Classifique a queda
Anote se ocorre numa área nova, durante um efeito, numa cena cheia ou ao abrir um menu. O momento orienta o teste.
Guia de diagnóstico de desempenho
A queda de FPS no Ryujinx pode vir de shaders, backend, escala, driver, energia ou regressão do Canary. Repita uma cena, mude uma variável e escolha a próxima verificação pelo resultado.
$ sintoma: identifique a cena
$ base: perfil padrão
$ mudança: uma variável
$ resultado: manter ou reverter
Este guia não promete um número universal de FPS. O resultado depende do jogo, da versão, do hardware e do driver.
Anote se ocorre numa área nova, durante um efeito, numa cena cheia ou ao abrir um menu. O momento orienta o teste.
Mantenha o mesmo build Canary, atualização, salvamento, backend e controle. Comece com valores padrão e escala nativa.
Repita o percurso após gerar shaders e dados de tradução. Um engasgo inicial não significa FPS baixos permanentes.
Atualize o driver e teste Vulkan se houver suporte. Compare OpenGL após registrar a base, sem mudar escala ou mods.
Se piorar, restaure o valor anterior antes de outra tentativa. Assim a comparação fica clara e o perfil funcional é preservado.
Esta ilustração existente explica uma comparação controlada de backends. Não é benchmark nem captura real do Ryujinx.
Comece com escala nativa e perfil padrão, feche tarefas em segundo plano e confira o driver. Repita a mesma cena duas vezes. Engasgo apenas com efeito novo costuma indicar shader; FPS baixos em todas as cenas pedem uma checagem de CPU/GPU, energia, backend e escala. Se começou após atualização do Canary, compare o build anterior funcional antes de apagar cache ou mudar arquivos.
Um engasgo ao entrar numa área pode coincidir com shaders ou carregamento de recursos. FPS sempre baixos apontam mais para CPU/GPU, escala alta, limite de quadros ou exigência do jogo. Tempos irregulares também parecem queda mesmo com o contador estável. Após atualizar jogo, driver ou emulador, compare as versões. Anote cena, duração, áudio e repetição após reiniciar para escolher o próximo teste.
| Padrão observado | Primeira hipótese | Próxima verificação |
|---|---|---|
| Engasgo quando surge um efeito novo | Compilação de shaders ou cache frio | Repetir o mesmo percurso depois da primeira passagem |
| FPS baixos em todas as cenas | Limite de CPU/GPU, escala ou energia | Voltar ao nativo e observar o uso do sistema |
| Só ocorre com Vulkan ou OpenGL | Backend ou comportamento do driver | Testar o outro backend com o mesmo perfil |
| Começou após atualização Canary | Regressão ou padrão alterado | Comparar com a versão anterior funcional |
Escolha um percurso curto que reproduza o problema, como área movimentada, combate ou transição. Anote build, atualização, backend, escala, VSync, mods e energia. Faça uma passagem de base e repita sem mudanças. Depois altere uma variável, como escala nativa, backend ou driver. Compare fluidez, falhas visuais e áudio; mantenha a mudança apenas se a melhora se repetir.
Faça a menor mudança útil. A escala nativa reduz o trabalho da GPU e cria uma base limpa. Teste 2x somente se o jogo estiver estável e houver margem. Vulkan é um primeiro teste em driver compatível; use OpenGL se Vulkan causar artefatos ou travamentos. Deixe VSync, filtros e mods iguais até concluir a comparação.
| Variável | Primeiro valor prudente | O que o resultado indica |
|---|---|---|
| Escala de resolução | Nativo 1x | Se a carga de pixels limita a GPU |
| Backend gráfico | Vulkan quando compatível | Se o caminho do driver muda ritmo ou estabilidade |
| VSync ou limite | Manter o valor de referência | Se o problema é o ritmo e não o FPS bruto |
| Mod por jogo | Desativado durante o diagnóstico | Se um patch específico altera o tempo do jogo |
O Ryujinx pode compilar shaders ao abrir uma cena ou efeito novo, causando um engasgo que tende a diminuir na repetição. A documentação oficial descreve PPTC, que reduz traduções repetidas após execuções anteriores. Compare uma segunda passagem. Se continuar lento com cache aquecido, verifique driver, carga de CPU/GPU, escala e build. Evite caches compartilhados de fontes desconhecidas.
Uma configuração não cria capacidade de hardware. Instale driver estável e confira se o notebook usa a GPU desejada. Economia de energia, bateria fraca, calor ou gravação em segundo plano podem reduzir clocks. Fixe o perfil por jogo no Steam Deck ou Linux; no Windows, mude uma camada por vez. GPU pouco usada com FPS baixo pode indicar limite de CPU ou do jogo; GPU saturada em escala alta aponta custo de renderização.
Uma queda nova no Canary pode ser regressão. Guarde o build atual e o anterior funcional; compare a mesma atualização, salvamento, cena, backend e escala. Se só o novo falhar, anote versões e passos para reproduzir. Se ambos falharem, confira configuração, driver, mods, cache ou limite do jogo. Reverta primeiro somente o emulador.
Esta sequência não garante uma taxa fixa em todo jogo de Switch: alguns exigem muito da CPU e outros têm limites de emulação ou bugs de versão. Mod de 60 FPS altera um título específico, não o desempenho geral. Chaves, firmware, DLC e controle são assuntos separados. O site não hospeda jogos, chaves, firmware, mods ou cache protegido; mantenha backups e consulte fontes oficiais sobre versões.
A ordem segue a FAQ e a documentação oficial de configuração; a matriz é um método editorial para separar causas.
Use escala nativa, atualize o driver e repita após aquecer os shaders. Teste um backend ou ajuste por vez e mantenha apenas melhora repetível.
Um efeito novo pode iniciar shaders ou carregar recursos. Repita o percurso; se persistir com cache aquecido, confira carga, escala, driver e build.
Vulkan é um primeiro teste em drivers compatíveis, mas não garante FPS maiores. Compare a mesma cena e mantenha OpenGL se for mais estável.
Não. O mod muda o tempo de um jogo e atualização específicos. Diagnostique primeiro hardware, driver, backend, escala e shaders.
A cena pode ser limitada pela CPU, por um teto de quadros, shaders ou pelo jogo. Compare uma passagem aquecida e observe CPU e GPU.
Não como primeira medida: apagar cache saudável pode criar novos engasgos. Faça backup e remova só se uma falha repetível apontar para ele.
Compare a mesma cena no build anterior, com jogo, backend e escala iguais. Registre versões se apenas a nova falhar.