ReC98
versary Edition)
| Inversé inversé: | |
|---|---|
| Finaliser: | |
| Indépendance de position: |
Vérifiez la page d'accueil pour des numéros de progrès plus détaillés et des informations sur le financement participatif!
Ce projet vise à reconstruire parfaitement le code source des cinq premiers jeux de projet Touhou de Zun Soft (maintenant Team Shanghai Alice ), qui ont été initialement publiés exclusivement pour le système NEC PC-9801.
Les jeux originaux en question sont:
Comme nous n'avons que les binaires, nous ne pouvons évidemment pas savoir comment Zun a nommé des variables et des fonctions, et qui commente le code d'origine. Parfait signifie donc que les binaires compilés à partir du code du référentiel REC98 ne sont pas en distingue des versions d'origine de Zun, ce qui rend impossible de réfuter que le code d'origine n'aurait pas pu ressembler à ceci. Cette propriété est maintenue pour chaque engagement GIT en cours de route.
Mis à part l'angle de préservation et le renseignement approfondi qui en résulte sur la mécanique des jeux, le code peut ensuite servir de base à tout type de MOD, ou à tout port sur des plateformes non PC-98, développé par la communauté. C'est également pourquoi Rec98 valorise le code lisible et compréhensible sur une pure décompilation.
Il y a plusieurs pourquoi atteindre la moddabilité via une décompilation complète semble être plus intéressante pour les jeux PC-98, contrairement à une réimplémentation de la boîte noire de style Pytouhou:
Depuis que le crowdfunding a apporté un flux continu de soutien, les progrès ont été stables. La décompilation de Th01 est complètement achevée en août 2022, et les jeux restants ne sont qu'une question de temps.
Au fil des ans, ce projet a conduit à une compréhension approfondie des compilateurs d'origine et du matériel PC-98, au point où la décompilation elle-même est devenue assez mécanique. Pour s'assurer que ce projet reste à la fois utile à soutenir et intéressant à travailler, son objectif a plus évolué vers la documentation méticuleuse et l'examen du code original de Zun. Le blog du projet détaille toutes les résultats d'une manière plus généralement lisible et est sans doute devenue la principale attraction, la reconstruction du code source elle-même se transformant presque en sous-produit de la recherche profonde sous-jacente sur ces jeux.
Le projet a également commencé assez viable. Au cours du développement des correctifs d'anglais statiques pour ces jeux, nous avons identifié deux bibliothèques principales utilisées sur les 5 jeux et avons même trouvé leur code source. Ce sont:
ZUNSP.COM de Th03 (accessible via ZUN.COM -4 ) est une version rebaptisée de SPRITE16.COM de Promision Soft, un pilote d'affichage EGC PC-98 à 16 couleurs, version 0.04, qui a été regroupé avec l' espace de jeu d'échantillon. Master.lib et l'exécution C / C ++ seul constituent une quantité importante du code dans tous les exécutables. Dans Th05, par exemple, ils représentent 74% de tous les code dans OP.EXE , et 40% de tous les code dans MAIN.EXE . C'est déjà beaucoup de code avec lequel nous n'avons pas à faire face. L'identification du reste du code partagé entre les jeux réduira encore la charge de travail à un montant plus acceptable.
Avec Dosbox-X et l'édition de débogage de Neko Project II, nous avons également deux émulateurs PC-9821 open source capables de gérer les jeux. Ceux-ci ont aidé à répondre à la plupart des questions liées au matériel, ainsi que des livres anciens sur le développement de PC-98 et des tests occasionnels sur du matériel réel.
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.exeLes fichiers interdits sont identiques à leur version dans le jeu précédent. Ongchk.com fait partie du pilote sonore PMD par Kaja, et n'a donc pas besoin d'être démonté non plus; Nous devons seulement garder le binaire pour permettre des reconstructions parfaites de zun.com.
Ce projet n'inclut aucune donnée d'actifs des versions d'origine PC-98. L'exécution des exécutables compilés nécessitera toujours une copie existante des jeux d'origine.
▶ master : le code d'origine de Zun, sans mods ni bugfixes (vous êtes ici!)
debloated : version redichietée du code de Zun qui est plus facile à lire et à modifier, et construit des binaires PC-98 plus petits et plus rapides. Élimine seulement les ballonnements et les mines terrestres; Tous les bogues et bizarreries du code d'origine de Zun sont laissés en place. Les ports doivent partir de cette branche , et c'est aussi la base recommandée pour les mods qui ne se soucient pas de la similitude avec le binaire d'origine.
anniversary : prend debloated et corrige en outre les bogues, réalisant une expérience de gameplay plus lisse et sans scintillement sur la plate-forme PC-98 tout en laissant des bizarreries en place. Pourrait être un port de départ encore meilleur pour les mods et les ports.
BossRush
th03_no_gdc_frequency_check : permet d'exécuter TH03 avec l'horloge GDC définie sur 5 MHz. Le jeu d'origine applique 2,5 MHz, mais ne l'exige pas fonctionnellement, même sur le matériel réel.
xJeePx : modifications de code pour le correctif de traduction en anglais de Xjeepx 2014.
th01_critical_fixes : Corre deux bugs critiques dans Th01:
th01_end_pic_optimize : accélère le blissant d'image dans les cinématiques de Th01 à 50% de l'exécution d'origine. Sert principalement d'exemple de la façon de se rapprocher du code de blignage optimal propulsé par l'EGC de Turbo C ++ 4.0J sans écrire une seule instruction ASM; L'EGC n'est certainement pas le meilleur outil pour ce travail.
th01_orb_debug : montre les informations suivantes dans le mode de débogage de Th01:
th01_sariel_fixes : Corrige trois problèmes de sprite dans le combat TH01 SAriel qui résulte des erreurs de logique claire dans le code d'origine.
th03_real_hitbox : rend le bitmap de collision de Th03 sur les deux champs de jeu. Très injouable.
Corrigeons pour le crash de NO-EMS Yuuka de Stage 5 TH04:
th04_noems_crash_fix : augmente la limite de mémoire auto-imposée de MAIN.EXE de Th04 par la bonne quantité pour corriger ce crash.mem_assign_all : supprime les limites de mémoire auto-imposées dans tous les exécutables Th02-TH05, fixant en outre d'autres plantages potentiels hors mémoire qui peuvent se produire pendant le modding.Solution de contournement pour le crash d'erreur Th04 Kurumi Divide:
th04_0_ring_ignoreth04_0_ring_as_single_bulletth04_0_ring_as_cap_bulletsth04_0_ring_as_gameoverSolution pour le TH04 Stage 4 Marisa Divide Error Crash:
th04_marisa4_crash_stillth04_marisa4_crash_moveth04_marisa4_crash_warp community_choice_fixes : branche combinée de tous les bugfix "évident" qui n'affectent pas le gameplay ou les visuels:
th01_critical_fixesth03_no_gdc_frequency_checkth04_noems_crash_fix Plus les solutions de contournement suivantes pour les bogues Divide Error du TH04, choisis par vote communautaire:
th04_0_ring_as_single_bullet (Résultats du sondage)th04_marisa4_crash_still (Résultats du sondage) Borland Turbo C ++ 4.0J
C'était le compilateur utilisé à l'origine, c'est donc le seul qui peut compiler de manière déterministe ce code aux exécutables qui sont parfaits pour les originaux de Zun. Borland n'a jamais réalisé un compilateur croisé ciblant les DO 16 bits qui s'exécute sur des fenêtres 32 bits, de sorte que les pièces C ++ doivent être compilées à l'aide d'un programme DOS 16 bits.
Rec98 utilise également Turbo C ++ 4.0J pour construire les outils personnalisés dans son pipeline de construction, tels que le convertisseur pour les sprites codés en dur. Ceux-ci ne doivent s'exécuter nativement dans le cadre du processus de construction, il peut donc sembler contre-productif de les compiler dans des programmes DOS 16 bits qui doivent ensuite être émulés sur des systèmes d'exploitation 64 bits. Cela a toujours du sens pour plusieurs raisons, cependant:
Par conséquent, il est peu logique d'ajouter la dépendance généralement assez forte d'un compilateur C ++ natif.
Borland Turbo Assembler (TASM), version 5.0 ou version ultérieure, pour Windows 32 bits ( TASM32.EXE )
REC98 nécessite non seulement un assembleur pour le code de jeu qui n'a pas encore été décompilé, mais aussi pour les bibliothèques tierces de PC-98 Touhou et le code d'assemblage de la propre manuscrite et indécompilable de Zun. Heureusement, l'assembleur 32 bits de Borland peut être utilisé pour le code 16 bits et s'exécute nativement sur des fenêtres 64 bits et 32 bits, surpassant les outils TASM.EXE et TASMX.EXE 16 bits.
En tant qu'avantage secondaire, l'utilisation d'un outil Windows 32 bits natif permet également aux pièces ASM d'utiliser librement les noms de fichiers longs qui n'ont pas besoin de se conformer à la convention DOS 8.3.
Joueur MS-DOS (groupé)
Un émulateur léger pour exécuter des outils de ligne de commande DOS sur le sous-système de la console Windows, utilisé automatiquement lors de la construction de la base de code sur des systèmes d'exploitation 64 bits. Malgré sa nature dépouillée, il fonctionne toujours sensiblement plus lent que Dosbox car il utilise le noyau X86 de l'interprétation de Neko Project 21 / W plutôt qu'un récompilateur dynamique, mais l'intégration de la console transparente ne compense plus que cela.
La construction groupée est spécifiquement optimisée par le profil pour la construction REC98, exécutant un noyau x86 réduit qui n'impose qu'un 386 sans FPU, pagination ou comptage de cycle. Par rapport aux constructions en amont de Takeda Toshiya, cette construction accélère le processus de construction REC98 de ≈60% pour une reconstruction complète, ≈80% pour compiller et relier la plus grande unité de traduction et le plus grand binaire, et ≈70% pour l'unité de traduction et le binaire de la taille médiane. Il contient également un bugfix requis pour exécuter Turbo C ++ 4.0J dans le contexte d'un système de construction qui n'était pas disponible dans les constructions en amont en juin 2024.
Voir bin/README.md pour les informations de licence et de construction.
Tup , pour Windows (groupé)
Un système de construction sain d'esprit et parallèle, utilisé pour assurer un minimum de reconstructions. Fournit un suivi parfait des dépendances via l'injection de code et l'accrochage des systèmes d'ouverture de fichiers d'un compilateur, ce qui lui permet d'ajouter automatiquement tous les fichiers #include D au graphique de dépendance de build. Cela rend la plus supérieure à la plupart make implémentations, qui manquent de cette caractéristique vitale, et sont donc intrinsèquement inadaptées à presque tous les langues de programmation imaginables. Sans abstractions pour les compilateurs spécifiques, le TUP s'adapte également parfaitement aux anciens outils de borland requis pour ce projet.
La construction Windows 64 bits regroupée comprend un BugFix important pour exécuter des outils de construction basés sur DOS via le lecteur MS-DOS qui n'a pas été fusionné dans le référentiel en amont en juin 2024.
Voir bin/README.md pour les informations de licence et de construction.
Exécutez simplement build.bat sur l'une des plates-formes de construction prises en charge; Il fait la bonne chose, quel que soit le système d'exploitation que vous utilisez. Le processus abandonnera avec une erreur si l'un des outils nécessaires ne peut être trouvé dans le PATH Windows.
Les exécutables finaux seront placés dans binth0? , en utilisant les mêmes noms que les originaux. Les exécuter nécessite des actifs originaux de chaque jeu dans le même répertoire.
Sur 64 bits x86, le processus de construction utilise TUP pour des reconstructions parallèles minimes, mais tous les outils de construction basés sur DOS sont émulés. Sur le X86 32 bits, le processus de construction retombe sur un fichier de lots séquentiel qui construit toujours la base de code entière, mais tous les outils de construction peuvent s'exécuter à des performances natives.
Tier 1 : Testé régulièrement, le meilleur support garanti.
Tier 2 : censé fonctionner, faisable pour soutenir, mais pas régulièrement testé. Les bogues critiques dans le processus de construction seront corrigées gratuitement.
Niveau 3 : censé fonctionner, mais un fardeau à maintenir. Les correctifs pour les bogues liés à la construction nécessiteraient un financement, mais BugFix PRS est également également accepté.
Tier 4 : explicitement non pris en charge et inadapté sans bricolage sérieux. Nécessiterait un financement ou des fourches dédiées, il est peu probable que les PR sont acceptés.
Tlink échoue avec Loader error (0000): Unrecognized Error sur les fenêtres 32 bits ≥Vista
Deux causes connues:
Essayez de configurer le pilote NTVDM DPMI pour être chargé dans la mémoire conventionnelle plutôt que dans la mémoire supérieure, en modifiant %WINDIR%System32autoexec.nt :
REM Install DPMI support
- LH %SystemRoot%system32dosx
+ %SystemRoot%system32dosxNécessite un redémarrage après cette modification pour prendre effet.
(Source)
Essayez de construire dans une coquille cmd.exe ordinaire au lieu de PowerShell ou Bash.
Voir CONTRIBUTING.md .
