低下する状況を分類する
新しいエリア、演出、混雑した場面、メニュー切り替え、一定間隔など、いつ発生するかを書き留めます。発生するタイミングから確認する層を絞れます。
パフォーマンスの切り分けガイド
Ryujinx FPS低下は、シェーダーのコンパイル、グラフィックスバックエンド、解像度スケール、ドライバー、電源制限、Canaryの回帰などで起こることがあります。まず同じ場面を再現し、ほかの設定は固定したまま一つずつ確かめましょう。結果を次の確認に使えば、設定をまとめて変えて原因が分からなくなるのを防げます。
$ 症状:場面を特定
$ 基準:標準設定
$ 変更:一つだけ
$ 結果:維持または復元
すべての環境に共通するFPS値はありません。結果はゲーム、ビルド、PC、ドライバーによって異なります。
新しいエリア、演出、混雑した場面、メニュー切り替え、一定間隔など、いつ発生するかを書き留めます。発生するタイミングから確認する層を絞れます。
Canaryのビルド、ゲームの更新、セーブ、バックエンド、解像度スケール、コントローラーをそろえます。最初は標準設定とネイティブ解像度を使います。
シェーダーや翻訳データが作られたあとに同じルートをもう一度試します。最初だけの引っ掛かりは、常にFPSが低い状態とは限りません。
GPUドライバーを更新し、対応環境ではVulkanを試します。基準を記録してからOpenGLと比較し、スケールやModはこの間変更しません。
結果が悪化したら、別の設定を試す前に元の値へ戻します。これにより、動作していたプロファイルを保ち、変更の影響を判断できます。
サイト内の既存イラストで、バックエンドを条件をそろえて比較する考え方を示します。実測ベンチマークやRyujinxの実画面ではありません。
Ryujinx FPS低下を調べるときは、まずネイティブ解像度と既定プロファイルを使い、バックグラウンド処理を閉じてドライバーを確認します。同じ場面を2回実行してから判断してください。新しいエフェクトでだけ一時停止するなら、シェーダーのコンパイルが原因かもしれません。どの場面でも遅い場合は、CPU/GPU負荷、電源、バックエンド、解像度スケールを確認します。Canary更新後に始まった問題は、設定を消す前に以前の正常なビルドと比べます。
Ryujinx FPS低下が新しいエリアで一度だけ起きるなら、シェーダーのコンパイルやデータ読み込みが考えられます。同じ場面で低い状態が続く場合は、CPU/GPUの余裕、高いスケール、フレーム制限、ゲーム固有の負荷を確認します。FPS表示が変わらなくても、フレーム時間が不規則だと滑らかさは失われます。問題が更新後に始まった場合は、ゲーム、ドライバー、エミュレーターのバージョンを記録し、再起動後にも再現するか確かめます。
| 見える症状 | 最初に考える原因 | 次に試すこと |
|---|---|---|
| 新しい演出で一度だけ止まる | シェーダー生成、またはキャッシュの準備中 | 初回のあと同じルートを再試行 |
| どの場面でもFPSが低い | CPU/GPU、解像度、電源の制限 | ネイティブ解像度に戻し負荷を見る |
| VulkanかOpenGLの一方で発生 | バックエンドまたはドライバー | ほかの設定を変えずに比較 |
| Canary更新後に発生 | 回帰または設定の変化 | 以前動いていたビルドを確認 |
Ryujinx FPS低下を再現できる短いルートを選びます。混雑した街、戦闘エフェクト、カメラ移動、同じロード画面などが使えます。ビルド、ゲーム更新、バックエンド、スケール、VSync、MOD、電源設定を記録し、まず同じ条件で2回実行します。その後はネイティブスケール、VulkanとOpenGL、ドライバーなど一つだけ変えます。滑らかさ、画像の乱れ、音声を比べ、繰り返し改善した変更だけ残します。
Ryujinx FPS低下が続く場合も、原因を確かめられる最小の変更から試します。ネイティブ解像度はGPUの負荷を抑えた基準になります。安定してから余裕がある場合だけ2倍スケールを比較してください。対応ドライバーではVulkanを試し、Vulkanだけで乱れや停止が起きるならOpenGLを使います。バックエンドとスケールが決まるまではVSync、フィルター、MODを変えないでください。
| 変数 | 最初の安全な値 | 結果から分かること |
|---|---|---|
| 解像度スケール | ネイティブ1x | ピクセル処理がGPUを制限するか |
| グラフィックスバックエンド | 対応時はVulkan | ドライバー経路が安定性に影響するか |
| VSyncまたは上限 | 基準の値を維持 | FPS値よりフレーム間隔が問題か |
| ゲーム別Mod | 診断中は無効 | 特定パッチがタイミングに影響するか |
Ryujinxは、新しい場面やエフェクトが出るとプレイ中にシェーダーを生成することがあります。その間だけ止まり、同じ内容を再訪すると軽くなる場合があります。公式ドキュメントはProfiled Persistent Translation Cache(PPTC)についても説明しており、十分な過去の起動後に翻訳処理を再利用します。初回を準備時間として扱い、2回目や3回目と比べてください。出所不明の共有キャッシュは、ゲーム更新、ビルド、バックエンドに合わない可能性があるため使いません。キャッシュが準備されたあとも遅い場合は、ドライバー、CPU/GPU負荷、スケール、ビルドを確認します。
エミュレーターの設定だけでハードウェア性能を増やすことはできません。安定版の新しいドライバーを入れ、ノートPCでは意図したGPUが選ばれているか確認します。省電力、低いバッテリー残量、熱による制限、バックグラウンド録画は動作クロックを下げることがあります。Steam DeckやLinuxではゲーム別の電源・リフレッシュプロファイルを固定し、Windowsではエミュレーター、ドライバー、電源プランを同時に変更しません。表示できる場合はCPUとGPUの使用率を見ます。GPU負荷が低いのにFPSも低ければCPUやゲーム側、高スケールでGPUが張り付くなら描画負荷が候補です。これは次のテストを選ぶための目安で、故障の断定ではありません。
Ryujinx FPS低下がCanary更新後に始まった場合は、設定ミスと決めつけず回帰を調べます。現在と以前の正常なビルドを用意し、同じセーブ、場面、バックエンド、スケールで比べます。新しいビルドだけで起きるなら、両方のバージョンと再現手順を記録してください。両方で起きる場合は、ローカル設定、ドライバー、MOD、キャッシュ、ゲーム固有の制限を確認します。
診断手順は、すべてのSwitchゲームが一定のフレームレートに達することを保証しません。CPU負荷の高いタイトル、エミュレーション上の制限がある場面、ビルドやドライバーの不具合があります。60 FPS Modは特定ゲームのタイミングを変えるもので、一般的な性能修正ではありません。prod.keys、ファームウェア、更新データ、DLC、ゲームダンプ、コントローラーの問題は別の確認事項です。このサイトは著作権保護されたゲーム、キー、ファームウェア、Mod、キャッシュを配布しません。自分の機器から取得したファイルを使い、セーブをバックアップし、ビルド固有の挙動は公式資料で確認します。
手順は公式FAQと設定ガイドを参考にし、テスト表は原因を分けるための編集上の方法として掲載しています。
ネイティブスケールと標準設定から始め、GPUドライバーを更新し、シェーダーを準備したあと同じ場面を再実行します。バックエンドや設定は一度に一つだけ試し、同じテストで改善した場合だけ維持します。
新しい演出でシェーダー生成やデータ読み込みが始まることがあります。初回のあと同じルートを試してください。キャッシュ準備後も遅ければ負荷、スケール、ドライバー、ビルドを確認します。
対応する新しいドライバーではVulkanが最初の比較候補です。公式FAQは特にAMDまたはIntelのGPUで推奨していますが、全ゲームで速くなる保証はありません。同じ場面で比べ、OpenGLの方が安定する場合はそちらを使います。
いいえ。Modは特定のゲームのタイミングを変更し、そのゲーム更新との一致が必要です。まずハードウェア、ドライバー、バックエンド、スケール、シェーダーを確認します。
CPU、フレーム上限、シェーダーや翻訳処理、ゲーム自体が制限になる場合があります。準備後のプレイを比べ、CPUとGPUの両方を見ます。
最初の手段ではありません。正常なキャッシュを消すと初回のカクつきが増えることがあります。バックアップを取り、再現性のある破損や回帰が示す場合だけ対象のキャッシュを削除します。
ゲーム、バックエンド、スケールをそろえ、以前のビルドで同じ場面を試します。新しいビルドだけ失敗するなら、戻すか報告する前にバージョンと再現手順を記録します。