nmlgc / rec98

The Touhou PC-98 Restoration Project

The Touhou PC-98 Restoration Project ("ReC98")

Reverse-engineered:
Finalized:
Position independence:

Check the homepage for more detailed progress numbers and information about the crowdfunding!

---

Overview

This project aims to perfectly reconstruct the source code of the first five Touhou Project games by ZUN Soft (now Team Shanghai Alice), which were originally released exclusively for the NEC PC-9801 system.

The original games in question are:

• TH01: 東方靈異伝　～ The Highly Responsive to Prayers (1997)
• TH02: 東方封魔録　～ the Story of Eastern Wonderland (1997)
• TH03: 東方夢時空　～ Phantasmagoria of Dim.Dream (1997)
• TH04: 東方幻想郷　～ Lotus Land Story (1998)
• TH05: 東方怪綺談　～ Mystic Square (1998)

Since we only have the binaries, we obviously can't know how ZUN named any variables and functions, and which comments the original code was surrounded with. Perfect therefore means that the binaries compiled from the code in the ReC98 repository are indistinguishable from ZUN's original builds, making it impossible to disprove that the original code couldn't have looked like this. This property is maintained for every Git commit along the way.

Aside from the preservation angle and the resulting deep insight into the games' mechanics, the code can then serve as the foundation for any type of mod, or any port to non-PC-98 platforms, developed by the community. This is also why ReC98 values readable and understandable code over a pure decompilation.

Why?

There are a number reasons why achieving moddability via full decompilation seems to be more worthwhile for the PC-98 games, in contrast to a PyTouhou-style black-box reimplementation:

• While stage enemies and their bullet patterns are controlled by bytecode in TH04's and TH05's .STD files that could just be interpreted by an alternate VM, midboss and boss battles are entirely hardcoded into the executables.
• Even though complete decompilation will take a long time, partial reverse-engineering results will be very useful to modders who just want to work on the original PC-98 versions of the games.
• PC-98 emulation is messy and overly complicated. It has been getting better as of 2018 thanks to DOSBox-X adding support for the platform, but even at its best, it will always consume way more system resources than what would be appropriate for those games.
• thcrap-style multilingual translation on PC-98 would be painful for languages with non-ASCII scripts. The obvious method of modifying the font ROM specifically for each language is ugly and won't work on real hardware, so a custom renderer would be needed. That by itself requires a lot of reverse-engineering and, preferably, compilable source code to avoid the limits of hex-editing. Or, even better, the prospect to do this entirely on a more modern system.
• These games stopped being sold in 2002, ZUN has confirmed on multiple occasions to have lost all the data of the "earlier games" ^{[citation needed]}, and PC-98 hardware is long obsolete. In short, these games are as abandoned as they can possibly be, and are unlikely to ever turn a profit again.

Is this even viable?

Ever since crowdfunding has brought a continuous stream of support, progress has been steady. Decompilation of TH01 fully completed in August 2022, and the remaining games are only a matter of time.

Over the years, this project led to a deep understanding of the original compilers and PC-98 hardware, to the point where the decompilation itself has become pretty mechanical. To ensure that this project remains both worthwhile to support and interesting to work on, its focus has shifted more toward meticulous documentation and review of ZUN's original code. The project blog details all the findings in a more generally readable way and has arguably become the main attraction, with the source code reconstruction itself almost turning into a byproduct of the underlying deep research into these games.

The project started out pretty viable as well. During the development of the static English patches for these games, we identified two main libraries used across all 5 games, and even found their source code. These are:

• master.lib, a 16-bit x86 assembly library providing an abstraction layer for all components of a PC-98 DOS system
• as well as the Borland C/C++ runtime library, version 4.0.
• Additionally, TH01 includes the Pi loader library by 電脳科学研究所/BERO,
• and TH03's ZUNSP.COM (accessible via ZUN.COM -4) is a rebranded version of Promisence Soft's SPRITE16.COM, a 16-color PC-98 EGC display driver, version 0.04, which was bundled with the sample game StormySpace.

master.lib and the C/C++ runtime alone make up a sizable amount of the code in all the executables. In TH05, for example, they amount to 74% of all code in OP.EXE, and 40% of all code in MAIN.EXE. That's already quite a lot of code we do not have to deal with. Identifying the rest of the code shared across the games will further reduce the workload to a more acceptable amount.

