Nintendo Switchは2017年に発売された第9世代のコンソールで
据え置きでありポータブルでもある非常に画期的なゲーム機である。
その勢いは凄まじく発売当初も品切れで新品が定価よりも
高騰するほどであった。そんなニンテンドースイッチだが
最近ハックが成功されニンテンドースイッチ内で
ファミコン(FCEUMM)やスーパーファミコン(Snes9x)、
ゲームボーイアドバンス(VBA Next)などのレトロ機
動かせるようになったと話題になった。
ここで気になったのがならば『ニンテンドースイッチのエミュレータ』
は可能なのか?という点である、気になり調べた所さすがエミュレータ
すでに開発に取り掛かっているそうだ。
今回はニンテンドースイッチのエミュレーターの
開発具合と実現可能年数さらに現在開発に取り掛かっている
yuzu(ゆず)とRyujinxについてご紹介する!!
■ニンテンドースイッチエミュの動作状況
まず上の動画を見ていただきたい。
こちらは Nintendo Switchエミュレータ yuzu の起動動画になります。
まず起動できている段階ですごくないですか??
およそ1年しか経っていないシステムにとって、異常な開発スピードです。
Wii・ゲームキューブエミュレーターであるDolphinエミュレータを使って
ゲームをスムーズに実行するには、
開発時間がかかりニンテンドーWiiが発売された3年後、やっとの事で
Dolphinはシステムメニューを起動することができた。
現在ニンテンドースイッチのエミュレーターは2つ開発が進められて
『yuzu』 Windows、macOS、Linux
『Ryujinx』 Windows Git
『yuzu』 は3DSのエミュレータであるCitraチームが作成したクロスプラットフォームエミュレータでいくつかの自家製アプリが正しく動作しているため、3つの商用ゲームが正式に起動することが確認されています。しかしまだ信じられないほど遅いフレームレートで動作します
『Ryujinx』はWindows用にC#でプログラミングされたパブリックドメインエミュレータ。『yuzu』によく似ていますが、自家製のものがいくつかあり、『ぷよぷよテトリス』や『洞窟物語』のBinding起動することが確認されていますが、こちらも同様でフレームレートは遅いです。
現在『yuzu』 はダウンロードできますがゲームはプレイ
できなく、エラーがでます。『yuzu』 の使い方も紹介できないほどです
ニンテンドースイッチの開発年数は??実現可能まで??
最近のブログでは、yuzuチームは2つの別々の面でスイッチエミュレーションにどのように取り組んでいるかを説明しています。
『まず、フレームをレンダリングしようとしているところまで、より多くのゲームを起動し、次にNVIDIA Maxwell GPUをエミュレートしようとしています。このような単純なゲームであっても、Maxwellのエミュレーションは非常に困難であることが示されており、今後数ヶ月でこれが最大の焦点になると思われます。』
勿論これをクリアしても実際に快適にプレイできるまでは膨大な時間がかかります。
通常のエミュレータは早くて3-4年遅ければ6-7年掛かります。
しかしニンテンドースイッチのエミュレータは発売から1年で
ここまで開発が進んでいるので3-4年の実現はけして不可能ではないと!
ここからは開発状況です。
一般的な改善
ソフトウェア開発のベストプラクティスでは、可能な限りコードを再利用する必要があります。このルールに沿って、yuzuはCitraコードベースのフォークとして開始され、コアエミュレーションコードは取り除かれました。これにより、ゆずは、コアスイッチのエミュレーションに焦点を当てながら、非常に機能的なユーザーインターフェイスを持つことができますが、しばらくするとユーザーインターフェイスのコードがゆっくりと発散し始めます。何人かの人々がCitra、特に著名なLioncashから改善をもたらすために欠けていました.Lioncashはある期間にわたって、ゆずを最新の状態にするために多くの変更を加えました。我々はまた、新しいfmtlibベースのロギングバックエンド(感謝したいとシトラの最近の機能の一部に移植jroweboy&daniellimwsダイアログ、フルスクリーンレンダリングのサポート、およびテーマのサポート「について」)を、。
また、次のような機能を実装しました。
復号化されたNCAサポートが追加されました。OpenGL拡張機能は、システム要件が満たされていることを確認するためのチェックをサポートします。サポートされていない32ビットゲームが起動していないことを確認するために、64ビットのゲームチェックを行います。スイッチ固有のドッキングモード設定。
改良されたFPSカウンタ。
などなど。
これらの改善はすべて、多くの寄稿者の努力のためにのみ可能でした。
CPUエミュレーション
任天堂のスイッチはカスタムのNvidia Tegra SoCを搭載しています。初心者のために、SoC(システムオンチップ)は、CPU、GPU、メモリ、入出力ポート、ストレージなどのコンポーネントを1つのチップに統合します。スイッチのSoC(Nvidia ODNX02-A2)はTegra X1チップで、ARM Cortex-A57 CPUコア4個とARM Cortex-A53 CPUコア4個を搭載しています。CPUはARMアーキテクチャをベースにしていますが、これは既に文書化されています。最初にCPUエミュレーションにUnicornを使用しました。しかしUnicornは、コードをデバッグしている開発者を支援するためのもので、許容できるフレームレートでゲームを実行することはできません。真実を伝えて、LioncashはAArch64エミュレーションをより完全にするために、Unicornに関連する変更をバックポートしました。Unicorn(QEMU 2.12.50)のバージョンは、実際のメインラインUnicorn(QEMU 2.2.1)よりも数マイル先です。
開発者とユーザーのどちらも、エミュレータが遅くなることを望んでいません。そこで、MerryがCitraに書いた動的再コンパイラであるDynarmicにARMv8サポートを提供するために、才能のある開発者MerryMageとLioncashがしっかりと動いています。Dynarmicは当初から多くの異なるARM CPUで再利用できるように設計されていたので、高速で安定した再コンパイラーが必要なときには、すでに使用していたものをすでに知っていました。彼らの努力のおかげで、Dynarmicは現在多くのARMv8命令をサポートしており、CPUエミュレーション用にDynarmicを使用するように変更しました。近い将来、完全なARMv8サポートを実装するよう現在作業中です。
Dynarmicは一般的に高速ですが、それでもいくつかの命令の実装が欠けています。ダイナミックが欠落した命令に当たったとき、それはユニコーンにフォールバックしなければなりません。ユニコーンを使用することに落ちるのは、ユニコーンを直接使用するよりもさらに遅くなります!ユニコーンにフォールバックするには、DynarmicからすべてのCPU状態をUnicornにコピーし、Unicornを実行してから状態をDynarmicにコピーする必要があります。これらのフォールバックは本当に遅いです。Dynarmicですべての命令を実装すると、これらの命令は必要なくなり、CPUエミュレーションは現在よりもはるかに高速になります。Dynarmicへの最新のアップデートでは、ほぼすべてのゲームでパフォーマンスが大幅に向上しました。ゲームは場合によっては60FPSまで上がります。
私たちは2018年2月ごろ、商業ゲームがゆずで実行されているところまで行きました。エミュレートされたNVIDIA GPUサービスにコマンドリストを提出していたので、彼らはほとんど描画準備が整っていました。簡単な説明のために、コマンドリストはゲームがGPUハードウェアをどのように設定し、レンダリングを開始する準備ができているかをゲームに知らせる方法です。Subvは、GPUレジスタがどのように書き込みを行うのか、それを動作させるための通信プロトコルを調べる作業を多くしました。
前述のとおり、スイッチはMaxwellアーキテクチャに基づいたGPUを収容するNvidia Tegra Socを使用します。Nvidiaのハードウェアは独自のものであり、どのように動作するのかについては公開されていません。幸運なことに、MaxwellベースのGPUは3年前にリリースされました。これらのGPUを使用するデバイスは何百万もあります。Linuxコミュニティや他の多くの人々が、独自のハードウェアであるにもかかわらず、これらのGPU用のオープンソースドライバを作成しようとしました。彼らは、これらのGPUがどのように機能するかを知る上で、多くの足取りをしました。ヌーボーのプロジェクトは、NVIDIAのGPUとのSoCのTegraは家族のためにこれらのオープンソースのLinuxドライバを作成します。デスクトップ/ラップトップGPU用のLinuxドライバは、独自のOSを実行するSwitchのようなコンソール用のGPUドライバと同じではありませんが、かなり重複しています。次のようなツールもありましたenvytoolsとそのサブモジュールenvydis(逆アセンブラ)。これはシェーダのデコードに関する多くの研究を行った。envydisには、各シェーダ命令の実際の動作に関するドキュメントはありません。名前、デコード、およびパラメータだけです。これらのプロジェクトによって行われた作業は、GPUの初期エミュレーションを実現するのに役立ちました。
これらのプロジェクトの助けを借りて、私たちはGPUエミュレーションで良い進歩を遂げ、ハードウェアを構成するだけでなく実際にレジスタに書き込むことで、画面に三角形を描画する準備ができたことを示す描画呼び出しを提出するゲームを得ました。最も単純な2Dゲームでさえもはや2Dではありません。スイッチは最新のGPUを使用しているため、2Dを描画するハードウェアはありません。だから、ゲームでは代わりに2つの三角形を四角形にして、現在のスクリーンをテクスチャとしてレンダリングし、それを2つの三角形にブリッジします。このように、ゲームはまだ柔軟な2Dゲームですが、GPUが提供する高速の3Dレンダリング機能を利用することができます。
グラフィックを表示する最初のゲームは、2月下旬?3月初旬頃に “Puyo Puyo Tetris”でした。ゲームはこの種のジェネリックを呼び出すwrite三角形のバッチをレンダリングしたことを示す描画レジスタに渡します。だから我々は描画をしていることを知っていたので、これらの三角形をどのようにデコードしてスクリーンにレンダリングするかを理解しなければなりませんでした。今日の終わりに、Switchは最新のGPUを使用しており、最新のGPUと同様に、プログラム可能なパイプラインを使用しています。プログラム可能なパイプラインは、ゲーム開発者にフル機能のプログラミング言語でグラフィックスパイプラインのいくつかを制御する能力を与えます。これらのプログラムはシェーダと呼ばれます。ゲーム開発者はGLSLやHLSLなどの言語でシェイダーを作成し、グラフィックス・ドライバーはこれらをGPU固有のアセンブリ言語にコンパイルします。シェーダは、ゲーム開発者にジオメトリの描画方法や、画面上のピクセルの色付け方法を変更する機能を提供するのに本当に便利です。
シェイダーがシーン全体にどれだけ影響を与えるかによって、GPUエミュレーションの開発は三角形を扱うだけでなく、シェーダーを扱うことについても重要です。より多くのグラフィックス出力を得るためにシェイダープログラムを実際に実装しなければなりませんでした。つまり、各シェーダーの命令を逆コンパイルする必要がありました。あなたが思っていた場合、任天堂のスイッチゲームはプリコンパイルされたシェーダバイナリで構築されているので、元のプログラムを実行するだけではありません。その代わりに、シェーダの命令を分析し、それを再び高水準のシェーダコードに戻すための斬新な方法を見つけなければなりません。各シェーダの指示が意味することを理解することは簡単ではありませんでした。なぜなら、これはNvidiaのすべてのプロプライエタリなコードだったからです。私たちはgdkchanとたくさん仕事をしました彼はこれで少し進歩を遂げ、ヌーボーとenvytoolsに基づいてGPUデータをデコードする方法をすぐに学びました。envytoolsとenvydis(逆アセンブラ)は、MaxwellベースのGPUでシェーダがどのように動作するかについてのリバースエンジニアリングを行ったため、命令の解読の大部分は既にわかっていますが、常にそうではありません。
yuzuでの実際のシェーダの実装では、エミュレートされた3DシェーダをGLSLに変換してホストGPU上で実行できるシェーダ再コンパイラであるCitraに最近追加されました。CPU上でこれらのシェーダプログラムを実行する代わりに、これらのシェーダをOpenGL GLSLに変換してそのままGPUにアップロードします。GPUは何千もの頂点に対してこれらのプログラムを並列に実行するように設計されているので、これは優れていますが、CPUはそうではありません。Citraでは、少なくとも2015年以降、GPUでフラグメントシェーダを実行していましたが、頂点シェーダとジオメトリシェーダはCPU上で実行されていました。3DS頂点シェーダとジオメトリシェーダはコーナーケースを説明するのが非常に難しく、リバースエンジニアリングの努力が正しいことを確認するまでには長年かかりました。そうすることで、私たちが確信できないことに取り組む努力を無駄にする必要はありませんでした。Citraの機能について詳しく知りたい場合は、そのブログの記事をチェックしてください(ここ)。
しかし、スイッチのGPUは現代的であり、ソフトウェアでこれを行うには強力すぎるので、これはゆずの場合のオプションではありません。2018年4月頃には、「Puyo Puyo Tetris」に少しのグラフィックスを表示するために実装されたシェーダの指示を十分に得ることができました。それはそれほどではなく、ちょうどレンダリングされSEGA logo、Tetris logoその後かなり掛かった。さらに、「Cave Story」や「Issacのバインディング」などの簡単な2Dゲームを起動することもできました。
実装したもう1つの新機能はconstbuffer、Subvによるシェーダのサポートでした。私たちは、UIや3Dモデルのような機能のために、さまざまな三角形のために再利用したいシェーダプログラムを用意しています。すべてのものに個別のシェーダを持たせるのは効率的ではありません。代わりに、すべてのものに再利用できるシェーダプログラムを2つ用意することができます。したがって、シェーダのconstbufferサポートはOpenGL uniformと同等ですuniform buffer objects (UBO)。ユニフォームは一般に、シェーダーに一定のデータを提供する方法であり、シェーダーも再構成するために使用することができます。
初期レンダリングのサポートとブレンドのサポートは、バニーによって行われました。ブレンドはアルファ透明度に使用されます – GPUレジスタの書き込みをOpenGL呼び出しに変換します。「Puyo Puyo Tetris」のバグが修正されSaving…ました。左下のアイコンには奇妙なボックスがあります。最初のテクスチャのサポートはSubvによって行われ、主にメモリからテクスチャを読み込み、デコードしてOpenGLにアップロードすることに関係していました。
ラスタライザキャッシュを使用すると、エミュレートされたスイッチメモリから使用されるたびにホストGPUにテクスチャをアップロードするのに計算コストがかかります。アップロードする前にテクスチャをデコードして解凍してから、CPU RAMからGPU RAMにメモリをコピーする必要があります。通常のPCゲームのハードウェアでの動作と同様に、GPUメモリにテクスチャを保持する方がはるかに効率的ですが、エミュレーションではやや難解です。これは、ゲームがいつテクスチャを変更したり変更したりするかわからないためです。bunneiはこれらのテクスチャをキャッシュする作業の大半を行ったので、テクスチャがOpenGLにアップロードされるとGPUメモリに保存され、それを追跡します。CPUまたはエミュレートされたスイッチのカーネルが、テクスチャがアップロードされたメモリアドレスを読み書きするとき、私たちは何をする必要があるかをチェックし、必要に応じてテクスチャをリロードしてください。これはフレームバッファにも適用されます。これは、ゲームでテクスチャとして使用できる場合があるためです。このキャッシングが存在しない場合、すべての描画をOpenGLメモリ(ホストGPU空間)にすべての描画でアップロードし、最後のフレームバッファをエミュレートされたスイッチメモリ(??CPU空間)にコピーして、フレームバッファ用。
主にCitraのラスタライザキャッシュに基づいていたため、ラスタライザキャッシュに対するいくつかの修正がありました。3DSが使用する圧縮テクスチャ形式はデスクトップGPUでは一般的にサポートされていないため、Citraのラスタライザキャッシュはアップロードしてキャッシュする前に圧縮テクスチャをデコードします。しかし、スイッチGPUは、デスクトップのOpenGLと同じテクスチャ形式の多くをサポートしているので、それらをデコードせずにアップロードすることで高速化しました。当初、このサポートはちょうどCitraのキャッシュにハッキングされていましたが、これは常に正常に機能しませんでした。1つの例は、 “Splatoon 2″のイカのテクスチャであり、これはSubv。また、「スプラットーン2」でイントロの背景テクスチャの色を入れ替えるために使用される、カラーコンポーネントを交換するためのテクスチャカラースウィズリングも実装しました。そう、これを実装する前に、色はすべて間違っていました。私たちは以前に逮捕された “Sonic Mania”イントロを修正したShaderサポートでYUV2ビデオの再生を修正しました。コンポーネントマスクと呼ばれるフィールドパラメータを実装する必要がありました。TEX/TEXSシェーダ命令を使用して、YUV2ビデオを適切にデコードします。また、テクスチャラップモードを実装しました。これは、三角形のテクスチャをミラーリングするか繰り返すかを指定する機能を提供します。
すでに実装されている他にもたくさんのものがあり、実装する必要があるものがたくさんあります。スイッチのGPUはかなり進歩しているので、数多くのテクスチャフォーマット、頂点フォーマット、多数のレジスタ、異なるコンフィギュレーションモード、実装が必要なシェーダ命令があります。
上記のもの以外にも、yuzuのGPU HLE(ハイレベルエミュレーション)にはさらに多くの変更が加えられました。これらのバグの修正や修正は、ゲームごとの実験ベースで行われました。私たちがさらに進歩するにつれて、私たちは実装を修正し、yuzuのエミュレーションの精度を向上させていきます。私たちが今までに進めてきた進歩はすべて、yuzuの貢献者とスイッチのハッキングコミュニティの善良な人々の努力のおかげです。
DarkLordZachによる仮想ファイルシステム(VFS)(ここ)
仮想ファイルシステム(VFS)は、実際のファイルが格納されている場所の詳細を隠すことを可能にする抽象レイヤーです。VFSの目的は、エミュレートされたスイッチファイルシステムが、エミュレートされたFSコード内の何も変更することなく、多くの異なるタイプのバックエンドを読み書きできるようにすることです。素人の言葉で言えば、このゲームではスイッチのファイルへの読み書きはまだ考えられますが、実際にはzipファイルやユーザーが追加するカスタムmodから読み取ることができます。これにより、アップデート、DLC、新しいフォーマット、暗号化などのサポートが少し容易になります。DarkLordZachは数週間VFSを片手に仕事をして成功させました。
DarkLordZachによるタッチスクリーンサポート(こちら)
DarkLordZachは様々なバグ修正や機能に非常に積極的に取り組んでおり、テストゲームでも手を貸しています。彼の最新の貢献は、ゆずのためのタッチスクリーンのサポートの形で来ます。この機能により、yuzuは入力をタッチするためのマウスクリックをエミュレートし、物理的なタッチスクリーンを使用すると入力デバイスとしても使用できます。
雑
これらの改良点とは別に、さまざまなゲームでバグやデッドロックを修正した複数のPRがありました。Super Mario Odysseyでグラフィックスを出力し、関連する問題を修正し、タイトルスクリーンに多くの新しいゲームを立ち上げ、Doomのようなネットワークに依存しないゲームを起動し、SVCやシェーダの手順をほとんど実行せず、コントローラのサポート、より多くの最適化を行いました。貴重な貢献をしたすべての寄稿者に感謝し、彼らの努力に拍手を送ります。