| リバースエンジニアリング: | |
|---|---|
| 確定: | |
| ポジションの独立性: |
より詳細な進捗数とクラウドファンディングに関する情報については、ホームページを確認してください!
このプロジェクトは、NEC PC-9801システム専用にリリースされたZun Soft (現在のTeam Shanghai Alice )による最初の5つのTouhouプロジェクトゲームのソースコードを完全に再構築することを目的としています。
問題の元のゲームは次のとおりです。
私たちはバイナリしか持っていないので、Zunがどのように変数や関数を挙げたか、そして元のコードが囲まれているコメントを明らかに知ることができません。したがって、完全なことは、REC98リポジトリのコードからコンパイルされたバイナリがZunの元のビルドと区別できないため、元のコードがこのように見えなかったことを反証することを不可能にすることを意味します。このプロパティは、途中ですべてのgitコミットに対して維持されます。
保存の角度と、結果として生じるゲームのメカニクスに対する深い洞察は別として、コードは、コミュニティが開発したあらゆるタイプのMOD、または任意のポートからPC-98プラットフォームの基盤として機能します。これは、rec98が純粋な逆コンパイルよりも読みやすく理解可能なコードを評価する理由でもあります。
PC-98ゲームでは、PC-98ゲームでは、完全な逆コンパイルを介してModdabilityを達成することがより価値がある理由がいくつかあります。
クラウドファンディングが継続的なサポートの流れをもたらして以来、進歩は安定しています。 2022年8月に完全に完了したTH01の逆コンパイルと、残りのゲームは時間の問題です。
長年にわたり、このプロジェクトは、元のコンパイラとPC-98ハードウェアを深く理解し、逆コンパイル自体がかなり機械的になっています。このプロジェクトがサポートする価値があり、取り組むことに興味を持っていることの両方を確実にするために、その焦点はZunの元のコードの細心のドキュメントとレビューにさらにシフトしました。プロジェクトブログは、すべての調査結果をより一般的に読みやすい方法で詳しく説明し、間違いなく主要な魅力になりました。ソースコードの再構成自体は、これらのゲームの根底にある深い研究の副産物にほとんど変わります。
プロジェクトもかなり実行可能で始まりました。これらのゲームの静的な英語パッチの開発中に、5つのゲームすべてにわたって使用されている2つの主要ライブラリを特定し、ソースコードを見つけました。これらは:
ZUNSP.COM ( ZUN.COM -4からアクセス可能)は、Promisence Soft's SPRITE16.COMのブランド変更バージョンで、16色のPC-98 EGCディスプレイドライバーバージョン0.04で、サンプルゲームストーミースペースにバンドルされています。 Master.libとC/C ++ランタイムだけで、すべての実行可能ファイルでかなりの量のコードを構成します。たとえば、Th05では、 OP.EXEのすべてのコードの74%、 MAIN.EXEのすべてのコードの40%になります。それはすでに私たちが対処する必要がないかなり多くのコードです。ゲーム全体で共有されている残りのコードを識別すると、ワークロードがさらに許容できる量になります。
Dosbox-XとNeko Project IIのデバッグ版を使用すると、ゲームを実行できる2つのオープンソースPC-9821エミュレーターもあります。これらは、PC-98の開発に関する古い本と実際のハードウェアに関する時折のテストとともに、ほとんどのハードウェア関連の質問に答えるのに役立ちました。
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クロスアウトファイルは、前のゲームではバージョンと同じです。 ongchk.comはKajaによるPMDサウンドドライバーの一部であるため、また分解する必要はありません。 Zun.comの少し完璧な再構築を許可するために、バイナリを保持する必要があります。
このプロジェクトには、元のPC-98リリースの資産データは含まれていません。コンパイルされた実行可能ファイルを実行するには、元のゲームの既存のコピーが必要です。
▶ master :Zunの元のコード、modまたはbugfixesなし(ここにいます!)
debloated :読みやすく修正しやすく、PC-98のバイナリをより速く構築するZunのコードの検索バージョン。膨満感や地雷のみを除去します。 Zunの元のコードからのすべてのバグと癖は、所定の位置に残っています。ポートはそのブランチから開始する必要があります。また、元のバイナリとの類似性を気にしないMODの推奨ベースでもあります。
anniversary : debloated取り、さらにバグを修正し、PC-98プラットフォームでよりスムーズでフリッカーのないゲームプレイエクスペリエンスを実現しながら、癖を残します。 MODとポートのポートの開始がさらに優れている可能性があります。
BossRush
th03_no_gdc_frequency_check :GDCクロックを5 MHzに設定してTH03を実行できます。元のゲームは2.5 MHzを実施しますが、実際のハードウェアでも機能的には必要ありません。
xJeePx :Xjeepxの2014年の英語翻訳パッチのコード変更。
th01_critical_fixes :TH01で2つの重要なバグを修正します。
th01_end_pic_optimize :TH01のカットシーンでの画像ブリットを元のランタイムの50%にスピードアップします。主に、単一のASM命令を書くことなく、ターボC ++ 4.0Jから最適なEGC駆動のブリットコードを導入する方法の例として機能します。 EGCは間違いなくこの仕事に最適なツールではありません。
th01_orb_debug :TH01のデバッグモードで次の情報を示します。
th01_sariel_fixes :元のコードの明確なロジックエラーから生じるTH01サリエルファイトで3つのスプライトグリッチを修正します。
th03_real_hitbox :TH03の衝突ビットマップを両方のプレイフィールドにレンダリングします。非常にプレイできません。
TH04ステージ5のゆうきemsクラッシュの修正:
th04_noems_crash_fix :TH04のMAIN.EXEの自己課されたメモリ限界を適切な量だけ増やし、1つのクラッシュを修正します。mem_assign_all :すべてのTH02-TH05実行可能ファイルの自己課されたメモリ制限を削除し、さらに、改造中に発生する可能性のある他の潜在的なメモリ外クラッシュを修正します。Th04 Kurumi分裂エラークラッシュの回避策:
th04_0_ring_ignoreth04_0_ring_as_single_bulletth04_0_ring_as_cap_bulletsth04_0_ring_as_gameoverTH04ステージ4マリサ分割エラークラッシュの回避策:
th04_marisa4_crash_stillth04_marisa4_crash_moveth04_marisa4_crash_warp community_choice_fixes :ゲームプレイやビジュアルに影響しないすべての「明白な」バグフィックスの組み合わせブランチ:
th01_critical_fixesth03_no_gdc_frequency_checkth04_noems_crash_fixさらに、TH04のDivide Errorエラーバグの次の回避策。コミュニティの投票によって選択されました。
th04_0_ring_as_single_bullet (投票結果)th04_marisa4_crash_still (投票結果) Borland Turbo C ++ 4.0J
これは最初に使用されていたコンパイラZunであったため、Zunの元のコードに少し完璧な実行可能ファイルにこのコードを決定的にコンパイルできるのは唯一のものです。 Borlandは、32ビットウィンドウで実行される16ビットDOSをターゲットにするクロスコンパイラを作成しなかったため、C ++パーツを16ビットDOSプログラムを使用してコンパイルする必要があります。
Rec98は、ターボC ++ 4.0Jを使用して、ハードコーディングされたスプライト用のコンバーターなど、ビルドパイプラインにカスタムツールを構築します。これらはビルドプロセスの一部としてネイティブに実行する必要があるため、それらを16ビットDOSプログラムにコンパイルし、64ビットオペレーティングシステムでエミュレートする必要があると逆効果に見える可能性があります。ただし、これはまだいくつかの理由で理にかなっています。
したがって、ネイティブC ++コンパイラに通常非常に重い依存性を追加することはほとんど意味がありません。
Borland Turboアセンブラー(TASM)、バージョン5.0以降、32ビットウィンドウ( TASM32.EXE )の場合
REC98は、まだ逆コンパイルされていないゲームコードのアセンブラーだけでなく、PC-98 TouhouのサードパーティライブラリとZun独自の手書きのないアセンブリコードにも必要です。ありがたいことに、Borlandの32ビットアセンブラーは16ビットコードに使用でき、64ビットと32ビットの両方のウィンドウでネイティブに実行され、16ビットTASM.EXEおよびTASMX.EXEツールよりも優れています。
サイドの利点として、ネイティブ32ビットWindowsツールを使用すると、ASMパーツはDOS 8.3コンベンションに準拠する必要のない長いファイル名を自由に使用できます。
MS-DOSプレーヤー(バンドル)
64ビットオペレーティングシステムにコードベースを構築するときに自動的に使用されるWindowsコンソールサブシステムでDOSコマンドラインツールを実行するための軽量エミュレータ。剥奪された性質にもかかわらず、Neko Project 21/Wの解釈X86コアではなくX86コアを使用しているため、Dosboxよりも著しく遅くなりますが、シームレスなコンソール統合はそれ以上のものです。
バンドルされたビルドは、rec98を構築するために特にプロファイル最適化されており、FPU、ページング、またはサイクルカウントなしで386のみをエミュレートするx86コアを縮小します。 Takeda Toshiyaのアップストリームビルドと比較して、このビルドは、完全な再構築のためにRec98ビルドプロセスを約60%、最大の翻訳ユニットと最大のバイナリをコンパイルおよびリンクするために約80%、中央値サイズの翻訳ユニットとバイナリの約70%を高速化します。また、2024年6月現在、上流のビルドで利用できなかったビルドシステムのコンテキストで、ターボC ++ 4.0Jを実行するために必要なバグフィックスも含まれています。
ライセンスとビルド情報についてはbin/README.mdを参照してください。
windows用(バンドル)
最小限の再構築を確保するために使用される正気の並列ビルドシステム。コードインジェクションを介して依存関係の完璧な追跡を提供し、コンパイラのファイルを開くsyscallsを引いて、すべての#include dファイルをビルド依存性グラフに自動的に追加できるようにします。これにより、ほとんどのmakeよりもはるかに優れており、この重要な機能が欠けているため、ほとんどすべてのプログラミング言語に想像できるものには本質的に適していません。特定のコンパイラに抽象化がないため、TUPはこのプロジェクトに必要な古代のボーランドツールにも完全に適合しています。
バンドルされた64ビットWindowsビルドには、2024年6月の時点で上流のリポジトリにマージされていないMS-DOSプレーヤーを介してDOSベースのビルドツールを実行するための重要なバグフィックスが含まれています。
ライセンスとビルド情報についてはbin/README.mdを参照してください。
サポートされているビルドプラットフォームのいずれかでbuild.bat実行するだけです。実行しているオペレーティングシステムに関係なく、正しいことを行います。必要なツールのいずれかがWindows PATHで見つからない場合、プロセスはエラーで中止されます。
最終的な実行可能ファイルはbinth0? 、オリジナルと同じ名前を使用します。それらを実行するには、同じディレクトリ内の各ゲームの元の資産が必要です。
64ビットX86では、ビルドプロセスではTUPを使用して最小限の並列再構築を使用しますが、すべてのDOSベースのビルドツールがエミュレートされます。 32ビットx86では、ビルドプロセスは常にコードベース全体を構築するシーケンシャルバッチファイルに戻りますが、すべてのビルドツールはネイティブパフォーマンスで実行されます。
ティア1 :定期的にテストされ、最良のサポートが保証されています。
ティア2 :機能し、サポートすることができますが、定期的にテストされていません。ビルドプロセスの重要なバグは無料で修正されます。
ティア3 :機能するはずですが、維持する負担。ビルド関連のバグの修正には資金が必要ですが、バグフィックスPRも同様に受け入れられる可能性があります。
ティア4 :深刻ないじくり回しなしでは、明示的にサポートされておらず、実行不可能です。専用の資金またはフォークが必要になると、PRは受け入れられる可能性は低いです。
Loader error (0000): Unrecognized Error
2つの既知の原因:
%WINDIR%System32autoexec.ntを編集することにより、上部メモリではなく、従来のメモリにロードするNTVDM DPMIドライバーを構成してみてください。
REM Install DPMI support
- LH %SystemRoot%system32dosx
+ %SystemRoot%system32dosx有効にするには、その編集後に再起動が必要です。
(ソース)
PowerShellまたはBashの代わりに、通常のcmd.exeシェルに構築してみてください。
CONTRIBUTING.mdを参照してください。