Dopo un mese di interruzione, il team di sviluppo, responsabile dell’emulatore RyuJinx, ha ripreso le attività pubblicando il primo report del 2024.
Il team esprime ottimismo per l’inizio positivo dell’anno e anticipa un periodo rinvigorante per la continuazione della fornitura di aggiornamenti regolari.
Our end of 2023 progress report is now available for everyone to read! 🎆
Beware: graphs ahead 📈https://t.co/UJOc2OVrn8— Ryujinx (@RyujinxEmu) January 16, 2024
Il report delinea diverse tematiche, inclusi interventi di correzione grafica, considerazioni per gli utenti di dispositivi alimentati a batteria e un riassunto annuale standard su argomenti come compatibilità e prestazioni nel corso del 2023.
Nel report, vengono dettagliate le sfide incontrate nell’emulazione di Monster Hunter Rise, specialmente dopo l’uscita del DLC ‘Sunbreak’.
Si evidenziano miglioramenti implementati attraverso il supporto della funzione di mappatura sparsa in Vulkan, consentendo una giocabilità migliorata su dispositivi che supportano completamente Vulkan, come Nvidia, Intel e AMD.
Inoltre, il report menziona un problema grafico riscontrato nel gioco Fashion Designer, che è stato risolto identificando e affrontando un glitch nella cache delle texture.
L’articolo descrive in dettaglio la natura del problema e come la risoluzione ha portato a una corretta visualizzazione degli oggetti nel gioco.
Proseguendo con usi peculiari delle texture, quando si cattura una Cicala in Yo-Kai Watch 1, un’immagine 2D dettagliata dell’insetto dovrebbe occupare una grande parte dello schermo.
Purtroppo, a causa di una condizione “if” discutibile che ha silenziato l’unico avviso nel registro che ci avrebbe immediatamente indicato dove fosse il problema, è stato necessario un po’ di tempo per individuare il… bug.
Per ragioni sconosciute, il team sviluppando Yo-Kai Watch 1 ha deciso di eseguire un salvataggio di immagine su una texture che è un quarto della larghezza del formato di base, ma memorizza quattro volte i dati per pixel rispetto a una texture RGBA32.
Se ciò sembra privo di senso, è perché lo è, poiché cosa viene immediatamente fatta con quell’immagine? Viene acceduta come un’immagine RGBA8, che è una conversione di formato incompatibile!
Aggiungendo una dipendenza di copia a questi formati risolve il bug e ripristina il corretto funzionamento.
La stessa problematica è stata anche la causa di gravi corruzioni grafiche in Wet Steps. Sebbene il gioco presenti ancora alcuni problemi, la differenza è significativa.
Super Mario RPG, rilasciato alla fine di novembre, presentava sorprendentemente pochi bug. Tuttavia, i nostri attenti utenti hanno immediatamente notato che Mario stesso, insieme ad alcuni oggetti ambientali, apparivano leggermente spenti.
Sebbene Mario stia invecchiando e abbia probabilmente perso lo splendore della sua giovinezza su GameCube, si è scoperto che l’eliminazione senza vincoli non funzionava correttamente in un paio di casi.
Nel caso in cui un gestore di shader venisse assegnato due volte tramite percorsi diversi, l’eliminazione senza vincoli non poteva essere estesa, poiché non è in grado di trovare l’operazione di gestione.
Tuttavia, anche se esistono percorsi diversi, il valore è effettivamente sempre lo stesso, poiché tutti i dati rilevanti non possono essere modificati una volta all’interno del passaggio dello shader.
Risolvendo questo problema e selezionando semplicemente il primo valore se esistono percorsi multipli, Super Mario RPG viene reso correttamente.
Un altro gioco che ha evidenziato un caso limite non gestito nell’eliminazione senza vincoli è stato Detective Pikachu Returns. Questo è più sottile, ma estendendosi attraverso una procedura di shuffle, si risolvono le riflessioni cubemap in tutto il gioco.
Facciamo una breve pausa per discutere alcune delle modifiche minori, ma forse interessanti, che sono avvenute negli ultimi mesi.
- Quando gli amiibo vengono utilizzati per la prima volta (tramite AmiiboAPI), il file JSON dell’API verrà memorizzato localmente in modo che gli amiibo possano essere utilizzati offline.
- La nostra versione minima di macOS è stata aumentata a macOS 12 Monterey. Non siamo sicuri del motivo per cui è stata scelta macOS 11 in precedenza, ma è del tutto inadatta per l’emulazione della Switch!
- Numerose modifiche di formattazione per stringhe, tempo e data. Risolve l’inversione dell’ordinamento per il tempo di gioco, le dimensioni del file e l’ultima volta giocato, e, cosa più importante, rimuove una serie di messaggi indesiderati nel registro se i giochi non sono mai stati avviati.
- “Crea collegamento desktop” funziona effettivamente su macOS e supporta anche il lancio a schermo intero.
Sonno
Il sonno è importante, è questo vale anche per i dispositivi elettronici che devono poter riposare, anche solo per qualche minuto. Ryujinx deve operare con un programma molto serrato e il modo migliore per farlo è in realtà non dormire.
Nessun kernel desktop è veramente “in tempo reale”, nel senso che è impossibile per noi dormire in un istante e svegliarci quando richiesto. C’è sempre variabilità e ritardo nelle nostre richieste.
Una valida alternativa al sonno viene chiamata “spin-waiting”, in cui il programma mantiene il controllo della CPU e continua a richiederle di “girare” fino a quando non viene attivato un evento che libera la CPU da questo ciclo di attesa.
Girare può essere utilizzato per avere un controllo molto dettagliato su quando e come la CPU interrompe e riprende l’esecuzione di un thread all’interno di un programma, ma presenta un grande svantaggio: è comunque attivo e utilizza energia per tutto il tempo.
Si fa un confronto tra il dormire e l’aspettare girando, illustrando che, mentre si è pronti più rapidamente se si è chiamati dall’attesa, si è meno riposati rispetto a quando si è chiamati dal sonno.
Ora che la terminologia è stata chiarita verrà esaminato il vero problema. Se abbiamo un singolo thread che monitora un singolo evento e desidera attendere 1ms alla volta, non ci saranno problemi.
Quando la stessa situazione coinvolge 10 diversi eventi di attesa sullo stesso thread, sfasati di 0,1ms l’uno dall’altro, emergono invece delle complicazioni.
Fino alla fine del 2023, la soluzione utilizzata era quella di passare semplicemente attraverso queste attese girando, ma questo comporta un continuo utilizzo della CPU, poiché è necessario rimanere svegli per gestire il thread che sta per svegliarsi ogni 0,1ms.
Nel precedente rapporto, si è parlato di una modifica a ServerBase che ha smesso di effettuare il polling ogni 1ms, riducendo drasticamente l’utilizzo della CPU e il consumo di energia a causa del problema sopra menzionato.
Tuttavia, ServerBase è solo uno dei molti tipi di thread che richiedono attese costanti; i thread di gioco presentano un problema altrettanto significativo.
La domanda ora è: come procedere? Gli appassionati di informatica che leggono probabilmente staranno gridando “nanosleep!” ai loro schermi da un paio di minuti, e in parte hanno ragione.
Linux/macOS
Sia Linux che macOS forniscono una chiamata di sistema nanosleep per attendere un numero preciso di nanosecondi. La precisione di un nanosecondo è più che sufficiente per gestire lo scenario sopra descritto, quindi proviamo a utilizzarla.
Durante i test, emerge che nanosleep non è esattamente preciso come suggerisce il suo nome. A valori molto bassi di nanosecondi, si osservano valori di risveglio molto consistenti (e piccoli), ma una volta superata la soglia di 0,5 ms, si verifica un notevole aumento dell’errore, che alla fine si stabilizza intorno a 1,5 ms.
Curiosamente, macOS presenta nuovamente un comportamento diverso. Per richieste di attesa molto brevi, la chiamata di sistema è notevolmente precisa con un errore minimo nelle richieste di sleep fino al nanosecondo.
Purtroppo, l’errore è direttamente proporzionale al tempo di attesa richiesto e continua a salire fino a raggiungere quasi 0,5 ms di ritardo quando viene richiesto uno sleep di 3 ms e oltre 3 ms di ritardo quando viene richiesto uno sleep di 20 ms.
Nonostante sembrino problematici, il caso d’uso desiderato era già orientato verso tempi di sleep più brevi, quindi sia macOS che Linux hanno una soluzione efficiente e semplice attraverso nanosleep.
Windows
Il kernel di Windows NT è di gran lunga il meno “in tempo reale” tra le tre principali opzioni presentate. Non ha un equivalente di nanosleep e, di conseguenza, è fortemente limitato nel gestire il problema del sonno.
Per impostazione predefinita, è possibile dormire con un’accuratezza di 1ms, che, come ci si augura di aver sottolineato, non è sufficiente neanche per due attese concorrenti (ciascuna distante 0,5 ms), figuriamoci per 10.
Su gran parte dei sistemi x86_64, è possibile effettuare una query sulla risoluzione dell’orologio e scoprire che esiste effettivamente una “base clock” con risoluzione di 0,5ms e, forse ancora più interessante, per impostazione predefinita, qualsiasi attesa eseguita si allineerà automaticamente al “base clock tick” più vicino.
Se si dorme senza pensarci, significa che il thread potrebbe svegliarsi in ritardo a causa dell’allineamento con il successivo tick di base.
Tuttavia, se si dispone di queste informazioni e si fa una congettura molto intelligente su quando si verificherà il prossimo tick, è possibile temporizzare il sonno con una precisione di 0,5 ms e svegliarsi quasi sempre poco prima.
Tutto ciò non risolve comunque i problemi relativi alle 10 attese concorrenti di 1 ms. Se rileviamo che un evento di attesa è allineato al clock di base o molto vicino ad esso, possiamo permettere al sistema di allineare le attese e svegliarsi appena prima del prossimo tick dell’orologio.
Se l’attesa non è allineata al clock di base (o estremamente precisa come 0,01 ms), purtroppo non c’è nulla che il kernel di NT ci fornisce per risolvere questo problema, oltre a continuare a utilizzare spinwaits quando necessario.
In breve, il focus è sull’utilizzo della CPU e sul consumo di energia, con l’introduzione di grafici a supporto delle affermazioni.
Gli utenti di dispositivi Apple e Linux trarranno i maggiori vantaggi da queste modifiche, con notevoli guadagni di efficienza in giochi come Tears of the Kingdom, Red Dead Redemption e Breath of the Wild.
Le riduzioni vanno dal 15 al 75%, con dispositivi M2 MacBook Air che emulano Pokémon Violet più efficientemente rispetto a come la Switch lo esegue nativamente.
Queste modifiche possono tradursi in ore aggiuntive di durata della batteria, riducendo l’entità e la frequenza del throttling termico, specialmente nei dispositivi senza ventole come la famiglia MacBook Air.
Consentono anche ai dispositivi di raggiungere e mantenere i loro boost clock nei momenti in cui sono effettivamente necessari, anziché essere continuamente spinti a incrementare durante i menu o in pausa.
Nel complesso, si promettono miglioramenti significativi nell’esperienza di gioco e nell’efficienza energetica.
Panoramica del 2023
Durante il 2023, Ryujinx ha aggiunto oltre 700 giochi alla sua lista di compatibilità, portando il totale a impressionanti 4255 titoli testati e segnalati.
Sorprendentemente, più dell’83% di questi giochi non presenta alcun problema grafico, tecnico o di stabilità, mentre solo il 12% ha almeno un problema, spesso rappresentato da piccoli difetti grafici o problemi di stabilità minori. L’ulteriore 4,5% si ferma ai menu, se ci arriva.
L’emulatore ha registrato un miglioramento medio annuo del 36% nelle prestazioni, evidenziando l’attenzione costante del team per ottimizzare l’emulatore.
I miglioramenti hanno influenzato diversi giochi, con notevoli progressi del 61% per Persona 5 e dell’89% per NieR.
I giochi di Zelda hanno registrato aumenti rispettivamente del 20% e del 35%, mentre il benchmark di riferimento, Super Mario Odyssey, continua a scalare senza sosta.
Ryujinx si è dimostrato pronto e reattivo, supportando numerosi titoli fin dal giorno del loro rilascio. Tra questi, vengono citati:
- The Legend of Zelda: Tears of the Kingdom ✓
- Super Mario Wonder ✓
- Super Mario RPG ✓
- Pikmin 4 ✓
- Metroid Prime Remastered ✓
- Sea of Stars ✓
- Octopath Traveller II ✓
- Fire Emblem Engage ✓
- Kirby’s Return to Dreamland Deluxe ✓
- Advance Wars 1+2: Re-boot Camp ✓
Per gli appassionati di emulazione, sviluppo grafico o con esperienza in C#/.NET, Ryujinx offre l’opportunità di contribuire al progetto.
Il team è attivamente alla ricerca di nuovi talenti disposti a esplorare il GitHub, risolvere bug, introdurre nuove funzionalità o semplicemente partecipare alla crescita di questo affascinante progetto.
Per coloro che desiderano sostenere Ryujinx finanziariamente, il team accoglie con gratitudine le donazioni tramite Patreon.
Anche chiunque voglia partecipare al testing dei giochi o assistere altri utenti sulla Discord di Ryujinx è il benvenuto nel contribuire all’ecosistema della community.
Fonte: twitter.com
