Disponibile il primo report dell’anno sui progressi raggiunti dall’emulatore Dolphin negli ultimi tre mesi, il programma open-source ci permette di emulare i giochi del Nintendo GameCube e della Wii su PC Windows, MacOS X, Linux e dispositivi Android.
Il Progress Report di Dolphin per Novembre, Dicembre e Gennaio 2024 ha visto l’introduzione di vari miglioramenti, tra cui una correzione per Sonic Mania, la prevenzione dell’ingrandimento del file di paging di Windows e rapporti di aspetto personalizzati.
The Nov and Dec 2023, Jan 2024 Dolphin Progress Report is up! This time, we have a Sonic Mania fix, stop Windows from ballooning its page file, custom aspect ratios, see a classic anew, a fix for double input on Deck, important work emails, and more!https://t.co/Y21qWYy6UN
— Dolphin Emulator (@dolphin@dolphin-emu.org) (@Dolphin_Emu) February 10, 2024
Per coloro che desiderano godersi alcuni dei più recenti homebrew con DSP-HLE, Dolphin ora supporta gli ultimi microcodici homebrew.
Per i giochi retail, è stato rilasciato anche un aggiornamento minore al microcodice Zelda-HLE per correggere un effetto mancante che era stato trascurato da tempo.
Cambiamenti
5.0-20353 – DSPHLE: supporto 2023 libaesnd uCode di Pokechu22
Libasnd e libaesnd sono microcodici DSP open source utilizzati per GameCube e Wii, comunemente impiegati nell’ambito dell’homebrew.
Quando Pokechu22 ha integrato questi microcodici in DSP-HLE nel 2022, si è reso conto che eventuali futuri aggiornamenti avrebbero richiesto un intervento manuale per mantenere la compatibilità con DSP-HLE.
Questo perché DSP-HLE non emula direttamente l’hardware DSP, ma reimplementa i microcodici in C++, garantendo prestazioni notevolmente più veloci rispetto all’emulazione hardware.
Tuttavia, Dolphin controlla l’hash del microcodice del gioco per determinare quale reimplementazione utilizzare. Nel caso in cui l’hash non corrisponda a nessuna reimplementazione, Dolphin ricorre al microcodice AX reimplementato, spesso compromettendo la riproduzione audio dell’homebrew.
Nel 2023, un aggiornamento a libaesnd ha causato problemi simili. Anche se le correzioni erano minori, la nuova versione presentava un hash diverso, causando l’interruzione dell’audio nei titoli che utilizzavano tale versione.
Questa problematica è stata evidenziata dalle ultime versioni del porting di Sonic Mania Wii, un progetto in fase di sviluppo attivo.
Pokechu22 ha risolto la situazione documentando le modifiche e aggiornando gli hash nel codice DSP-HLE, consentendo agli utenti di continuare a godere dell’audio nei titoli che impiegano la nuova versione di libaesnd.
5.0-20880 – Zelda-HLE: corretto il fattore di volume del riverbero by flacs
Nel contesto di DSP-HLE, il collaboratore di lunga data flacs ha introdotto un microfix che risolve un problema notato in Mario Kart Double Dash!! riguardante gli effetti di riverbero mancanti.
Questo problema era stato rilevato nel 2015 ma era stato considerato di bassa priorità durante una riscrittura significativa di Zelda-HLE. Dopo il completamento della riscrittura, il bug è rimasto irrisolto.
Flacs ha identificato e corretto il bug, eliminando efficacemente il problema in tutti i quadranti. La soluzione si è rivelata relativamente semplice: il volume del riverbero veniva erroneamente moltiplicato due volte per il volume corrente, causando un effetto estremamente silenzioso.
Successivamente, è emerso che i segnalatori di bug inizialmente non avevano notato il riverbero a causa di questa discrepanza nel volume. Una volta risolto il problema, l’effetto di riverbero ha ripreso a funzionare correttamente come previsto.
5.0-20517 – Implementato Send Mail by Sketch
Sketch ha preso nota delle difficoltà riscontrati dagli utenti e ha lavorato lentamente attraverso il sistema di posta Wii.
Anche se questo non è ancora completamente completo, coloro che hanno eseguito correttamente la registrazione al servizio WiiLink potranno inviare messaggi ad altri Wii e persino email direttamente da Dolphin.
Per raggiungere questo punto, è stato affrontato un percorso piuttosto lungo, e gran parte del lavoro è stato già fatto per l’emulazione di WiiConnect24.
Presto, si spera di avere la piena parità tra l’utilizzo di WiiLink su una console e Dolphin, anche se ci sono ancora alcune funzionalità mancanti sul lato di Dolphin.
5.0-20589 – Riscritto LazyMemoryRegion by AdmiralCurtiss
Nell’ultimo report sui progressi raggiunti dall’emulatore, è stata descritta un’ottimizzazione delle prestazioni che aveva l’effetto collaterale fastidioso di occupare 32 GiB di spazio su disco su Windows.
Ora AdmiralCurtiss ha riscritto il codice utilizzato su Windows per evitare effetti collaterali di questo tipo.
Per riassumere il problema dell’ultima volta: Dolphin aveva bisogno di un’allocazione di memoria di 32 GiB per tenere traccia di dove si trovavano i codici ricompilati.
La maggior parte di questa memoria non doveva essere effettivamente allocata, ma ogni volta che Dolphin voleva accedere a una posizione particolare, doveva essere allocata memoria reale al volo in modo che l’accesso non fallisse.
Nella soluzione precedentemente descritta, questo è stato gestito chiedendo al sistema operativo di allocare pagine al bisogno.
Questo metodo ha funzionato bene su quasi tutti i sistemi operativi, ma su Windows è emerso un problema: il sistema avrebbe forzato l’espansione del file di paging per corrispondere alla grande allocazione di 32 GiB nel caso in cui si tentasse di accedere a tutta la memoria disponibile.
Con la nuova soluzione, le operazioni ora vengono gestite in modo più manuale su Windows.
L’idea iniziale di AdmiralCurtiss era quella di emulare il comportamento del sistema operativo configurando un gestore di segnali che si attiva quando Dolphin tenta di accedere a un indirizzo non supportato dalla memoria reale, una pratica già utilizzata da Dolphin per l’ottimizzazione fastmem.
Successivamente, il lettore del Progress Report PJB3005 ha suggerito una soluzione più semplice, considerando che Dolphin scrive nella regione di 32 GiB solo da due pezzi di codice, entrambi eseguiti raramente.
Questa soluzione è stata poi implementata da AdmiralCurtiss. Invece di utilizzare un gestore di segnali, Dolphin ora verifica manualmente se è necessario allocare memoria reale prima di scrivere nella regione di 32 GiB.
Le parti della regione di 32 GiB che non sono ancora supportate da memoria reale puntano a una pagina di sola lettura riempita di zeri, così da evitare errori nel caso in cui Dolphin tenti di leggere da una posizione non ancora scritta.
Ora gli utenti di Dolphin su Windows possono beneficiare dell’ottimizzazione delle prestazioni JIT Block Lookup senza preoccuparsi che Windows faccia gonfiare il loro file di paging.
Problemi come non essere in grado di scaricare file di grandi dimensioni mentre Dolphin è in esecuzione non si verificheranno più.
Su sistemi operativi diversi da Windows, Dolphin sta ancora utilizzando il vecchio approccio in cui il sistema operativo alloca memoria reale al volo, poiché abbiamo riscontrato problemi solo con quell’approccio su Windows.
5.0-20745 – Disabilita il rilevamento di Mipmap arbitrarie per impostazione predefinita by iwubcode
Come parte dell’importante trucco per aumentare la Risoluzione Interna, Dolphin regola il livello di mipmap delle texture.
Il mipmap è il processo di scambio verso versioni a risoluzione inferiore delle texture se queste sembrano troppo piccole nell’immagine finale.
Si tratta di una pratica grafica consolidata: utilizzare texture ad alta risoluzione ovunque porta ad aliasing e moiré severi su texture distanti o ad angoli obliqui.
Tuttavia, questo dipende dalla risoluzione, e i target di mipmap impostati per 480p saranno intensamente sfocati a 4K.
Perciò, Dolphin regola i livelli di mipmap per corrispondere all’aumento della Risoluzione Interna, migliorando significativamente la qualità complessiva delle texture nell’immagine finale.
Tuttavia, alcuni titoli GameCube e Wii utilizzano trucchi con i mipmap per gli effetti speciali, e modificando i livelli di mipmap, stavamo interrompendo questi trucchi.
Per ottenere la massima qualità dell’immagine ad alta risoluzione senza compromettere gli effetti speciali, nel 2017 è stato introdotto il Rilevamento Arbitrario dei Mipmap, un’euristica che cerca di individuare i trucchi con i mipmap e di passare a una implementazione dei mipmap più accurata solo per le texture coinvolte in tali effetti.
Il risultato è che le specifiche texture utilizzate per questi effetti saranno più sfocate, ma poiché si sta correggendo effetti danneggiati e dovrebbe influenzare solo le specifiche texture coinvolte, si configura una situazione vantaggiosa per entrambe le parti. Questo è il ragionamento teorico.
Purtroppo questa euristica si è dimostrata problematica. Spesso presenta falsi positivi, rilevando erroneamente che le mipmap sono utilizzate per gli effetti e utilizzando inutilmente le versioni più sfocate.
Nel 2018 è stato introdotto il comando di attivazione del Rilevamento Arbitrario dei Mipmap. Attivato per impostazione predefinita, questa opzione ha fornito a chiunque avesse problemi con l’euristica la possibilità di semplicemente disattivarla e evitare eventuali problemi che potrebbe causare. Si è trattato di una soluzione semplice, che è rimasta invariata da allora.
Tuttavia, verso la fine del 2023, iwubcode ha posto una domanda che ha sconvolto tutti: “quanti giochi utilizzano mipmap arbitrari per gli effetti?”
In seguito a questo scambio di opinioni, si è realizzato che il numero di giochi che utilizzano questi trucchi con i mipmap non è molto elevato.
A loro conoscenza, solo Nintendo ha utilizzato questa tecnica. Naturalmente, si trattava di giochi di Nintendo, titoli che rappresentano i fiore all’occhiello della lineup di GameCube e Wii, come Super Mario Galaxy e The Legend of Zelda: The Wind Waker.
Tuttavia, essendo titoli così fondamentali, si è realizzato che l’importanza di individuare questi effetti era stata sopravvalutata. Per quanto sappiano, solo un paio di dozzine di giochi utilizzano il trucco, mentre migliaia di giochi non lo fanno.
Considerando quanto siano comuni e dannosi i falsi positivi con l’euristica, averla attiva per impostazione predefinita per ogni gioco probabilmente causava più danni che benefici.
Pertanto è stata presa la decisione di cambiare rotta. Il Rilevamento Arbitrario dei Mipmap è ora disattivato per impostazione predefinita. Da questo momento in poi sarà attivato solo nei casi noti, tramite il sistema GameINI.
Nel caso in cui si notino eventuali problemi risolti attivando il Rilevamento Arbitrario dei Mipmap, si prega di farlo sapere affinché possano essere aggiunti alla lista dei trucchi con i mipmap conosciuti.
5.0-20785 – Supporto dei rapporti di aspetto personalizzati by Filoppi
Il Widescreen Hack di Dolphin è sia sorprendente che terribile allo stesso tempo. Espandendo il View Frustum, consente a Dolphin di renderizzare qualsiasi gioco in qualsiasi rapporto di aspetto, e quindi riempire qualsiasi schermo senza distorcere l’immagine.
Tuttavia, il Widescreen Hack viene eseguito solo sul lato di Dolphin e non influisce affatto sulla logica del gioco. Il Frustum Culling, la grafica 2D nello spazio schermo e altro ancora sono completamente non modificati.
Il risultato sono grandi aree vuote nello spazio espanso, elementi 2D allungati e pop-in aberrante che sono semplicemente la realtà del Widescreen Hack.
Fortunatamente, è disponibile un’alternativa: codici cheat specifici per il rapporto d’aspetto del gioco. Modificando direttamente il gioco attraverso il nostro sistema di cheat, è possibile risolvere tutti questi problemi e ottenere un risultato migliore.
Tuttavia, i codici di rapporto d’aspetto richiedono che l’utente configuri il proprio rapporto d’aspetto. Ad esempio, per eseguire il codice di rapporto d’aspetto 16:9 di Ralf per Wind Waker, l’utente deve impostare il rapporto d’aspetto di Dolphin su Force 16:9. Abbastanza semplice.
Ma cosa accade se il display è UltraWide? I codici 21:9 sono abbastanza comuni, ma non esiste un’opzione “Forza 21:9”.
Per aggirare questo problema, gli utenti di display 21:9 possono impostare il rapporto d’aspetto su “Allungamento alla finestra” e passare alla modalità a schermo intero.
Questo svolge il lavoro, ma presenta alcuni problemi. I rapporti d’aspetto ultrawide sono meno uno standard e più una suggestione, quindi anche all’interno della categoria 21:9, i rapporti effettivi variano. Nel mondo reale, il piccolo trucco di solito comporta una leggera distorsione.
Ma ancora peggio è Super UltraWide. I codici degli aspetti 32:9 sono rari, rendendo il trucco sopra descritto non praticabile.
La migliore opzione disponibile per gli utenti 32:9 era combinare un codice 21:9, la modalità a finestra e “Allungamento alla dimensione della finestra”, quindi dimensionare molto attentamente la finestra in modo che non ci fosse allungamento. Non ottimale.
Filoppi ha ritenuto che le soluzioni esistenti non fossero sufficienti e ha aggiunto a Dolphin la nuova opzione “Rapporto d’aspetto personalizzato”.
Utilizzando questa funzione, è possibile forzare il rapporto d’aspetto di Dolphin in base alle proprie esigenze. Grazie a questa novità, gli utenti di schermi Super UltraWide possono godersi un rapporto d’aspetto di 21:9 a schermo intero senza problemi o distorsioni.
Inoltre, questa modifica consente di utilizzare qualsiasi rapporto di aspetto su qualsiasi display. Quindi, se si possiede un display 16:9 e si desidera giocare in 21:9 su un televisore OLED o altro, ora è possibile farlo.
In effetti, se un gioco retro teorico per GameCube o Wii avesse un rapporto d’aspetto errato, questa funzionalità potrebbe essere utilizzata per correggerlo. Non ne abbiamo ancora trovati esempi, ma è una possibilità interessante da considerare.
Tuttavia, come viene fatto ogni volta che vengono concessi nuovi e potenzialmente pericolosi poteri agli utenti, è importante accompagnare questa novità con una parola di cautela.
È necessario ricordare che il GameCube e la Wii non sono mai stati esattamente in 4:3, 5:4 o 16:9, almeno non nell’hardware originale.
Durante quegli anni, si utilizzavano prevalentemente schermi analogici e le immagini sarebbero state comunque sovrascansionate, quindi gli sviluppatori di giochi non avevano un incentivo per garantire l’esattezza dei rapporti d’aspetto.
Pertanto, quando Dolphin applica rapporti d’aspetto standard, è importante tenere presente che ogni singolo gioco potrebbe essere in qualche modo “sbagliato”. Ad esempio, ricordate gli scudi di Melee?
Questo problema si è rivelata un’enorme sfida per il team di sviluppo di Dolphin, richiedendo mesi di sforzi da parte di ingegneri altamente qualificati, tester, membri della comunità di esports e altri collaboratori. Si è trattato di un compito titanico.
Il frutto di tutto questo lavoro è che Dolphin ora legge l’esatto rapporto d’aspetto richiesto dal gioco sulla console e lo visualizza senza alcuna distorsione.
Per garantire che gli utenti possano vedere l’immagine senza problemi, tutte le modalità di rapporto d’aspetto di Dolphin utilizzano queste correzioni, ad eccezione della modalità “Allungamento alla finestra” che le ignora.
Tuttavia, ora c’è un secondo modo per aggirare queste correzioni: utilizzare un rapporto d’aspetto personalizzato. Questa opzione fornirà agli utenti esattamente ciò che viene inserito, indipendentemente dalle impostazioni.
Pertanto, se si sta giocando in 4:3 o 16:9 e si configura un rapporto d’aspetto personalizzato diverso, si bypasserà l’adattamento automatico del rapporto d’aspetto di Dolphin, causando distorsioni nell’immagine.
5.0-20849 – VideoCommon: Applica “Forza colore a 24 bit” alle copie EFB by flacs
“Forza colore a 24 bit” è un miglioramento introdotto da flacs che mira a ridurre il banding forzando l’hardware emulato alla massima profondità di bit possibile.
Tuttavia, in alcune situazioni, attivare questa funzione non portava ad alcun miglioramento del banding. Questa modifica risolve tale problema, sebbene per comprendere appieno il motivo dovremo analizzarne i dettagli.
Il post-processing su GameCube e Wii si basa sull'”Embedded Frame Buffer” (EFB), una memoria di lavoro rapida di 2MiB nella GPU.
Durante il rendering, alcuni effetti di base di post-processing possono essere applicati sull’EFB, ma non quelli che coinvolgono la lettura e la distorsione del frame.
Per la maggior parte degli effetti di post-processing, i giochi eseguono una copia EFB per trasferire il frame nella memoria principale, dove viene letto come texture per renderizzare nuovamente sopra di esso.
Tuttavia, poiché le console renderizzano principalmente in RGBA6 a 6 bit per canale, i giochi convertono spesso il frame in RGBA8 a 8 bit per canale durante la copia EFB per mantenere la qualità visiva.
Tuttavia, questo formato occupa molto spazio nella memoria principale, quindi molti giochi optano per copiare alcune immagini nell’EFB in formato RGB565, che occupa meno spazio ma ha una qualità visiva inferiore.
Questa scelta comporta un maggior effetto di banding e la mancanza del canale alfa, ma era una soluzione accettabile data la limitata memoria disponibile su queste console.
In Dolphin, è stata implementata una funzionalità chiamata “Forza Colore a 24 bit” per migliorare la qualità dell’immagine riducendo il banding.
Questa modalità forza la console emulata in una modalità ibrida simile a RGBA8, dove i canali di colore sono a 8 bit per canale e il canale alfa rimane a 6 bit. Tuttavia, per Luigi’s Mansion, questa funzionalità non ha avuto alcun effetto sul banding.
Flacs ha notato un problema con la modalità “Forza Colore a 24 bit” su Dolphin, che non influiva sulle copie EFB dei giochi in RGB565. Questo comprometteva l’efficacia dell’ottimizzazione.
Flacs ha corretto questa falla affinché le copie EFB utilizzino anche RGBA8 quando “Forza Colore a 24 bit” è attivata, migliorando così l’esperienza di gioco, in particolare su Luigi’s Mansion.
5.0-20923 – Steam Deck: Imbottito il rapporto sulle funzionalità a 64 byte by endrift e ArcaneNibble
Nel report sui progressi precedenti, è stato trattato il 5.0-20148 – Riattivazione periodica del giroscopio di Steam Deck. Le versioni attuali di SteamOS cercheranno di disattivare i giroscopi che ritiene non vengano utilizzati.
Questo ha causato molti problemi, quindi questa modifica ha risolto il problema facendo sì che Dolphin riattivi il giroscopio su Steam Deck approssimativamente una volta al secondo.
A causa delle peculiarità di SteamOS, l’esecuzione di build di sviluppo su Steam Deck non è semplice per gli utenti. La maggior parte di essi ottiene le build di Dolphin tramite Flatpak delle versioni Beta.
Anche se la modifica è stata testata dai sviluppatori prima dell’integrazione, è stata solo dopo la pubblicazione del rapporto e del rilascio Beta che i Flatpak sono stati aggiornati, consentendo a questa modifica di essere adottata su larga scala dagli utenti.
L’autore della modifica, ArcaneNibble, ha verificato immediatamente il problema ma non è stato in grado di riprodurlo. Nonostante ciò, le segnalazioni sul problema continuavano ad arrivare.
Anche altri sviluppatori hanno tentato di replicarlo senza successo. Alcuni utenti e tester hanno svolto ulteriori verifiche, ma nessuno di loro è riuscito a riscontrare il problema. Nonostante gli sforzi, le segnalazioni persistevano. La causa del problema rimaneva ancora un mistero.
Il problema è continuato per settimane fino a quando non è stata scoperta la causa. Gli Steam Deck più vecchi presentavano il problema, mentre quelli più recenti no.
È emerso che l’LCD di Steam Deck ha subito una revisione importante nell’autunno del 2023, comportando cambiamenti significativi negli interni del dispositivo e l’utilizzo di componenti diversi, incluso il chip controller del controller Steam Deck.
Gli Steam Deck prodotti prima dell’autunno del 2023 utilizzavano un controller Atmel, mentre quelli successivi e tutti gli Steam Deck OLED utilizzavano un controller Renesas. Questa scoperta ci ha permesso di identificare il problema, confermato poi da test eseguiti dagli utenti.
Una volta identificata la procedura per riprodurre il problema, gli sviluppatori hanno chiesto assistenza a coloro che lavorano sullo sviluppo del Steam Deck.
Endrift, autore di mGBA e collaboratore di Dolphin, che ha recentemente dedicato molto tempo allo sviluppo di Steam Deck, si è offerto di aiutare.
Ha collaborato con l’autore della modifica per condurre una dettagliata sessione di debugging. Durante questo processo è emerso che ArcaneNibble ha trascurato di inserire un valore, che è stato identificato come causa del problema.
Codice rotto: const unsigned char pkt[] = {0x00, 0x87, 0x03, 0x30, 0x18, 0x00};
Codice funzionante: const unsigned char pkt[65] = {0x00, 0x87, 0x03, 0x30, 0x18, 0x00};
ArcaneNibble ha dimenticato di aggiungere il padding alla dimensione del pacchetto del pacchetto di report della funzione. Ecco come spiega endrift quanto accaduto:
Quando Steam ordina al dispositivo Steam Deck (o in precedenza al controller Steam) di modificare una impostazione, utilizza un elemento chiamato “report di funzionalità HID”.
Questi report possono essere lunghi fino a 64 byte in USB 2.0, e la dimensione di un report del dispositivo è definita nel descrittore di report, adeguatamente denominato, specificato dallo standard HID.
I report di funzionalità possono essere suddivisi in un massimo di 256 ID diversi, ciascuno dei quali può avere una dimensione separata come descritto nel descrittore.
Tuttavia, per un sistema dinamico come lo Steam Deck, talvolta i dispositivi definiscono una dimensione del report di 64 byte più lunga di quanto utilizzato e riempiono la fine con zeri, quindi definiscono l’ID al di fuori del descrittore.
Steam invia sempre un report completo di 64 byte, in conformità con il descrittore del report. Tuttavia, inviando un report di funzionalità con meno di 64 byte, l’implementazione sul dispositivo USB si confonde.
Molto probabilmente, successivi report di funzionalità vengono interpretati erroneamente a causa di questo, e uno di questi report interpretati erroneamente da Steam causa questo problema.
Tuttavia, i chip Renesas non sembrano confondersi e assumono semplicemente internamente che il report debba essere riempito fino a 64 byte anche quando ne vengono inviati meno.
Questo ha portato i controller Atmel a entrare in uno stato glitchato in cui operavano contemporaneamente sia in “Modalità Lizard” (i controlli predefiniti di fallback quando Steam non è in esecuzione) che in modalità normale, raddoppiando ogni input.
Endrift ha testato una soluzione e ha presentato una rapida richiesta di pull, risolvendo così il problema dei doppi input. Anche se la soluzione potrebbe sembrare semplice, individuare questo bug è stato estremamente difficile.
È stato necessario l’impegno dell’intera comunità di Dolphin Steam Deck per risolvere questo problema. Un ringraziamento speciale a tutti coloro che hanno segnalato il bug e hanno contribuito a risolverlo.
5.0-20941 – SDL: Aggiunta API GameController, pulizia by SuperSamus
SuperSamus ha apportato miglioramenti al backend di input SDL del progetto. In primo luogo, ha aggiunto il supporto per l’API GameController, un’astrazione che garantisce una mappatura coerente tra diversi tipi di controller.
Questo significa che gli utenti possono passare da un controller all’altro, ad esempio dal DualSense al controller Switch Pro, senza dover riconfigurare nulla.
Inoltre, SuperSamus ha ottimizzato il backend di input SDL, eliminando molte soluzioni alternative pensate per vecchie versioni di SDL che non sono più rilevanti per l’attuale backend SDL2. Grazie a questi miglioramenti, SDL è ora meglio che mai su tutti i sistemi operativi.
Inoltre, grazie a questa modifica, SDL è stato nuovamente abilitato per impostazione predefinita nelle build Linux del progetto, segnando un altro traguardo nel progresso di SDL.
5.0-20961 – Inizializza il Bounding Box solo se supportato dalla GPU/driver by AdmiralCurtiss
“Renderer” era un’astrazione nel codice di Dolphin che fungeva da interfaccia per i plugin video. Tuttavia, quando i plugin video sono stati integrati nel codice di Dolphin e sono diventati i backend video, “Renderer” è diventato un accumulo disorganizzato, riempito di numerosi frammenti di codice e funzionalità varie.
Pertanto, l’anno scorso, Phire ha intrapreso la missione di eliminare completamente “Renderer”, ristrutturando ampie porzioni del codice grafico di Dolphin.
Dopo l’implementazione di “Kill Renderer” in Dolphin, un grande refactoring del codice grafico, sono stati segnalati problemi da parte degli utenti con GPU molto vecchie. Ogni tentativo di avviare un gioco risultava in un errore “Impossibile creare il buffer di BoundingBox”.
Dopo Kill Renderer, Bounding Box veniva sempre inizializzato, indipendentemente dal supporto dell’hardware. Questo non influisce sulla maggior parte degli utenti, poiché più del 99% dell’hardware dei nostri utenti supporta la funzionalità.
Tuttavia, per qualsiasi hardware che non supporta Bounding Box, questa regressione ha completamente interrotto Dolphin.
AdmiralCurtiss ha esaminato il problema e ha apportato una correzione rapida. Con questo cambiamento, Dolphin funzionerà come prima di Kill Renderer su quelle GPU:
Dolphin funziona di nuovo e i giochi si avviano, ma se un utente prova a eseguire un titolo che richiede Bounding Box, potrebbe sperimentare dei problemi.
Avviso per gli utenti Nvidia
Sono state ricevute segnalazioni di corruzione delle texture in D3D11 su GPU Nvidia con i loro driver più recenti.
Questa problematica è ancora in fase di sviluppo, poiché non è stata ancora isolata e analizzata in modo completo, ma si ritiene che sia causata da un problema legato ai driver. Al momento, si consiglia agli utenti Nvidia di evitare di utilizzare il nostro backend D3D11.
Fonte: twitter.com
