Disponibile il nuovo report sui progressi raggiunti dall’emulatore RPCS3 nel mese di giugno. RPCS3 ad oggi è l’unico programma che ci permette di emulare gran parte dei titoli commerciali della console PlayStation 3 su PC Windows e Linux.

Diverse le modifiche riportate anche questo mese da Nekotekina e kd-11, sotto esame l’implementazione della MSAA nativa e il supporto per il carico di lavoro sulla RSX a più thread.

Sono stati affrontati anche diversi miglioramenti nella pianificazione PPU e una revisione più che significativa dell’ambiente DevOps.

Oltre al seguente rapporto, ulteriori dettagli sul lavoro di Nekotekina e kd-11 durante il mese di giugno e sui contributi futuri possono essere trovati nei loro report settimanali sul Patreon.

• Aggiornamento dello stato da kd-11 (10-06-2019)
• Aggiornamento dello stato da Nekotekina (24-06-2019)
• Aggiornamento dello stato da kd-11 (25-06-2019)

Sommario

Giugno è stato un mese altalenante, dovuto alla pausa di diversi tester, le vacanze estive non hanno comunque influito negativamente, la categoria Playable alla fine è diventata la categoria più grande all’interno della lista dei titoli compatibili.

Tutto questo è stato possibile solo dopo anni di sviluppo, test e rielaborazioni, riuscendo a raggiungere il giusto equilibrio tra precisione e prestazioni per poter emulare correttamente la console Sony.

Le categorie Intro e Loadable sono diminuite a causa del passaggio di alcuni giochi in Ingame o Playable. Anche la categoria Ingame ha visto una riduzione netta a causa di un’ulteriore manutenzione effettuata unendo voci di gioco duplicate.

Per un aspetto più dettagliato, potrete visualizzare la pagina della cronologia per la compatibilità dei giochi che possono essere eseguiti su RPCS3.

Principali miglioramenti

