From 6c555aad6122fd40b5261b3b6804e9f187f5b1b3 Mon Sep 17 00:00:00 2001 From: nmlgc Date: Sun, 23 Dec 2018 00:34:19 +0100 Subject: [PATCH] [Readme] Mention that stage portions in TH04/TH05 *are* handled by bytecode Funded by zorg. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 22e7a419..176545fc 100644 --- a/README.md +++ b/README.md @@ -16,7 +16,7 @@ After completely decompiling the games first, we can then build an efficient env This approach is different from a project like [PyTouhou](http://pytouhou.linkmauve.fr/), a free/libre black-box reimplementation of the engine of TH06, [東方紅魔郷 ～ the Embodiment of Scarlet Devil](http://en.wikipedia.org/wiki/The_Embodiment_of_Scarlet_Devil). There are a number reasons why decompilation seems to be more worthwhile for the PC-98 games: -* From a cursory inspection of their code, these games appear to have not much of an "engine", much less a common one. The gameplay is mainly driven by stage- and boss-specific callback functions hardcoded into the executable, rather than the ECL scripts in the Windows games, which would merely require an alternate VM to interpret them. +* 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](https://github.com/joncampbell123/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.