With DOSBox-X and the Debug edition of Neko Project II, we also have two open-source PC-9821 emulators capable of running the games. These have helped to answer most hardware-related questions, together with old books about PC-98 development and occasional tests on real hardware.

Dumped executables

• TH01: zunsoft.com, op.exe, reiiden.exe, fuuin.exe
• TH02: zun.com (ongchk.com, zuninit.com, zun_res.com, zunsoft.com), op.exe, main.exe, maine.exe
• TH03: zun.com (ongchk.com [-1], zuninit.com [-2], zunsoft.com [-3], zunsp.com [-4], res_yume.com [-5]), op.exe, main.exe, mainl.exe
• TH04: zun.com (ongchk.com [-O], zuninit.com [-I], res_huma.com [-S], memchk.com [-M]), op.exe, main.exe, maine.exe
• TH05: zun.com (ongchk.com [-O], zuninit.com [-I], res_kso.com [-S], gjinit.com [-G], memchk.com [-M]), op.exe, main.exe, maine.exe

Crossed-out files are identical to their version in the previous game. ONGCHK.COM is part of the PMD sound driver by KAJA, and therefore doesn't need to be disassembled either; we only need to keep the binary to allow bit-perfect rebuilds of ZUN.COM.

This project does not include any asset data from the original PC-98 releases. Running the compiled executables will still require an existing copy of the original games.

Branches

• ▶ master: ZUN's original code, without mods or bugfixes (You are here!)

• debloated: Rearchitected version of ZUN's code that is easier to read and modify, and builds smaller and faster PC-98 binaries. Only removes bloat and landmines; all bugs and quirks from ZUN's original code are left in place. Ports should start from that branch, and it's also the recommended base for mods that don't care about similarity to the original binary.

• anniversary: Takes debloated and additionally fixes bugs, achieving a smoother and flicker-free gameplay experience on the PC-98 platform while still leaving quirks in place. Might be an even better starting port for mods and ports.

• BossRush

• th03_no_gdc_frequency_check: Allows TH03 to be run with the GDC clock set to 5 MHz. The original game enforces 2.5 MHz, but doesn't functionally require it, even on real hardware.

• xJeePx: Code changes for xJeePx's 2014 English translation patch.

• th01_critical_fixes: Fixes two critical bugs in TH01:

  • Potential heap corruptions in the game's debug mode when decrementing boss HP by holding ↵ Return while the HP bar is still filling up.
  • General Protection Faults when defeating bosses with diagonally moving shootout lasers on screen. These are most commonly reported for Elis or Mima, and when playing on real hardware or Anex86.

• th01_end_pic_optimize: Speeds up image blitting in TH01's cutscenes to 50% of the original runtime. Mainly serves as an example of how to get close to optimal EGC-powered blitting code out of Turbo C++ 4.0J without writing a single ASM instruction; the EGC is definitely not the best tool for this job.

• th01_orb_debug: Shows the following information in TH01's debug mode:

  • Physics values for the Yin-Yang Orb at the bottom center of the playfield
  • The frames since the last collision with every bumper bar in the top-left corner of the respective stage object tile

• th01_sariel_fixes: Fixes three sprite glitches in the TH01 Sariel fight that result from clear logic errors in the original code.

• th03_real_hitbox: Renders TH03's collision bitmap onto both playfields. Highly unplayable.

• Fixes for the TH04 Stage 5 Yuuka No-EMS crash:

  • th04_noems_crash_fix: Increases the self-imposed memory limit of TH04's MAIN.EXE by just the right amount to fix that one crash.
  • mem_assign_all: Removes the self-imposed memory limits in all TH02-TH05 executables, additionally fixing other potential out-of-memory crashes that may occur during modding.

• Workarounds for the TH04 Kurumi Divide Error crash:

  • th04_0_ring_ignore
  • th04_0_ring_as_single_bullet
  • th04_0_ring_as_cap_bullets
  • th04_0_ring_as_gameover

• Workarounds for the TH04 Stage 4 Marisa Divide Error crash:

  • th04_marisa4_crash_still
  • th04_marisa4_crash_move
  • th04_marisa4_crash_warp

• community_choice_fixes: Combination branch of all "obvious" bugfixes that don't affect gameplay or visuals:

  • th01_critical_fixes
  • th03_no_gdc_frequency_check
  • th04_noems_crash_fix

  Plus the following workarounds for TH04's Divide Error bugs, chosen by community vote:

  • th04_0_ring_as_single_bullet (poll results)
  • th04_marisa4_crash_still (poll results)