Supporto per MSAA nativo (#6055, #6089)

Da diversi mesi a questa parte il developer kd-11 ha sistematicamente rielaborato l’implementazione della texture cache in RPCS3, per cercare quantomeno di renderlo simile alla PlayStation 3.

Il lavoro svolto fino ad oggi ha portato ad enormi progressi e corretto innumerevoli problemi, e in tutto quello che è stato dettagliato nei precedenti rapporti sui progressi.

Questo mese, kd-11 ha terminato anche l’ultimo pezzo del puzzle, la caratteristica che ha reso necessaria una reimplementazione così ampia, l’antialiasing multisample (MSAA). la console fisica supportava alcune tecniche di antialiasing come MSAA e CSAA per le quali in precedenza non era presente nell’emulatore.

L’implementazione di queste tecniche di antialiasing ha visto all’inizio importanti blocchi a causa della grande differenza nell’implementazione di queste tecniche tra la RSX della PlayStation 3 e le moderne GPU per PC.

Come misura di stopgap, RPCS3 ha utilizzato soluzioni alternative primitive per comunicare ai giochi che MSAA funzionava correttamente mentre in realtà non lo era. Ciò ha portato a una peggiore qualità dell’immagine a risoluzione nativa (720p) su RPCS3 rispetto a una PlayStation 3.

Tuttavia, con l’introduzione di upscaling della risoluzione nel 2017, la necessità di MSAA è diminuita in quanto gli utenti sono stati in grado di cancellare la maggior parte degli alias semplicemente sovrastampando la grafica, ovvero impostando la risoluzione interna su 4K e successivamente ridimensionando l’immagine alla risoluzione del monitor (1080p o 1440p).

Aggiungete ulteriori miglioramenti come il filtro anisotropico e gli utenti sono stati in grado di ottenere una grafica che supera di gran lunga l’hardware nativo.

Tuttavia, questa era ancora una soluzione alternativa e non la soluzione completa. Alcuni giochi (come ad esempio Red Dead Redemption) utilizzavano MSAA su oggetti specifici nell’immagine (come il fogliame) che il semplice sovracampionamento non poteva replicare.

Dopo aver analizzato i componenti che dovevano essere migliorati, kd-11 ha condiviso un’ampia tabella di marcia con i patrions che descrivono in dettaglio il lavoro da fare per portare il vero supporto MSAA in RPCS3.

Ora che tutti gli elementi di quella tabella di marcia sono stati completati, kd-11 era fiducioso che i blocchi stradali identificati anni fa fossero stati finalmente superati e ha iniziato a lavorare sull’implementazione del vero supporto MSAA.

Nel video qui sopra vengono evidenziati alcuni esempi per giochi che richiedono il supporto MSAA

Ma nessuno si aspettava davvero che questo compito andasse avanti senza intoppi, cosa che divenne evidente quasi immediatamente.

All’inizio stesso, kd-11 ha riscontrato alcuni problemi. Per cominciare, anche con l’implementazione di base di MSAA, FPS di molti giochi è sceso a singole cifre.

RPCS3 ha fatto molta strada dall’era dei secondi per fotogramma e kd-11 non aveva intenzione di riportarci lì. Il debug di questi problemi, ha identificato significativi problemi di occupazione dell’hardware che sono stati risolti in modo sommario, riportando le prestazioni alla normalità. 

Tuttavia, questo è stato seguito da sfide ancora maggiori in quanto la MSAA è una delle tecniche più pesantemente custodite. La memoria utilizzata per il buffering degli stencil con il multicampionamento è completamente tagliata dall’accesso in scrittura sulle GPU NVIDIA.

Esistono modi semplici per affrontare questo problema con le GPU AMD, ma tutto l’hardware supportato deve essere preso in considerazione per implementare questa funzione con successo.

Sebbene l’inizializzazione sulle GPU NVIDIA sia facilmente realizzabile con l’assistenza della CPU, è necessario eseguire un ciclo di test dello stencil attraverso tutti i valori possibili che è semplicemente troppo lento per i requisiti di RPCS3.

Dopo aver discusso con altri sviluppatori nella Discord DXVK, kd-11 ha optato per iterare tutti i bit anziché tutti i valori per le GPU NVIDIA che hanno ridotto la complessità delle attività di un fattore 8.

Mentre questo ha lasciato le GPU NVIDIA potenzialmente 5 volte più lente delle GPU AMD nell’elaborazione di MSAA, è stato fortunatamente abbastanza per rendere MSAA facilmente utilizzabile su entrambe le GPU.

Una rapida occhiata al miglioramento del supporto nativo MSAA!

Mentre l’attuale implementazione supporta solo una versione limitata di MSAA che corrisponde al layout di PlayStation 3, kd-11 prevede di migliorarlo ulteriormente per consentire opzioni più flessibili da abilitare per ottenere elementi visivi che superano di gran lunga l’hardware originale in ogni aspetto.

Molti giochi a tripla AAA (come Red Dead Redemption, la serie Crysis, la serie Killzone, tutti i capitoli di Ratchet & Clank ecc..) si basano su MSAA per una visuale corretta e, come puoi vedere nelle immagini sottostanti, le immagini sono leghe migliori con questa funzione abilitata.

Come avvertimento, si noti che MSAA ora è abilitato per impostazione predefinita in RPCS3, il che aumenta l’utilizzo della GPU nei titoli in cui questa funzionalità è utilizzata in modo pesante.

Chiunque abbia usato RPCS3 in precedenza saprà che con la maggior parte dei giochi, le prestazioni non hanno avuto alcun impatto quando si è passati dalla risoluzione nativa a una risoluzione interna anche di 4K sulla maggior parte delle GPU moderne.

Tuttavia, con l’implementazione di MSAA, alcuni giochi potrebbero utilizzare MSAA x4 o addirittura x8 e moltiplicare la risoluzione interna del 300% (per ottenere 4K) può causare anche la moltiplicazione di questi effetti per la stessa proporzione, uccidendo così le prestazioni a causa dell’eccessivo carico della GPU, causando un collo di bottiglia.

Si consiglia agli utenti di testare vari livelli di upscaling (150%, 200%, 300% e così via) per determinare la risoluzione massima che può essere utilizzata senza influire sulle prestazioni.

Supporto multi-threading per carichi di lavoro RSX (#6112)

Successivamente sul piatto, kd-11 ha implementato una vasta gamma di modifiche migliorando vari tipi di sistema. Il primo è il principale cambiamento del lotto, essendo l’introduzione del multi-threading per le attività RSX.

La configurazione precedente ha visto tutte le attività RSX che si verificano sullo stesso thread in quanto è stato progettato pensando alle CPU più vecchie (in genere 4 CPU core con SMT).

Tuttavia, con l’attuale panorama delle CPU che rilasciano un minimo di 6 core con SMT, era tempo di sfruttare le risorse aggiuntive disponibili.

kd-11 ha analizzato le aree in cui i carichi di lavoro RSX possono essere facilmente parallelizzati e le prestazioni risultanti ne traggono vantaggio.

Ciò ha portato all’implementazione di un thread off-loader aggiuntivo per gestire tutti i trasferimenti PCIe (dalla CPU alla GPU) in parallelo con l’elaborazione del frame FIFO.

Nel complesso, il miglioramento delle prestazioni è piuttosto significativo (specialmente con il renderer Vulkan), ma sfortunatamente la maggior parte dei giochi potrebbe non vedere il pieno beneficio di questo miglioramento, poiché il collo di bottiglia delle prestazioni verrebbe spostato su altri componenti dell’emulatore come SPU.

Mentre il framerate potrebbe non aumentare molto in alcuni giochi, il tempo di lavoro impiegato per emulare RSX diminuisce in modo significativo.

Nei carichi di lavoro puramente PPU+RSX, il salto delle prestazioni è compreso tra il 20% e il 50% a seconda del sistema.

Inoltre, se gli utenti sperimentano immagini tremolanti con l’opzione RSX multi-thread abilitata, è un segno che il thread aggiuntivo viene frequentemente non programmato dal sistema operativo e non è in grado di tenere il passo a causa della mancanza di risorse della CPU.

Tenendo presente le CPU con un basso numero di core, questa opzione è disabilitata per impostazione predefinita.

Ecco un esempio di utilizzo delle risorse con RSX Multi-threading Off e On. Mentre il miglioramento delle prestazioni di miglioramento è benvenuto, c’è un calo nell’utilizzo di Guest RSX con un aumento delle metriche host che mostrano lo spostamento del collo di bottiglia dall’RSX agli altri componenti.

Ma kd-11 non si è fermato qui, durante la fase di ricerca dell’integrazione di MSAA ha scoperto importanti differenze di prestazioni tra le GPU AMD e NVIDIA (specialmente su Windows). 

Con una rapida profilazione del collaboratore Whatcookie, è stato rivelato che c’era una quantità eccessiva di oggetti sampler creati con Vulkan e che questo passaggio era molto più lento sui driver AMD rispetto ai driver NVIDIA.

A seguito di questo rapporto, kd-11 ha reimplementato il layout del vertice in streaming sotto Vulkan su un modello di streaming che migliora le prestazioni evitando una costosa copia descrittiva su ogni blocco secondario di un disegno in batch.

Ciò risolveva problemi con le schede Radeon in cui le prestazioni scendevano nel territorio dei secondi per fotogramma con alcuni giochi.

Successivamente, kd-11 ha scoperto ulteriori problemi con il modo in cui RPCS3 utilizzava le GPU Radeon integrando la funzionalità MSAA.

Grazie al progetto GPUOpen e al profiler GPU di Radeon, ha rapidamente identificato la fonte del problema: l’occupazione degli shader in alcuni passaggi in cui gli shader erano grandi, complicati e consumavano troppo spazio di registrazione inutilmente.

Una volta che il lavoro di kd-11 sull’integrazione di MSAA è stato unito, ha continuato a indagare su alcuni shader generati e a ottimizzarli a mano, notando che alcuni shader consumavano quasi il 50% in più di registri mentre erano 3-10 volte più lunghi in termini di conteggio delle istruzioni.

Ciò stava effettivamente causando problemi di caricamento dello shader in alcuni giochi in cui, anche con una cache dello shader, ci sarebbe voluto troppo tempo per precaricare gli shader.

Un altro problema identificato (specialmente con il renderer Vulkan) era che c’erano semplicemente troppe barriere in atto. Ogni operazione di imaging stava convertendo il layout nel layout previsto, quindi facendo più barriere e successivamente ripristinando questo cambiamento.

Questo non è un problema se fatto una o due volte, ma ciò accadeva troppo spesso e causava un collo di bottiglia nelle prestazioni. La soluzione implementata era quella di ridurre le inutili barriere di memoria e ha comportato un miglioramento del 30% delle GPU Polaris.

Entrambi i problemi di cui sopra hanno influito principalmente sulle prestazioni in sistemi di fascia bassa e GPU deboli, quindi gli utenti con sistemi potenti potrebbero non vedere lo stesso livello di benefici.

Infine, i tester hanno sottolineato altri giochi con colli di bottiglia RSX e ulteriori scavi hanno rivelato nuovi colli di bottiglia in Zcull e caricamenti del buffer di indice.

L’elaborazione del buffer dell’indice è stata accelerata utilizzando SSSE3 che ha il potenziale per upload fino a 4 volte più veloci a 32 bit e upload 8 volte più veloci a 16 bit.

Anche l’invio di lavori Zcull per il renderer Vulkan è stato riscritto per cambiare il modello da un sistema a immissione singola per un sistema a immissione singola per comando che è molto più efficiente nei giochi che utilizzano Zcull pesantemente.

Ciò ha portato a un notevole aumento delle prestazioni su più titoli e, in particolare, molti giochi a 60FPS bloccati a metà degli anni ’40 possono ora raggiungere i 60FPS se altre parti dell’emulatore lo consentono, il che dovrebbe migliorare la giocabilità, specialmente nei giochi di combattimento.

Per mantenere equi i confronti, abbiamo disabilitato il supporto multi-thread RSX per mostrare con precisione il miglioramento delle prestazioni dalle ottimizzazioni sopra descritte:

Ristrutturare il meccanismo di invio dei frame (#6069)

Infine, kd-11 ha ristrutturato il meccanismo di invio dei frame nel renderer Vulkan per evitare il bug di deadlock del driver NVIDIA apparso dai driver della serie 400. In precedenza, RPCS3 utilizzava un segnale di recinzione e un’attesa esplicita seguita dall’invio manuale al motore attuale senza semafori.

L’idea era di controllare l’invio dei frame dall’applicazione invece di lasciarlo fare al driver, ma ciò ha innescato un brutto deadlock con i driver, a volte costringendo un hard reset del sistema per far funzionare di nuovo i sistemi Windows.

Questo è stato risolto semplicemente facendo ciò che fa ogni altra applicazione e invece usa semafori di segnale nel driver.

Questo percorso è privo di bug, probabilmente poiché è il metodo più comunemente usato da altre applicazioni vulkan. Mentre questo ha risolto completamente il bug deadlock con le GPU NVIDIA,

kd-11 ha implementato anche un sistema di gestione dei frame che consente di liberare correttamente le risorse quando la finestra di RPCS3 viene ridotta ad icona, migliorando le prestazioni complessive del sistema e la capacità di multi-task.

Implementazione TSX fallback (#6045, #6056)

Potresti averlo sentito o meno, ma il 15 maggio del 2019, Intel ha rilasciato nuovi aggiornamenti di microcodice per affrontare una vulnerabilità di sicurezza nota come “MDS”.

Su Windows, gli utenti possono facoltativamente eseguire l’aggiornamento al microcodice più recente, mentre su Linux, la maggior parte delle distribuzioni ha reso disponibile l’aggiornamento immediatamente.

Gli utenti che hanno ricevuto questo aggiornamento in anticipo potrebbero aver notato che RPCS3 stava funzionando molto più lentamente. Mentre era facile correlare la diminuzione delle prestazioni alle mitigazioni dell’MDS, sorprendentemente non erano i veri colpevoli della perdita.

La perdita di prestazioni è in realtà il risultato della risoluzione da parte di Intel di un errore non specificato nella loro implementazione TSX per CPU Skylake+.

Intel non fornisce note di rilascio dettagliate per gli aggiornamenti del microcodice, quindi queste informazioni sono state effettivamente raccolte attraverso la visualizzazione di vecchi messaggi di commit per il kernel Linux inviati dai dipendenti Intel.

Fortunatamente, si è scoperto che Intel ha aggiunto alcune nuove funzionalità che possiamo usare per determinare se una specifica CPU è influenzata o meno da questo nuovo aggiornamento del microcodice.

Questa nuova funzionalità è nota come TSX_FORCE_ABORT. La presenza di TSX_FORCE_ABORT significa che è stato esposto un nuovo MSR (registro specifico del modello) con la possibilità di attivare/disattivare il tasso di interruzione del 100% sulle transazioni TSX.

RPCS3 in realtà non si prende cura di questa funzionalità, ma ogni CPU che segnala questa funzionalità può essere considerata in possesso di una versione di TSX nota per comportarsi diversamente.

Whatcookie, il nuovo collaboratore che si è unito ai nostri ranghi, era responsabile della ricerca e dell’identificazione dell’esistenza di TSX_FORCE_ABORT.

Una volta che queste informazioni sono venute alla luce, ha sommariamente implementato il supporto nell’emulatore per rilevare la presenza di questa funzione.

Se la tua CPU è interessata, ora vedrai TSX-FA apparire nella seconda riga del registro. Nell’ultima versione di RPCS3, molti problemi con TSX-FA sono stati risolti, ma nel caso continui a riscontrare problemi, considera di disabilitare il supporto TSX nella scheda Impostazioni.

Una volta incorporato questo rilevamento in RPCS3, Nekotekina mirava a migliorare la situazione per gli utenti con il nuovo microcodice.

Per capire lo scopo di questo cambiamento, dobbiamo prima capire un po’ su come funziona TSX. TSX ci consente di scrivere software multi-thread in grado di funzionare senza la necessità di utilizzare blocchi per sincronizzare i thread.

Dopo aver iniziato una transazione TSX, qualsiasi memoria toccata da quel thread viene contrassegnata come riservata.

Se un altro thread tenta di toccare quella memoria riservata, causerà un “interruzione” sul thread che ha riservato la memoria, il che significa che eseguirà il rollback di tutte le modifiche apportate dal thread originale e quindi tutto può continuare normalmente.

In precedenza, dopo aver interrotto una transazione, la strategia era semplicemente provare il percorso TSX ancora e ancora e ancora finché non ha funzionato.

Tuttavia, con l’ultimo microcodice, il cambiamento nell’implementazione di TSX ha comportato un massiccio aumento del tasso di interruzione, ben oltre ciò che è accettabile per i requisiti di RPCS3, compromettendo così le prestazioni.

Per alleviare questo problema, Nekotekina ha implementato un percorso di fallback in cui l’emulatore tenterà ora di utilizzare il percorso non TSX quando rileva un alto tasso di interruzione sul percorso TSX.

Il nostro test case ha visto un miglioramento delle prestazioni da 30FPS a 41FPS. Questo particolare gioco ha visto 44FPS con il vecchio microcodice e 39FPS con TSX disabilitati del tutto.

Sebbene il vantaggio di TSX sia stato ridotto, offre comunque agli utenti un aumento delle prestazioni rispetto al percorso non TSX, che è sempre il benvenuto! Nekotekina sta inoltre studiando ulteriori metodi per migliorare il percorso TSX per riportare le prestazioni ai livelli precedenti.

Detto questo, nel caso in cui si verifichi un improvviso calo delle prestazioni e visualizzi TSX-FA nel tuo registro, considera di disabilitare il supporto TSX per il momento.

Manutenzione DevOps (#5178, #5964, #6046, #6058, #6071, #6142)

RPCS3 è un enorme progetto per un totale di oltre 1100 file e 70 cartelle (esclusi i sottomoduli) e, come tale, può essere piuttosto disordinato in alcuni punti.

Mentre molti volontari e membri principali hanno trascorso molto tempo a lavorare per mantenere pulita la base di codice, inevitabilmente si insinuano debiti tecnici e altre varie intrusioni.

A giugno, c’è stato un picco nelle richieste di pull dedicate alla pulizia del progetto stesso. Sebbene queste modifiche abbiano effetti limitati sulla compatibilità e sulle prestazioni del gioco, hanno un forte effetto nel mantenere il progetto aperto a nuovi collaboratori, oltre a prevenire l’introduzione di nuovi bug.

Avvisi del compilatore: JohnHolmesII e MSuih

Chiunque abbia programmato prima ha sicuramente familiarità con gli avvisi del compilatore. Per coloro che non lo hanno, ecco una breve panoramica:

Un compilatore esaminerà il codice scritto prima di compilarlo, e durante questa revisione, potrebbe emettere avvisi su cose che vede come codice potenzialmente errato, codice fuorviante o persino codice stilisticamente scadente.

La maggior parte dei progetti è molto particolare sul modo in cui vengono gestiti gli avvisi del compilatore, alcuni addirittura arrivano a rifiutare di accettare qualsiasi codice che crei avvisi.

RPCS3 non aveva alcun avviso aggiuntivo abilitato oltre a quelli abilitati di default nei compilatori, che non è la migliore pratica da seguire.

Quel che è peggio è che nonostante non siano stati attivati ​​molti avvisi, al momento della compilazione sono stati comunque emessi migliaia di avvisi.

Il sistema di costruzione automatizzato Travis, ad esempio, aveva registri che si estendevano su 8000 linee, la maggior parte delle quali erano avvisi.

E se tutto ciò non bastasse, gli avvertimenti emessi sui 3 compilatori utilizzati (GCC, Clang e MSVC) erano tutti diversi! La differenza tra MSVC è comprensibile, ma GCC e Clang hanno informazioni di avviso molto compatibili e avrebbero dovuto essere molto simili.

La situazione è migliorata da due importanti contributi. Il primo, di John HolmesII, si concentrava sul lato Unix delle cose, mentre il secondo, di MSuih, era un follow-up con un focus sulla pulizia degli avvertimenti in MSVC.

Il sistema di compilazione di CMake è stato leggermente modificato, in modo che GCC e Clang siano ora trattati come compilatori molto simili. 

Il flag di avviso -Wall, un punto fermo in quasi tutti i progetti e di solito considerato un minimo, era solo ora abilitato per i compilatori Unix, come base. Si scopre che la maggior parte di quelle migliaia di avvertimenti erano correzioni banali, come ad esempio la regolazione di alcuni tipi di dati.

Alcuni erano un po’ sinistri, come un troncamento nascosto. Parte del refactor di CMake includeva anche il nascondere intenzionalmente alcuni avvisi che venivano fatti per due motivi principali.

Il primo è che non tutti gli avvisi sono buoni avvisi e il secondo è che la correzione di molti degli avvisi esistenti ha richiesto uno sforzo significativo da parte degli sviluppatori principali.

Con questo, la pulizia degli avvisi del compilatore è stata un successo, portando il registro Travis da oltre 8000 linee a circa 1000 linee, con la maggior parte delle linee che ora sono normali output del compilatore. RPCS3 ha ancora molta strada da fare in termini di conformità degli avvisi, ma sono stati compiuti progressi significativi.

Un importante effetto collaterale della pulizia degli avvisi è che eventuali nuovi avvisi introdotti si distingueranno in modo significativo, impedendo loro di finire nella base di codice. I sistemi di allarme possono essere relativamente autosufficienti, se applicati correttamente.

Clang-tidy, avvertimenti e modernizzazione – scribam

Infine, concluderemo la sezione dei principali miglioramenti con il lavoro svolto dal collaboratore scribam, che ha continuato a strappare un’assoluta lacuna di lavoro al grintoso.

In primo luogo, ha applicato -Wpedantic alla base del codice e corretto un numero di avvisi generati lì. Questo flag di avviso non è ancora abilitato per impostazione predefinita, ma alla fine è stato un buon inizio per arrivarci. 

Quindi, scribam ha eseguito l’utilità di lanugine in modo chiaro sulla base di codice. Un’utilità di linting è uno strumento che cerca vari problemi nel codice, incluso tutto, dalle cose che sembrano avvertimenti ai consigli di stile.

Importante infine sottolineare che strumenti come clang-tidy trovano funzioni obsolete e tecniche di codifica che possono essere dannose per la base di codice.

Un esempio sono le funzioni di ricerca stringa find_first_of e find_last_of integrate nella libreria standard C++.

Clang-tidy è stato in grado di notare che la ricerca di singoli caratteri anziché intere sottostringhe è sostanzialmente più veloce, consentendo ad alcune aree del codice RSX che utilizzano queste funzioni per l’analisi degli shader di diventare sempre più leggermente più efficienti.

Sono stati implementati numerosi suggerimenti relativi alla leggibilità e alla modernizzazione di Clang-Tidy, migliorando la manutenibilità della base di codice. Il suo ultimo contributo è stato quello di aggiornare la versione GCC richiesta a 8, poiché le funzionalità di modernizzazione lo richiedono.

DevOps può essere un lavoro brutto a volte, in quanto può sembrare un grande sforzo per apparentemente nessuna ricompensa tangibile.

Gran parte dell’aggiornamento del codebase richiede l’analisi di centinaia di codice di altre persone e, nonostante i messaggi utili dagli strumenti di sfilacciatura, le modifiche appropriate non sono sempre evidenti.

Tuttavia, questo tipo di lavoro è necessario per la longevità di un progetto su questa scala, ed è un compito senza fine. C’è ancora molto altro da fare a breve termine, incluso molto lavoro sulla pulizia degli avvisi e il lavoro di aggiornamento dell’ambiente di build per Windows per essere il più aggiornato possibile.

Giochi

Haze

Per dare il via alla vetrina dei giochi di questo mese, abbiamo lo sparatutto in prima persona Haze della Ubisoft. Questo titolo esclusivo per PlayStation 3 in precedenza aveva sofferto di problemi grafici come il testo mancante e un “filtro giallo” permanente durante il gioco.

Backbreaker Vengeance

Il successore del famigerato gioco arcade di football americano, Backbreaker Vengeance, divenne finalmente giocabile dopo che gli ultimi problemi grafici rimanenti furono risolti da kd-11.

Kidou Senshi Gundam UC

Un altro titolo di Gundam trova la sua strada per giocare con gli ultimi bug rimasti in Kidou Senshi Gundam UC. Sebbene questo gioco avesse buone prestazioni e grafica, in precedenza si sarebbe bloccato in alcuni scenari di cast personalizzati.

Grazie ai miglioramenti della precisione con l’emulatore, tutti questi problemi sono stati risolti in modo sommario.

2010 FIFA World Cup: South Africa

Uno dei pochi titoli FIFA a non arrivare su PC, 2010 FIFA World Cup: South Africa, è finalmente diventato giocabile questo mese. Gli utenti che hanno perso la Coppa del Mondo possono ora divertirsi con questo gioco su PC con RPCS3.

Fight Night Champion

L’esclusivo titolo di boxe per console, Fight Night Champion, ora entra in gioco su RPCS3. Tuttavia, questo gioco sembra soffrire di basse prestazioni durante le partite impedendogli di essere giocabile.

SEGA Rally Online Arcade

Se qualcuno non vedeva l’ora di vincere i titoli delle corse, non cercate oltre. Questo mese è stato scoperto che SEGA Rally Online Arcade è diventato sicuro. Mentre il gioco sembra avere una buona grafica, soffre di basse prestazioni che lo impediscono di essere giocabile.

DJ Hero

Per finire l’elenco dei giochi, questo mese DJ Hero è avanzato oltre la schermata del titolo! Mentre i giradischi da DJ non sono ancora supportati su RPCS3, il collegamento di un controller come un pad per chitarra consente agli utenti di suonare le fasi di remix di DJ-Guitar.

Nota che agli utenti potrebbe essere richiesto di usare cheat per sbloccare tutte le canzoni e quindi suonare i livelli di chitarra.

Altri miglioramenti

Ci sono state numerose altre richieste di pull durante il mese che non sono riuscite a raggiungere la sezione Principali miglioramenti.

Abbiamo raccolto un elenco di tutti questi miglioramenti qui e abbiamo allegato una breve panoramica a ciascuno di essi.

Assicurati di controllare i link forniti, dato che le pagine GitHub di solito rivelano ulteriori dettagli, così come i cambiamenti del codice stesso. Per vedere l’elenco completo delle richieste di pull direttamente su GitHub, clicca qui.

Potrete scaricare la versione più recente dell’emulatore collegandovi a questo indirizzo per PC Windows e Linux. Se vi piace potrete anche contribuire allo sviluppo con una piccola donazione sul Patreon.

Fonte: rpcs3.net