Classifica il calo
Annota se succede in una nuova area, durante un effetto, in una scena piena o aprendo un menu. Il momento orienta il test.
Guida alla diagnosi delle prestazioni
I cali di FPS su Ryujinx possono dipendere da shader, backend, scala, driver, alimentazione o regressioni Canary. Ripeti una scena, cambia una variabile e scegli il controllo successivo dal risultato.
$ sintomo: individua la scena
$ base: profilo predefinito
$ modifica: una variabile
$ risultato: mantieni o ripristina
Questa guida non promette un valore FPS universale. Il risultato dipende da gioco, versione, hardware e driver.
Annota se succede in una nuova area, durante un effetto, in una scena piena o aprendo un menu. Il momento orienta il test.
Mantieni uguali build Canary, aggiornamento, salvataggio, backend e controller. Parti dai valori predefiniti e dalla scala nativa.
Ripeti il percorso dopo aver generato shader e dati di traduzione. Uno scatto iniziale non significa FPS bassi permanenti.
Aggiorna il driver e prova Vulkan se supportato. Confronta OpenGL dopo aver registrato la base, senza cambiare scala o mod.
Se peggiora, ripristina il valore precedente prima di un altro tentativo. La prova resta chiara e il profilo funzionante è salvo.
Questa illustrazione esistente spiega un confronto controllato dei backend. Non è un benchmark né una schermata reale di Ryujinx.
Parti dalla scala nativa con il profilo predefinito, chiudi le attività in background e controlla il driver. Ripeti due volte la stessa scena. Uno scatto con un nuovo effetto indica spesso gli shader; FPS bassi ovunque richiedono controlli su CPU/GPU, alimentazione, backend e scala. Se è iniziato dopo un aggiornamento Canary, confronta la versione precedente funzionante prima di cancellare cache o cambiare file.
Uno scatto entrando in un’area può coincidere con shader o caricamento delle risorse. FPS sempre bassi indicano più spesso CPU/GPU, scala elevata, limite dei frame o un gioco impegnativo. Tempi irregolari possono sembrare un calo anche con contatore stabile. Dopo un aggiornamento del gioco, driver o emulatore, confronta le versioni. Annota scena, durata, audio e ripetibilità dopo il riavvio per scegliere la prova successiva.
| Schema osservato | Prima ipotesi | Controllo successivo |
|---|---|---|
| Scatto quando appare un nuovo effetto | Compilazione shader o cache fredda | Ripetere il percorso dopo il primo passaggio |
| FPS bassi in tutte le scene | Limite CPU/GPU, scala o alimentazione | Tornare al nativo e osservare il carico |
| Succede solo con Vulkan o OpenGL | Backend o comportamento del driver | Provare l’altro backend con lo stesso profilo |
| È iniziato dopo un aggiornamento Canary | Regressione o valore modificato | Confrontare la versione precedente funzionante |
Scegli un percorso breve che riproduca il problema, come un’area affollata, un combattimento o una transizione. Annota build, aggiornamento, backend, scala, VSync, mod e alimentazione. Fai un passaggio di base e ripetilo senza modifiche. Poi cambia una variabile, per esempio scala nativa, backend o driver. Confronta fluidità, errori visivi e audio; mantieni la modifica solo se il miglioramento si ripete.
Fai la modifica minima utile. La scala nativa riduce il lavoro della GPU e offre una base pulita. Prova 2x solo se il gioco è stabile e c’è margine. Vulkan è un primo test con driver compatibili; usa OpenGL se Vulkan causa artefatti o blocchi. Lascia invariati VSync, filtri e mod fino alla fine del confronto.
| Variabile | Primo valore prudente | Cosa indica il risultato |
|---|---|---|
| Scala di risoluzione | Nativa 1x | Se il carico di pixel limita la GPU |
| Backend grafico | Vulkan se supportato | Se il percorso del driver cambia fluidità o stabilità |
| VSync o limite | Mantieni il valore di base | Se il problema è il ritmo e non gli FPS grezzi |
| Mod per gioco | Disattivata durante la diagnosi | Se una patch influenza i tempi del titolo |
Ryujinx può compilare shader in una nuova scena o con un effetto, causando uno scatto che spesso diminuisce ripetendo il percorso. La documentazione ufficiale descrive PPTC, che riduce le traduzioni ripetute dopo avvii precedenti. Confronta il secondo passaggio. Se resta lento a cache calda, verifica driver, carico CPU/GPU, scala e build. Evita cache condivise da fonti sconosciute.
Un’impostazione non crea margine hardware. Installa un driver stabile e controlla che il portatile usi la GPU prevista. Risparmio energetico, batteria scarica, calore o registrazioni in background possono ridurre le frequenze. Fissa il profilo per gioco su Steam Deck o Linux; su Windows cambia una sola parte alla volta. GPU poco usata con FPS bassi può indicare limite CPU o del gioco; GPU satura ad alta scala indica costo di rendering.
Un nuovo calo su Canary può essere una regressione. Conserva la build attuale e quella precedente funzionante; confronta stessa partita, scena, backend e scala. Se fallisce solo la nuova, annota versioni e passaggi di riproduzione. Se falliscono entrambe, verifica configurazione, driver, mod, cache o limiti del gioco. Ripristina prima solo l’emulatore per mantenere una prova utile.
Questa procedura non garantisce una frequenza precisa in tutti i giochi Switch: alcuni pesano sulla CPU, altri hanno limiti di emulazione o bug di versione. Una mod 60 FPS riguarda un titolo, non le prestazioni generali. Chiavi, firmware, DLC e controller sono temi separati. Il sito non ospita giochi, chiavi, firmware, mod o cache protette; conserva backup e consulta le fonti ufficiali per dubbi sulla versione.
L’ordine segue la FAQ e la guida ufficiale di configurazione; la matrice è un metodo editoriale per distinguere le cause.
Usa scala nativa, aggiorna il driver e ripeti dopo il riscaldamento degli shader. Prova un backend o valore per volta e mantieni solo miglioramenti ripetibili.
Un nuovo effetto può avviare shader o caricare risorse. Ripeti il percorso; se resta lento a cache calda, controlla carico, scala, driver e build.
Vulkan è un primo test con driver compatibili, ma non garantisce più FPS. Confronta la stessa scena e tieni OpenGL se è più stabile.
No. La mod cambia i tempi di un gioco e aggiornamento specifici. Prima verifica hardware, driver, backend, scala e shader.
La scena può dipendere da CPU, limite dei frame, shader o gioco. Confronta un passaggio a cache calda e osserva CPU e GPU.
Non come prima scelta: eliminare una cache sana può creare nuovi scatti. Fai un backup e rimuovila solo se una prova ripetibile lo indica.
Confronta la stessa scena sulla build precedente, mantenendo gioco, backend e scala. Registra le versioni se fallisce solo quella nuova.