Classer la baisse
Notez si la baisse survient dans une nouvelle zone, pendant un effet, dans une scène chargée ou à l’ouverture d’un menu. Le moment oriente le test.
Guide de diagnostic des performances
Les baisses de FPS sur Ryujinx peuvent venir des shaders, du backend, de l’échelle, du pilote, de l’alimentation ou d’une régression Canary. Répétez une scène, changez une variable et choisissez le contrôle suivant selon le résultat.
$ symptôme : repérer la scène
$ base : réglages par défaut
$ changement : une variable
$ résultat : garder ou annuler
Ce guide ne promet pas un nombre universel de FPS. Le résultat dépend du jeu, de la version, du matériel et du pilote.
Notez si la baisse survient dans une nouvelle zone, pendant un effet, dans une scène chargée ou à l’ouverture d’un menu. Le moment oriente le test.
Gardez la même version Canary, mise à jour, sauvegarde, backend et manette. Commencez par les valeurs par défaut et l’échelle native.
Refaites le parcours après la création des shaders et des données de traduction. Un accroc initial n’est pas un faible débit permanent.
Mettez le pilote à jour et essayez Vulkan s’il est pris en charge. Comparez OpenGL après avoir noté la base, sans toucher à l’échelle ni aux mods.
Si le résultat se dégrade, restaurez la valeur précédente avant un autre essai. La comparaison reste claire et le profil fonctionnel est conservé.
Cette illustration existante explique une comparaison contrôlée des backends. Ce n’est ni un benchmark ni une capture réelle de Ryujinx.
Pour diagnostiquer une baisse de FPS sur Ryujinx, commencez à l’échelle native avec le profil par défaut, fermez les tâches inutiles et vérifiez le pilote. Rejouez deux fois la même scène. Un accroc lors d’un effet nouveau évoque souvent les shaders ; des FPS bas partout invitent à vérifier CPU/GPU, alimentation, backend et échelle. Si le problème suit une mise à jour Canary, comparez l’ancienne version fonctionnelle avant d’effacer un cache ou de modifier la configuration.
Une baisse de FPS sur Ryujinx à l’entrée d’une zone peut accompagner les shaders ou le chargement des ressources. Des FPS constamment bas évoquent plutôt CPU/GPU, échelle élevée, plafond d’images ou jeu exigeant. Des temps d’image irréguliers peuvent sembler saccadés même si le compteur reste stable. Après une mise à jour du jeu, du pilote ou de Canary, comparez les versions. Notez scène, durée, son et répétition après redémarrage pour choisir le prochain test.
| Motif observé | Première hypothèse | Contrôle suivant |
|---|---|---|
| Accroc lors d’un nouvel effet | Compilation des shaders ou cache froid | Refaire le même parcours après le premier passage |
| FPS faibles partout | Limite CPU/GPU, échelle ou alimentation | Revenir au natif et observer la charge |
| Baisse avec Vulkan ou OpenGL seulement | Backend ou comportement du pilote | Comparer l’autre backend sans toucher au profil |
| Début après une mise à jour Canary | Régression ou valeur modifiée | Tester la dernière version qui fonctionnait |
Pour mesurer une baisse de FPS sur Ryujinx, choisissez un parcours court qui reproduit le souci : zone dense, combat ou transition. Notez version, mise à jour du jeu, backend, échelle, VSync, mods et alimentation. Faites un passage de référence puis répétez-le sans changement. Modifiez ensuite une variable, comme l’échelle native, le backend ou le pilote. Comparez fluidité, défauts visuels et son ; gardez le changement seulement si l’amélioration se répète.
Une baisse de FPS sur Ryujinx se teste avec le plus petit changement utile. L’échelle native réduit le travail du GPU et fournit une base propre. Essayez 2x seulement si le jeu est stable et que le GPU a de la marge. Vulkan constitue un premier test avec un pilote compatible ; gardez OpenGL si Vulkan produit des artefacts ou blocages. Ne touchez pas à VSync, aux filtres ni aux mods avant la comparaison.
| Variable | Première valeur prudente | Ce que le résultat indique |
|---|---|---|
| Échelle de résolution | Natif 1x | Si la charge de pixels limite le GPU |
| Backend graphique | Vulkan s’il est pris en charge | Si le chemin du pilote change la fluidité ou la stabilité |
| VSync ou plafond | Garder la valeur de référence | Si le souci concerne le rythme plutôt que les FPS bruts |
| Mod par jeu | Désactivé pendant le diagnostic | Si un patch de titre influence le timing |
Ryujinx peut compiler des shaders lors d’une nouvelle scène ou d’un nouvel effet, causant un accroc qui diminue souvent au passage suivant. La documentation officielle décrit PPTC, qui limite les traductions répétées après des lancements précédents. Comparez deux passages. Si la zone reste lente cache chaud, vérifiez pilote, charge CPU/GPU, échelle et version. Évitez les caches partagés de sources inconnues.
Un réglage ne crée pas de capacité matérielle. Installez un pilote stable et vérifiez que le PC portable utilise le bon GPU. Économie d’énergie, batterie faible, chaleur ou capture en arrière-plan peuvent réduire les fréquences. Fixez le profil par jeu sur Steam Deck ou Linux ; sous Windows, changez une seule couche. GPU peu chargé avec FPS bas peut indiquer une limite CPU ou du jeu ; GPU saturé à forte échelle évoque le rendu.
Une baisse apparue sur Canary peut être une régression. Gardez la version actuelle et la précédente fonctionnelle ; comparez la même sauvegarde, scène, backend et échelle. Si seule la nouvelle échoue, notez les versions et les étapes de reproduction. Si les deux échouent, vérifiez configuration, pilote, mods, cache ou limites du jeu. Revenez d’abord sur le seul émulateur pour préserver la comparaison.
Cette méthode ne garantit pas un débit précis pour tous les jeux Switch : certains sollicitent le CPU, d’autres sont limités par l’émulation ou un bug de version. Un mod 60 FPS concerne un titre, pas les performances générales. Clés, firmware, DLC et manette relèvent d’autres guides. Le site n’héberge pas de jeux, clés, firmware, mods ou caches protégés ; conservez des sauvegardes et consultez les sources officielles pour les questions de version.
La procédure suit la FAQ et le guide de configuration officiels ; la matrice est une méthode éditoriale pour isoler les causes.
Une baisse de FPS sur Ryujinx peut venir des shaders, du backend, de l’échelle ou du pilote. Utilisez l’échelle native, mettez le pilote à jour et rejouez après le préchauffage. Testez une variable à la fois.
Un nouvel effet peut lancer les shaders ou charger des ressources. Refaites le parcours ; si le souci persiste cache chaud, vérifiez charge, échelle, pilote et version.
Vulkan est un premier test avec un pilote compatible, sans garantie de FPS supérieurs. Comparez la même scène et gardez OpenGL s’il est plus stable.
Non. Le mod change le timing d’un jeu et d’une mise à jour précis. Vérifiez d’abord matériel, pilote, backend, échelle et shaders.
La scène peut être limitée par le CPU, un plafond d’images, les shaders ou le jeu. Comparez un passage chaud et observez CPU et GPU.
Pas d’abord : effacer un cache sain peut créer de nouveaux accros. Faites une copie et ne supprimez que si un défaut répétable le justifie.
Comparez la même scène sur l’ancienne version, avec jeu, backend et échelle identiques. Notez les versions si seule la nouvelle échoue.