ReC98
versary Edition)
| Umgekehrter eingeweiht: | |
|---|---|
| Abgeschlossen: | |
| Positionsunabhängigkeit: |
Weitere detaillierte Fortschrittsnummern und Informationen zum Crowdfunding finden Sie auf der Homepage!
Dieses Projekt zielt darauf ab, den Quellcode der ersten fünf Touhou-Projektspiele von Zun Soft (jetzt Team Shanghai Alice ) perfekt zu rekonstruieren, die ursprünglich exklusiv für das NEC PC-9801-System veröffentlicht wurden.
Die fraglichen Originalspiele sind:
Da wir nur die Binärdateien haben, können wir offensichtlich nicht wissen, wie Zun Variablen und Funktionen nannte und mit welchen Kommentaren der ursprüngliche Code umgeben war. Perfekt bedeutet daher, dass die aus dem Code im Rec98 -Repository zusammengestellten Binärdateien von Zuns ursprünglichen Builds nicht zu unterscheiden sind, was es unmöglich macht, zu widerlegen , dass der ursprüngliche Code nicht so aussehen können . Diese Eigenschaft wird für jeden Git -Commit auf dem Weg gehalten.
Abgesehen von dem Konservierungswinkel und dem daraus resultierenden tiefen Einblick in die Mechanik der Spiele kann der Code dann als Grundlage für jede Art von Mod oder einen Port-PC-98-Plattformen dienen, der von der Community entwickelt wurde. Dies ist auch der Grund, warum Rec98 -Werte lesbarer und verständlicher Code über eine reine Dekompilierung.
Es gibt mehrere, warum die Erreichung der Moddabilität durch vollständige Dekompilation für die PC-98-Spiele im Gegensatz zu einer Schwarzbox-Neuauflagen im Pytouhou-Stil lohnender zu sein scheint:
Seit Crowdfunding einen kontinuierlichen Strom der Unterstützung gebracht hat, war der Fortschritt konstant. Die Dekompilierung von Th01 wurde im August 2022 vollständig abgeschlossen, und die verbleibenden Spiele sind nur eine Frage der Zeit.
Im Laufe der Jahre führte dieses Projekt zu einem tiefen Verständnis der ursprünglichen Compiler und der PC-98-Hardware, bis zu dem Punkt, an dem die Dekompilierung selbst ziemlich mechanisch geworden ist. Um sicherzustellen, dass sich dieses Projekt sowohl für die Unterstützung als auch interessant anbietet, hat sich sein Fokus mehr auf die akribische Dokumentation und Überprüfung des ursprünglichen Code von Zun verändert. Das Projektblog beschreibt alle Ergebnisse auf eine allgemeiner lesbare Weise und ist wohl zur Hauptattraktion, wobei die Rekonstruktion des Quellcode selbst fast zu einem Nebenprodukt der zugrunde liegenden tiefen Forschung dieser Spiele wird.
Das Projekt begann auch ziemlich lebensfähig. Während der Entwicklung der statischen englischen Patches für diese Spiele haben wir zwei Hauptbibliotheken in allen 5 Spielen identifiziert und sogar ihren Quellcode gefunden. Diese sind:
ZUNSP.COM von Th03 (über ZUN.COM -4 zugänglich) ist eine umbenannte Version von Promisence Soft's SPRITE16.COM , ein 16-Color-PC-98-EGC-Display-Treiber, Version 0.04, der mit dem Probenspiel StormySpace gebündelt wurde. Master.lib und die C/C ++ -Raufzeit allein bilden eine beträchtliche Menge des Codes in allen ausführbaren Ausführungen. In Th05 beispielsweise beträgt sie 74% aller Code in OP.EXE und 40% aller Code in MAIN.EXE . Das ist schon ziemlich viel Code, mit dem wir uns nicht befassen müssen. Wenn Sie den Rest des in den Spielen geteilten Codes identifizieren, wird die Arbeitsbelastung weiter auf einen akzeptableren Betrag reduziert.
Mit Dosbox-X und der Debug-Ausgabe von Neko Project II haben wir auch zwei Open-Source-PC-9821-Emulatoren, die die Spiele durchführen können. Diese haben dazu beigetragen, die meisten Fragen im Zusammenhang mit Hardware zu beantworten, zusammen mit alten Büchern über PC-98-Entwicklung und gelegentliche Tests an echten Hardware.
zunsoft.com , op.exe , reiiden.exe , fuuin.exeongchk.comzuninit.com , zun_res.com , zunsoft.comop.exe , main.exe , maine.exeongchk.comzuninit.comzunsoft.comzunsp.com [-4], res_yume.com [-5]), op.exe , main.exe , mainl.exeongchk.comzuninit.com [-i], res_huma.com [-s], memchk.com [-m]), op.exe , main.exe , maine.exeongchk.comzuninit.com [-i], res_kso.com [-s], gjinit.com [-g], memchk.com [-m]), op.exe , main.exe , maine.exeÜberschreitende Dateien sind im vorherigen Spiel mit ihrer Version identisch. Ongchk.com ist Teil des PMD -Sound -Treibers von Kaja und muss daher auch nicht zerlegt werden. Wir müssen nur die Binärdatei behalten, um den Wiederaufbau von Zun.com zu ermöglichen.
Dieses Projekt enthält keine Vermögensdaten aus den ursprünglichen PC-98-Releases. Das Ausführen der kompilierten ausführbaren Funktionen erfordert weiterhin eine vorhandene Kopie der Originalspiele.
▶ master : Zuns ursprünglicher Code, ohne Mods oder Bugfixes (Sie sind hier!)
debloated : Fordertected-Version von Zuns Code, der leichter zu lesen und zu ändern ist und kleinere und schnellere PC-98-Binärdateien erstellt. Entfernt nur Aufblähen und Landminen; Alle Fehler und Macken aus Zuns ursprünglichem Code bleiben an Ort und Stelle. Ports sollten in dieser Niederlassung ausgehen , und es ist auch die empfohlene Basis für Mods, die sich nicht für die Ähnlichkeit mit der ursprünglichen Binärdehnung interessieren.
anniversary : Nimmt debloated und repariert zusätzlich Fehler, indem er ein glatteres und flackerfreies Gameplay-Erlebnis auf der PC-98-Plattform erzielt und gleichzeitig die Macken an Ort und Stelle hinterlässt. Könnte ein noch besserer Startport für Mods und Ports sein.
BossRush
th03_no_gdc_frequency_check : Ermöglicht TH03 mit der GDC -Uhr auf 5 MHz. Das ursprüngliche Spiel erzwingt 2,5 MHz, erfordert es jedoch nicht funktionell, selbst bei echten Hardware.
xJeePx : Codeänderungen für den 2014 English Translation Patch 2014.
th01_critical_fixes : Behebt zwei kritische Fehler in Th01:
th01_end_pic_optimize : beschleunigt das Bildblitt in den Zwischensequenzen von Th01 auf 50% der ursprünglichen Laufzeit. Hauptsächlich dient als Beispiel dafür, wie man optimalem EGC-Bitling-Code aus Turbo C ++ 4.0J nähert, ohne eine einzelne ASM-Anweisung zu schreiben. Das EGC ist definitiv nicht das beste Werkzeug für diesen Job.
th01_orb_debug : Zeigt die folgenden Informationen im Debug -Modus von Th01 an:
th01_sariel_fixes : Behebt drei Sprite -Störungen im Th01 -Sariel -Kampf, die sich aus klaren logischen Fehlern im ursprünglichen Code ergeben.
th03_real_hitbox : Renders Th03s Kollisionsbitmap auf beide Spielfelder. Sehr unspielbar.
Korrekturen für den Th04-Stufe 5 Yuuka No-EM-Crash:
th04_noems_crash_fix : Erhöht die selbst auferlegte Speichergrenze von Th04 von MAIN.EXE um genau die richtige Menge, um diesen einen Absturz zu beheben.mem_assign_all : Entfernt die selbst auferlegten Speichergrenzen in allen ausführbaren Th02-Th05-Ausführungsmitteln und fixiere zusätzlich andere potenzielle Abstürze außerhalb des Memorys, die während des Moddings auftreten können.Problemumgehungen für den TH04 Kurumi -Divide -Fehlerabsturz:
th04_0_ring_ignoreth04_0_ring_as_single_bulletth04_0_ring_as_cap_bulletsth04_0_ring_as_gameoverWorkarounds für den TH04 Stufe 4 Marisa Divide Fehler Crash:
th04_marisa4_crash_stillth04_marisa4_crash_moveth04_marisa4_crash_warp community_choice_fixes : Kombinationszweig aller "offensichtlichen" Bugfixes, die sich nicht auf das Gameplay oder keine Visuals auswirken:
th01_critical_fixesth03_no_gdc_frequency_checkth04_noems_crash_fix Außerdem die folgenden Problemumgehungen für Divide Error von Th04, die durch die Gemeinschaftsabstimmung ausgewählt wurden:
th04_0_ring_as_single_bullet (Umfrageergebnisse)th04_marisa4_crash_still (Umfrageergebnisse) Borland Turbo C ++ 4.0j
Dies war der Compiler Zun, der ursprünglich verwendet wurde, daher ist es der einzige, der diesen Code deterministisch kompilieren kann, um ausführbare Ausführbarungen zu kompilieren, die zu Zuns Originalbithergen sind. Borland hat nie einen Cross-Compiler-Ziel für 16-Bit-DOS gemacht, der an 32-Bit-Fenstern ausgeführt wird. Daher müssen die C ++-Teile mit einem 16-Bit-DOS-Programm zusammengestellt werden.
Rec98 verwendet auch Turbo C ++ 4.0J, um die benutzerdefinierten Tools in seiner Build -Pipeline zu erstellen, z. B. den Konverter für hartcodierte Sprites. Diese müssen nur im Rahmen des Build-Prozesses nativ laufen, sodass es kontraproduktiv erscheinen kann, sie in 16-Bit-DOS-Programme zusammenzustellen, die dann auf 64-Bit-Betriebssystemen emuliert werden müssen. Dies macht jedoch aus mehreren Gründen immer noch sinnvoll:
Daher ist es wenig sinnvoll, die normalerweise ziemlich starke Abhängigkeit von einem nativen C ++ - Compiler hinzuzufügen.
Borland Turbo Assembler (TASM), Version 5.0 oder höher, für 32-Bit-Fenster ( TASM32.EXE )
Rec98 erfordert nicht nur einen Assembler für den Spielcode, der noch nicht zerlegt wurde, sondern auch für PC-98 Touhous Drittanbieter-Bibliotheken und Zuns eigene handgeschriebene und unkenntliche Assembly-Code. Zum Glück kann der 32-Bit-Assembler von Borland für 16-Bit-Code verwendet werden und läuft nativ sowohl auf 64-Bit- als auch für 32-Bit-Fenster, wodurch die Tools von 16-Bit TASM.EXE und TASMX.EXE übertroffen werden.
Als Nebeneffekt ermöglicht die Verwendung eines nativen 32-Bit-Windows-Tools auch die ASM-Teile, lange Dateinamen frei zu verwenden, die nicht der DOS 8.3-Konvention entsprechen müssen.
MS-DOS-Spieler (gebündelt)
Ein leichter Emulator zum Ausführen von DOS-Befehlszeilen-Tools auf dem Windows-Konsolen-Subsystem, das beim Erstellen der Codebasis auf 64-Bit-Betriebssystemen automatisch verwendet wird. Trotz seiner abgespeckten Natur läuft es immer noch merklich langsamer als Dosbox, da es das Interpreting von X86-Kern von Neko Projekt 21/W verwendet, anstatt einen dynamischen Neukompilierer, aber die nahtlose Konsolenintegration mehr als wettmacht dies.
Der gebündelte Build wird speziell profiloptimiert, um Rec98 zu erstellen und einen reduzierten X86-Kern auszuführen, der nur einen 386 ohne FPU, Paging oder Zykluszählung emuliert. Im Vergleich zu Takeda Toshiya's Upstream-Builds beschleunigt dieser Build den Rec98-Build-Prozess um etwa 60% für einen vollständigen Wiederaufbau, ~ 80% für die Kompilierung und Verknüpfung der größten Übersetzungseinheit und der größten Binärdatum und ~ 70% für die mittelgroßen Übersetzungseinheit und Binärer. Es enthält außerdem ein Bugfix, der für das Ausführen von Turbo C ++ 4.0J im Kontext eines Build -Systems erforderlich ist, das ab Juni 2024 in den vorgelagerten Builds nicht verfügbar war.
Siehe bin/README.md für Lizenz und Erstellung von Informationen.
Tup für Fenster (gebündelt)
Ein vernünftiges, parallele Build -System, das verwendet wird, um minimale Umbauten zu gewährleisten. Bietet eine perfekte Verfolgung von Abhängigkeiten über die Codeinjektion und das Hooking der Datei eines Compiler -Datei, sodass die Syscalls eröffnet werden können, sodass sie automatisch alle #include D -Dateien in das Build -Abhängigkeits -Diagramm hinzufügen können. Dies macht es den meisten make überlegen, denen dieses wichtige Merkmal fehlt und daher von Natur aus für so ziemlich jede vorstellbare Programmiersprache nicht geeignet ist. Ohne Abstraktionen für bestimmte Compiler passt Tup auch perfekt zu den für dieses Projekt erforderlichen alten Borland -Tools.
Der gebündelte 64-Bit-Windows-Build enthält einen wichtigen Fehler für das Ausführen von DOS-basierten Build-Tools über MS-DOS-Player, das ab Juni 2024 nicht in das Upstream-Repository zusammengefasst wurde.
Siehe bin/README.md für Lizenz und Erstellung von Informationen.
Führen Sie einfach build.bat auf einer der unterstützten Build -Plattformen aus; Es tut das Richtige, unabhängig davon, welches Betriebssystem Sie ausführen. Der Prozess wird mit einem Fehler abgebrochen, wenn eines der erforderlichen Tools im Windows PATH nicht gefunden werden kann.
Die endgültigen ausführbaren Säle werden in binth0? mit den gleichen Namen wie die Originale. Das Ausführen erfordert die ursprünglichen Vermögenswerte jedes Spiels im selben Verzeichnis.
Bei 64-Bit X86 verwendet der Build-Prozess TUP für minimale parallele Umbauten, aber alle DOS-basierten Build-Tools werden emuliert. Auf 32-Bit X86 fällt der Build-Prozess in einer sequentiellen Stapeldatei zurück, die immer die gesamte Codebasis erstellt. Alle Build-Tools werden jedoch mit nativem Leistung ausgeführt.
Stufe 1 : regelmäßig getestet, beste Unterstützung garantiert.
Tier 2 : Soll funktionieren, machbar für die Unterstützung, aber nicht regelmäßig getestet werden. Kritische Fehler im Build -Prozess werden kostenlos behoben.
Tier 3 : Soll funktionieren, aber eine Belastung zu pflegen. Bei Behebung von Fehler im Zusammenhang mit Build-bezogenen Fehlern werden jedoch auch Bugfix-PRs akzeptiert.
Stufe 4 : explizit nicht unterstützt und unmittelbar, ohne ernsthaft zu basteln. Würde dedizierte Finanzmittel oder Gabeln erfordern, ist es unwahrscheinlich, dass PRs akzeptiert werden.
Tlink fällt mit Loader error (0000): Unrecognized Error bei 32-Bit-Fenstern ≥vista
Zwei bekannte Ursachen:
Versuchen Sie, den NTVDM -DPMI -Treiber zu konfigurieren, der in den herkömmlichen Speicher und nicht in den oberen Speicher geladen werden soll, indem Sie %WINDIR%System32autoexec.nt bearbeiten:
REM Install DPMI support
- LH %SystemRoot%system32dosx
+ %SystemRoot%system32dosxBenötigt nach dieser Bearbeitung einen Neustart, um wirksam zu werden.
(Quelle)
Versuchen Sie, in einer regulären cmd.exe -Hülle anstelle von PowerShell oder Bash zu bauen.
Siehe CONTRIBUTING.md .
