ほぼすべてのNintendo 64ゲームをネイティブPCポートとして再コンパイル可能に
(tomshardware.com)- 1996年に発売された Nintendo 64 ゲームを、エミュレーションではなくPCネイティブポートとして再コンパイルし、レイトレーシング、ウルトラワイド、高FPSといった改善を適用できるようになった
- GitHubのMr-Wiseguyが公開した N64Recomp と Zelda64Recomp が中核ツールであり、Zelda64Recompは The Legend of Zelda: Majora's Mask をPCに移植する
- この方式は2020年に公開された完全デコンパイルベースの Super Mario 64 PC Port とは異なるが、どちらもPCでネイティブ実行されるため、性能とエフェクトの正確性を高められる
- 手動デコンパイルは1人以上が何年もかけて作業する必要がある一方、N64Recomp はN64ゲームをより速くPCで実行可能な形に変えるアプローチである
- 成果物にはアセットが含まれないため、プレイには ROM が必要であり、Banjo-Kazooie、Rocket Robot、Superman 64 も実行例として挙げられている
N64ゲーム移植手法の変化
- 2024年になっても、Nintendo 64 のオリジナルハードウェアとゲームは愛好家コミュニティで継続的な関心を集めている
- 高度なN64プレイの次の段階は、エミュレーションではなく 再コンパイルされたPCポート になる可能性が高まっている
- GitHubのMr-Wiseguyが N64Recomp と Zelda64Recomp を公開した
- N64RecompはN64ゲームをPCネイティブポートにするための基盤ツールである
- Zelda64Recompは The Legend of Zelda: Majora's Mask をPCに移植し、N64Recompのグラフィックスおよび利便性向上を適用する
PCポートで可能な改善
- 再コンパイルされたPCポートは、元のN64ゲームにPC環境向けの改善を加えられる
-
本格的なレイトレーシング
- フレームレート制限の解除
- 適切なウルトラワイド対応
- PCで期待されるグラフィックスおよび利便性の向上
- Majora's Mask は、エミュレーション方式とネイティブPC再コンパイル方式におけるウルトラワイド動作の比較例として扱われている
-
Super Mario 64 PC Portとの違い
- 2020年に公開された完全デコンパイルベースの Super Mario 64 PC Port は、レイトレーシングやモデル全体の差し替えといった機能を可能にし、現在もMODが続いている
- 再コンパイルポートは、SM64 PC Portのようなデコンパイルポートとは制作方式が異なる
- どちらの方式もPCでネイティブ実行され、オリジナルハードウェアと比べて性能とエフェクトの正確性を高めつつ、エミュレーションに期待されるPC向けの改善を提供できる
N64Recompが重要な理由
- N64Recompは、再コンパイルというアプローチによって エミュレーションとネイティブポートの長所 を同時に狙うツールである
- N64ゲームを手動でデコンパイルするには、1人以上が何年も作業しなければならない
- より効率的にN64ゲームをPCで素早く実行可能な状態へ変えるツールは、保存活動に携わる人々にとっても有用になり得る
RT64と実行例
- Darioは、N64Recompや一部のN64エミュレータで活用される RT64プラグイン を開発した人物である
- Darioの投稿によれば、Wiseguyは完全なデコンパイルなしでN64ゲームのPCポートを作るツールを1年間、非公開で開発していた
- 成果物にはアセットが含まれず、プレイには ROM のみが必要である
- 実行例として次のゲームが挙げられている
- Banjo-Kazooie
- Rocket Robot
- Superman 64
N64エコシステムの別の動き
- N64ライブラリとオリジナルハードウェアのファン向けの別の進展も続いている
- オープンソースの SummerCart64 は既存コンソール向けのフラッシュカートで、64DD対応 も実装している
- 実機と互換性のあるホームブリューN64ゲームやROMハックも引き続きリリースされている
- 30人のファイターを提供する Smash Remix
- Mario 64エンジンの再構築プロジェクトである Peach's Fury
2件のコメント
Hacker News の意見
このツールを使うには、依然としてまず ROM を逆アセンブルし、再コンパイルできるように大量の注釈を付ける必要がある
ツール自体は素晴らしいが、任意の ROM をほぼワンクリックでスタンドアロン実行ファイルにできるかのような誇張は行き過ぎに見える
投稿の動画では、名前のない N64 ゲームを再コンパイルして問題なく動かしており、別途注釈も必要なさそうだった
ROM は文字通り読み取り専用なので、ROM を入れてネイティブポートを得る、という形が可能になる
バイナリからバイナリへの変換のほうが直感的だし、人間の入力も不要に思える
本当にすごい
N64 のデコンパイルのために作られたさまざまな基盤ツールが、ほかのシステムのデコンパイルパッケージへ広がっている
最近見た https://decomp.me/ は、複数のシステム向けに関連 SDK とハードウェアプリセットを備えた共同デコンパイルをサポートしている
今後数年で、より多くのシステムでもこうした流れが出てきそうだ
これが出たときに見たが、ROM ハック界隈を追っていない立場としては、なぜこのアプローチがここまで遅れて出てきたのか気になる
アセンブリ命令を C に翻訳してから再コンパイルするのは、初期に試してみるべき明らかな方法に見えるが、以前は不可能で、今になって可能にした別のブレークスルーがあったのだろうか
GitHub リポジトリをざっと見ると、レイトレーシング対応に内部で rt64 を使っているようだ（https://github.com/rt64/rt64）
rt64 は GPU をエミュレートするためにウーバーシェーダー技法を使っており、この素晴らしい記事がウーバーシェーダーとは何か、なぜ必要なのか、どれほど大変なのかを説明している: https://dolphin-emu.org/blog/2017/07/30/ubershaders/
ある機械語から別の言語へ静的再コンパイルすることは、実務上非常に難しいか、一般には不可能な領域にある [1]
こうした再コンパイルを正しく行うには、再コンパイルを容易にしてくれるバイナリ側の助けも必要で [2]、そのうえで動作させるためのパッチも必要になる [3]
動的再コンパイルにはこうした問題がないため、元のバイナリとアセット、つまり ROM を入れれば、たいていエミュレートされたソフトウェアを作れる
この解法がどれほど汎用的なのかについては混乱が多い
再コンパイルや移植をはるかに容易にし、作業量を減らすという点では非常に印象的で価値も大きいが、従来型エミュレーターの必要性を置き換えるものではない
[1]: https://cs.stackexchange.com/questions/155511/why-is-static-...
[2]: N64 ゲームのバイナリは、一般的な静的再コンパイルを難しくするさまざまな要素を偶然避けており、このアプローチの助けになっている可能性があるが、実際のところはよく分からない
[3]: Majora's Mask の再コンパイルリポジトリには、動作のために手作業で作られたパッチが多数含まれている: https://github.com/Mr-Wiseguy/Zelda64Recomp
Jamulator はすでに 2013 年に NES 向けにこれをやっていたが、誰もあまり気にしていなかったように思う
https://andrewkelley.me/post/jamulator.html
Android で Windows プログラムを実行する Winlator もある
https://github.com/brunodev85/winlator
それから記事でリンクされている YouTube 動画は AI 音声を使っているのだろうか？
N64Recomp の GitHub リポジトリ[0]にはこう書かれている:
"This is not the first project that uses static recompilation on game console binaries. A well known example is jamulator, which targets NES binaries."
[0]: https://github.com/Mr-Wiseguy/N64Recomp
そういう状況では、再コンパイルは物事を複雑にするだけで、利点は大きくない
N64 は固定ハードウェアなので少し簡単
それでもこのプロジェクトは依然として RDP にエミュレーションを使っている
生成された RSP マイクロコードをどう扱っているのかは分からないし、もしかすると扱っていないかもしれない
多くのゲームは単に公式ライブラリを使っていた
Jamulator が Zelda 向けの同様の改善機能と一緒に出ていたら、ずっと人気が出ていただろう
関心は方式そのものよりも、今それで何ができるのかからより多く生まれているようだ
動画のナレーションは、単に Nerrel という実在の人物が担当している
最近の AI 音声があまりに良くなったので、こちらが期待する話し方をしない人を AI ではないかと疑うようになっているのは、興味深い意味でかなり驚きだ
ナレーションが非常に平坦なので昔から AI のように聞こえていて、それがユーモアと混ざる感じが好きだ
すべてのゲーム実行ファイルが WebAssembly のように OS 非依存だとよいのに
例えば GameAssembly のようなもの
今では新しい macOS では 32 ビットゲームを遊べず、Wine でも 32 ビット Windows ゲームが動かない
Wine/Crossover でまともに動かせる 64 ビットの
.exeファイルを見つけるのもほとんど不可能だコンソールの場合、特に古いタイトルやプラットフォーム独占作は、非常に低レベルの GPU 実装詳細に依存していることが多い
さらに古いコンソールには、単純な入出力以外にも重要な仕事をする専用チップがあった
例えば SNES のサウンドチップは、CPU や GPU と並行して自分の小さなプログラムを実行する、完全に独立した CPU だった
もちろん今後のすべてのゲーム開発に高レベル仮想マシンを義務付けることはできるだろうが、コンソールのハードウェア仕様が固定されている点を考えると、最新グラフィックスを活用しようとするタイトルには競争力がないだろう
Debian では次を実行する必要があった
dpkg --add-architecture i386 && apt-get updateその後
wine32パッケージをインストールすればよいゲームにはグラフィックス API、ウィンドウ API、入力 API、サウンド API、ディスク API など、さまざまな API が必要になる
ときにはアンチチートやコピー防止機能のためにカーネルモジュールも必要になる
残念なのは、オープンソース OS が、開発者がコードを一度だけ書いてテストすればどこでも動作するような共通 API セットを提供しようとしていない点だ
Flatpak はあるが、私の理解では API セットを提供するものではなく、仕様やドキュメントなしに Linux ディストリビューションを仮想マシン内に包むものに近い
見苦しいし、Linux ではない小さな OS との互換性もない
M1 mini で GTA IV を動かした
PlayOnMac がインストールする 32 ビット版 Wine の中に、何らかの「32 on 64」エミュレーションが入っているようだが、検索が難しすぎて実際にどう動いているのかは分からない
Mac が古い Mac プログラムより古い Windows プログラムとの互換性のほうが高いのは面白い
JVM がなかったら、Minecraft が Linux や BSD 系などをサポートしていたかは疑問だ
JVM 版ではない Bedrock Edition は Windows、コンソール、スマートフォンをサポートしているが、明らかに可能なはずなのに macOS はサポートしていない
これが最終的にLinuxでも動作して、かなり低スペックな携帯機でN64ゲームを安定して遊べるようになるといいな。
N64はエミュレーションが難しいことで悪名高いが、プラットフォーム向けにネイティブビルドすれば性能問題は消える。
例はこちらで見られる: https://github.com/Mr-Wiseguy/Zelda64Recomp?tab=readme-ov-fi...
N64エミュレーションの詳細はよく知らないが、2010年代初頭からN64エミュレータを完全に動かしてきた。
主に有名な古典作品しか遊んでいないので、よりニッチなタイトルの性能はよく分からない。
1時間ほどプレイしたが問題なかった。
自分でテスト済み。
GoldenEyeのようなゲームには、これはかなり有用かもしれない。
変なジョイスティック入力を前提にしているのでPCでは遊びにくいが、他のFPSのように普通のマウス操作ができるネイティブGoldenEye移植があれば素晴らしそうだ。
照準のモード切り替え方式と、カーソルが移動してから中央に戻るまでの時間が、ゲームの面白さの一部になっている。
PC FPSのように走りながら自由照準できるようになると、キャンペーンがその前提で設計されているので、むしろ壊れてしまいそうだ。
どこで立ち止まって照準するかを選び、照準中に冷静さを保つのが魅力だ。
ただしモード切り替えは維持し、マウスが 1) スティック左右のようにBondを回転させ、2) Rを押して「照準モード」のときだけカーソルを制御するなら面白いかもしれない。
正直、シューターがみなQuake式のWASD+マウス自由照準へ一直線に進んだのは惜しい。
モード切り替え方式が、GoldenEyeで好きな身体的な感覚を生んでいる。
https://github.com/Graslu/1964GEPD/releases/tag/latest
Perfect Darkでも動く。
かなり興味深いが、これがMiSTerでちゃんと動作するConker版につながり得るのか気になる。
例えば、これをデコンパイル補助に使って、誰かが修正版を作れるだろうか？
エミュレータと比べた利点が何なのか気になる。
結局、事前に翻訳しておく形のエミュレータではないのか？
こういう方式は昔Bleemのようなものでもあったし、性能面で有利かもしれないが、現代のPCでは優れたエミュレータならだいたいうまく動く。
https://en.wikipedia.org/wiki/Bleem!
N64エミュレータの目標は通常、元のコンソールの動作を正確に再現することだ。
逆に、SM64、OOT、MMを60fps、ワイドスクリーン、テクスチャパック、ランダマイザーなど、さまざまなグラフィック改善付きで遊びたい人も多い。
そうした人たちにとって、これらのゲームがもともとN64で動いていたという事実は、実質的に重要ではない。
むしろ障害に近い。
N64のグラフィックパイプラインはエミュレートが厄介で、現代的な改善を積極的に妨げる。
このプロジェクトは、ゲーム自体を現代的に扱い、N64中心の要素を方程式から完全に取り除くことに、より焦点を当てているように見える。
今ではコンピュータがN64よりはるかに速いので、差は目立たないかもしれない。
一般的なエミュレータは事前にコンパイルするのか、それともJITを使うのか？
そうでないなら、なぜやらないのか気になる。
このアプローチ、つまり事前コンパイルには大きな利点がありそうだ。
ただしTeknoParrotがそのように動作しているのでなければ、事前翻訳についてはよく分からない。
例えばTeknoParrotを使えば、ELFバイナリを使うLinuxアーケードゲームをWindowsで実行できるが、アーキテクチャが同じなので、どちらにせよエミュレーションとは呼ばないだろう。
インタプリタ実行は、マシンのさまざまな部分の状態を表す仮想マシンを書き、精度レベルを変えながら、その状態を変更する命令を実行する方式だ。
オタクたちの底力！ エミュレータにJITコンパイラを搭載する段階を超え、今やbinary liftingでCに変換した後、再コンパイルまで可能に