---

Building

Required tools

• Borland Turbo C++ 4.0J

  This was the compiler ZUN originally used, so it's the only one that can deterministically compile this code to executables that are bit-perfect to ZUN's original ones.

  ---

• Borland Turbo Assembler (TASM), version 5.0 or later, for 32-bit Windows (TASM32.EXE)

  Borland never made a cross compiler targeting 16-bit DOS that runs on 32-bit Windows, so the C++ parts have to be compiled using a 16-bit DOS program. The not yet decompiled ASM parts of the code, however, can be assembled using a 32-bit Windows tool. This not only way outperforms any 16-bit solution that would have to be emulated on modern 64-bit systems, making build times, well, tolerable. It also removes any potential EMS or XMS issues we might have had with TASMX.EXE on these emulators.

  These advantages were particularly relevant in the early days of ReC98, when the ASM files were pretty huge. That's also when I decided to freely use long file names that don't need to conform to the 8.3 convention… As a result, the build process still starts with a separate 32-bit part (build32b.bat), which must be run in Windows (or Wine).

  In the end though, we'd definitely like to have a single-step 16-bit build process that requires no 32-bit tools. This will probably happen some time after reaching 100% position independence over all games.

  ---

• Borland C++ 5.5, for 32-bit Windows (BCC32.EXE)

  Released as freeware, and as of July 2020, still sort of officially downloadable from

  http://altd.embarcadero.com/download/bcppbuilder/freecommandLinetools.exe

  (SHA-256 433b44741f07f2ad673eb936511d498c5a6b7f260f98c4d9a6da70c41a56d855)

  Needed to fulfill the role of being "just any native C++ compiler" for our own tools that either don't necessarily have to run on 16-bit DOS, or are required by the 32-bit build step, as long as that one still exists (see above).

  Currently, this category of tools only includes the converter for hardcoded sprites. Since that one is written to be as platform-independent as possible, it could easily be compiled with any other native C compiler you happen to have already installed. (Which also means that future port developers hopefully have one less thing to worry about.) So, if you dislike additional dependencies, feel free to edit the Tupfile so that bmp2arr is compiled with any other C compiler of your choice.

  However, choosing Borland C++ 5.5 as a default for everyone else fits ReC98 very well for several reasons:

  • It still happens to be the most hassle- and bloat-free way to get any sort of 32-bit Windows C++ compiler to people, clearly beating Open Watcom, and the required registration for Borland/Embarcadero's own C++ 7.30. Depending on anything bigger would be way out of proportion, considering how little we use it for
  • We already rely on a 32-bit Windows tool
  • Turbo C++ 4.0J defines the lower bound for our allowed level of C++ features anyway, making Borland C++ 5.5's old age and lacking C++ standard compliance a non-issue
  • Unlike 7.30, 5.5 still works on Windows 9x, which is what typically runs on the real PC-98 hardware that some people might want to compile ReC98 on.
  • Other tiny C compilers have no C++ support. While the sprite converter is written in C, future tools might not be, and I'm too old to restrict people to C for no good reason.

  ---

• Tup, for Windows (optional, but recommended)

  A sane, parallel build system, used to ensure minimal rebuilds during the 32-bit build part. Provides perfect tracking of dependencies via code injection and hooking a compiler's file opening syscalls, allowing it to automatically add all #included files to the build dependency graph. This makes it way superior to most make implementations, which lack this vital feature, and are therefore inherently unsuited for pretty much any programming language imaginable. With no abstractions for specific compilers, Tup also fits perfectly with the ancient Borland tools required for this project.

  As of September 2020, the Windows version of Tup requires Vista or higher. In case Tup can't run or isn't installed, the build process falls back on a dumb batch file, which always fully rebuilds the entire 32-bit part.

  ---

• DOSBox (if you're running a 64-bit version of Windows, or a non-Windows operating system)

  For the most part, it shouldn't matter whether you use the original DOSBox or your favorite fork. A DOSBox with dynamic recompilation is highly recommended for faster compilation, though. Make sure to enable that feature by setting the following options in its configuration file (dosbox.conf for the original version):

  [cpu]
  core=dynamic
  cycles=max

  ---

The most performant OS for building ReC98 is therefore a 32-bit Windows ≥Vista and <11, where both the 32-bit and 16-bit build parts can run natively from a single shell. The build process was tested and should work reliably on pretty much every system though – from modern 64-bit Windows and Linux, down to Windows 95, which you might use on actual PC-98 hardware.

How to build

• Make sure you've created the bin/bcc32.cfg and bin/ilink32.cfg files for Borland C++ 5.5, as pointed out in its readme.txt file. This fixes errors like

  Error E2209 Pipeline/bmp2arrl.c 12: Unable to open file 'io.h'
  

  that you will encounter otherwise.

• Running on a 64-bit OS? Run build32b.bat in a Windows shell, followed build16b.bat in your DOSBox of choice.

• Running on 32-bit Windows? Run just build.bat.

All batch files will abort with an error if any of the necessary tools can't be found in the PATH.

The final executables will be put into bin\th0?, using the same names as the originals. Running them requires each game's original assets in the same directory.

Troubleshooting

• TCC compiles, but fails to link, with Error: Unable to execute command 'tlink.exe'

  Cause: To locate TLINK, TCC needlessly copies the PATH environment variable into a statically allocated 128-byte buffer. It then constructs absolute tlink.exe filenames for each of the semicolon- or \0-terminated paths, writing these into a buffer that immediately follows the 128-byte PATH buffer in memory. The search is finished as soon as TCC found an existing file, which gives precedence to earlier paths in the PATH. If the search didn't complete until a potential "final" path that runs past the 128 bytes, the final attempted filename will consist of the part that still fit into the buffer, followed by the previously attempted path.

  Workaround: Make sure that the BIN\ path to Turbo C++ 4.0J is fully contained within the first 127 bytes of the PATH inside your DOS system. (The 128^th byte must either be a separating ; or the terminating \0 of the PATH string.)

• TLINK fails with Loader error (0000): Unrecognized Error on 32-bit Windows ≥Vista

  This can be fixed by configuring the NTVDM DPMI driver to be loaded into conventional memory rather than upper memory, by editing %WINDIR%\System32\autoexec.nt:

  REM Install DPMI support
  -LH %SystemRoot%\system32\dosx
  +%SystemRoot%\system32\dosx

  Requires a reboot after that edit to take effect.

  (Source)

Contribution guidelines

See CONTRIBUTING.md.

---

rec98's Issues

About th02~05 Music Room

I recently did a project to re-create the th2 ~ 5 music room. However, I encountered a problem, I do not know ZUN the use of the polygon background (which is the polygon inside the star image) where. So I'd like to ask you, where do you find those pictures from these data? thank you very much!

PoDD remake!

I'm doing a remake of PoDD with ReC98 (when I actually get to doing it) and I need help! I need someone who can draw in the PC-98 style, composers who can make PMD music, and people who can make more stages and cutscenes for the game. I'm writing the dialogue and music comments, as well as translating stuff. Here's a TV Tropes darth wiki page on what's gonna go on in the game: http://tvtropes.org/pmwiki/pmwiki.php/DarthWiki/PhantasmagoriaOfDimDreamRemake

`th04_marisa4_crash_warp` branch actually contains the 'still' code

The th04_marisa4_crash_warp branch's code is looks to be identical to the code in the th04_marisa4_crash_still one.

$ git checkout th04_marisa4_crash_warp 
$ git log|head
commit 96ca88f6299629973165ed0d7b5a82dc8e26b71d
Author: nmlgc <[email protected]>
Date:   Fri Apr 15 03:06:49 2022 +0200

    [Mod] [th04] Stage 4 Marisa: Replace the Divide Error with no movement at all
...

$ git log|head
commit 79a78cac7448ab7f8ce178387c493f61783cdf51
Author: nmlgc <[email protected]>
Date:   Fri Apr 15 03:06:49 2022 +0200

    [Mod] [th04] Stage 4 Marisa: Replace the Divide Error with no movement at all
    ...

I found this while trying to find if there would be a way to patch my English translated binary in a hex editor to avoid having to try setting up a cross compilation/assembly environment in Linux. I do not have windows on anything at all. I already successfully did this for the EMS crash (for the RHDN patches: change 204E to 1A4F at address 0xBD10).

I did this because I don't think the community fixes are in English.

Will this thing work on MS-DOS?

I'm wondering if this reconstruction of the old Touhou games will work on IBM-compatible/standard MS-DOS.

Write a BMP→array converter for hardcoded 1bpp sprites?

TH01 pellets are coming up next, and for the first time, we'll have the chance to move hardcoded sprite data from ASM land to C land. This raises the question of when we are going to do this The Right And Moddable Way, by auto-converting actual image files into ASM or C arrays during the build process. This converter would also automatically generate pre-shifted versions of any sprites that need them, without requiring modders to store the 8 versions of those sprites manually.

Such a minor thing is currently not covered by any of the subscriptions, probably to this missing option in the order form. Since it requires no RE skills and also collides with nothing else, it would be the perfect thing to be done by an outside contributor who is merely familiar with C/C++… if we still have any left, that is.
Any backers with outstanding contributions in the backlog might also choose to put their contribution towards that, in case they think that this is more valuable than more reverse-engineering at this point. Otherwise, I'll just hardcode TH01's pellets directly, for the time being.

Since TH05's gaiji are also stored in this hardcoded 1bpp form, I also consider this converter as a prerequisite for fully rebuilding TH05's ZUN.COM, as mentioned in the 2020-02-23 blog post. As it turns out though, the OMF .OBJ output mentioned in that post won't be necessary after all. Most of these sprite declarations lie in the middle of a translation unit anyway, and therefore need to be #included. Same for ASM land.

---

Some more, unsorted details I had in mind - everything here is still up for discussion though:

• Ideally, we'd only have to read 1bpp ("monochrome") .BMP files, as saved by MS Paint – any non-1bpp formats are handled by other, non-hardcoded image formats, and are out of scope here. However, Paint is pretty much deprecated, and has a quite nasty rendering bug in 1bpp mode on my system:

  
  (It's the exact spark sprite sheet from below, but some dots just aren't rendered?)

  It's also been getting more and more difficult to save this format from other tools. Therefore, the converter should also accept all other common uncompressed .BMP bit depths – but, of course, error out whenever any color other than #000000 or #ffffff is found.

• This should simultaneously compile into a 16- and 32-bit binary, right from the start. The 32-bit build step already requires the ASM arrays to be present, as does the 16-bit build step for C arrays.

• Yes, technically it wouldn't be necessary to compile this into a 16-bit Real Mode DOS program, since we could already output the C arrays during ReC98's 32-bit build step. However, people are looking forward to the eventual 16-bit-only build process, and I agree that it makes no sense to have the PC-98-only master depend on a 32-bit C++ compiler just for things like these.

• Therefore, aim for maximum portability right from the start - the converter should compile with anything from Turbo C++ 4.0J up to modern Visual Studio and GCC/Clang compilers, so that future port authors have one less thing to worry about. Now, I could force C89 onto people now, but I really don't see why I should 🙂

  ReC98 itself is going to use the freeware Borland C++ 5.5 (from the infamous freecommandLinetools.exe) as its default 32-bit Windows compiler; I've just added that one to the DevKit. Turbo C++ 4.0J defines the subset of allowed C++ features anyway, and BCC55 still happens to be the most hassle- and bloat-free way to get any sort of 32-bit Windows C++ compiler to people. (Open Watcom unfortunately only comes second here.)

• Rely on platform.h in the top level of this repo, adding new things there as necessary. For modern, sane compilers, we'd ideally only need to #include <stdint.h> there? I hope.

• For integration into the future build system, the converter should be written as a library with a C/C++ API.

• My original plan would have involved parsing sprite dimensions from a C header, recognizing the dots*_t types, as well as macros like PRESHIFT to figure out where to put the pre-shifted data, or *_H to indicate the height. However, that would not only significantly raise the complexity of this, it also can't communicate all necessary information: TH03's in-game score sprites have their dots stored upside down, but we'd obviously like to have them the right way around in the .BMP file. (Not to mention the fact that TH05's zun -G is written completely in ASM and doesn't need a C header anyway.)

• 💡 And then you notice that having a C++ build system allows you to just #include the sprite declarations from their actual header, and then pass the necessary numbers to the converter via sizeof(). So, the converter is free to only output raw numbers for the array definition. Adding per-dimension initializer lists will catch even more errors at compile-time, and mzdiff will catch the rest 🙂

• 💡 And then you notice that this doesn't depend on the build system at all. We can simply use the converter's main() function to call the conversion API for every sprite sheet in ReC98, with "hardcoded" paths, and run that from the Makefile. Then, we don't even need to design a command-line frontend.

• No further dependencies – yes, no master.lib, but also no win32_utf8. The only encoding-sensitive call should be fopen(), so let's just handle Win32 Unicode via an overload for wchar_t.

• The dots*_t types limit the width of individual sprites to 8, 16, or 32 dots, you don't need to support any other sprite widths. Pre-shifted sprites can even be restricted to 8 dots.

• Inside the .BMP files, cels can be arranged in any left-to-right, top-to-bottom order. Their individual positions are then derived according to the dimensions of the input file. An example from TH05's gaiji sprite sheet:

  • Sprite size: 16×16
  • Sprite count: 256
  • Input .BMP size: 256×256
  • → Top-left corner of sprite #174 (0xAE) is at position ((0xAE % 16) * 16, ⌊0xAE / 16⌋ * 16) = (224, 160)

• Preliminary file extensions for the generated files could be .csp and .asp. The future build system mandates that those are different from regular .cpp or .asm, because that's how it selects the compiler. Having distinct extensions also works well with .gitignore.

• Whoever writes it gets to name it. (Within reason, of course…) 6 letters max, since we need to suffix it with 16 and 32 – if a directory contains both a .COM and a .EXE with the same name, even modern 64-bit Windows runs the .COM binary by default…

• And, of course, it should output the obligatory // Generated by ??? from ???.bmp, do not modify directly comment in the first line of the file.

---

Currently, the converter would have to work correctly with the following sprites, and output the same arrays we currently got in the repo:

Game	.BMP file	C declaration / data layout	Note
1		dots16_t sPELLET[3][PRESHIFT][8];
2/4/5		dots16_t sPELLET[PRESHIFT][8];	Reusing TH01's bitmap is probably not worth the complication of somehow getting rid of TH01's two decay sprites, which are no longer used in later games?
2/4/5		dots16_t sSPARKS[PRESHIFT][8][8];
2		dots16_t sPOINTNUMS[13][8];	Yes, there's a 13th empty 8×8 sprite at the end. It's actually used in place of the multiplier, if the multiplier would be ×1. :zunpet:
3		dots8_t sSCORE[10][8];	Emitted data needs to be stored upside-down.
4/5		dots16_t sPELLET_BOTTOM[PRESHIFT][4];	Bottom gray part of pellets.
4/5		dots16_t sPOINTNUMS[12][PRESHIFT][8];	Also not worth reusing the first 10 sprites of TH02's bitmap.
5		dots16_t sGAIJI[256][16];
5		dots8_t sPIANO_LABEL[9][8];

(Technically, we'd also have to add the piano sprites for TH05's Music Room, but these are stored and used in such a compressed way that it defeats the purpose of storing them as bitmaps.)

does the games are decompiled ?

Hello, i'm a member of touhou online and we would like to translate to french the pc98 touhou games, so i've been interested in your decompilation method of the games in order to translate them, could you tell me if it's usable and how ?

Logo artwork

(@Shinmera, would you be up for doing artwork for this project as well? I've even got a more detailed description this time around.)

---

Now that all the doubts about the feasibility of this project have been removed and I'm slowly starting promotion, it would be nice to have some custom artwork to go along with it.

The basic concept I've been having in mind is Richard Stallman cosplaying PC-98 characters (or the other way round, whichever you think looks better or funnier). There would be 6 main versions in total: one with Reimu or Marisa (again, up to the artist) to represent the project as a whole, as well as the final boss of each game (Sariel, Mima, Yumemi, Yuuka and Shinki) to represent that specific game.

Stylistically, I'm looking for something similar to Touhoumon sprites, that is, a whole-body drawing of the given character striking a random pose. Bonus points if the 5 Magic Stones are included in the artwork, since I just love using them to mock Touhou character discussions. ☺

I'm not asking for entirely separate images per game. It's completely fine if the costumes of the 6 characters are merely layers on top of a shared base pose.

Since these will be mainly used as icons, you should be going for a square aspect ratio. Apart from that, draw as high-res as you like. (Of course, SVG is always preferred, but it's not too important.)

That said, the future ports will also introduce new in-game menus for mod selection, and I'd like to reuse some of the character artwork as message box or status icons. I think I should be able to create low-res sprites from the high-res promotional images by myself, but it would be great if I could get some help there as well. In that case, we could even add a small waiting animation or different expressions for the various types of message boxes (information, warnings and errors).

Just note that these images need to match the constraints of the PC-98 graphics hardware, and can thus only use a maximum of 16 different colors.

However, we're still about one year away from that point, so I can't give any more specifics on that right now.