Questa voce fa parte 2 di 2 nella serie Retrogaming Stellare

Nel post che ho inviato ieri sera tardissimo quando sarei dovuta stare a letto da un pezzo, sperando il mio stato di delirio non abbia reso il tutto incomprensibile… ho accennato come ho buttato mezza giornata appresso a #RetroArch, che sul PC non mi funziona, considerata una rogna (e forse di più che semplicemente non ho scoperto) su cui non posso soprassedere. 🧪

Bene, se non altro sono felice del fatto che oggi, ricordandomi di come un tempo lo usavo e funzionava bene, ho (re)installato RetroPie sul Raspberry Pi 3, e… Dai, ma com’è possibile che qui non solo effettivamente funziona tutto, ma allo stesso tempo ho i vantaggi del PC (giocare con la mia orgasmatica tastiera meccanica cinese, su un display grosso), e il collegamento di diversi controller funziona senza sofferenze; e, per giunta, essendo un computerino, posso spostarlo dalla scrivania a qualunque TV di casa al volo…? 😾️

Dovevo farlo da subito, fanculo il PC desktop, considerando che la sua potenza non mi serve per emulare console del millennio scorso… ma mi resta comunque l’amaro in bocca. Perché comunque il Raspino è underpowered al punto che il menu XMB di RetroArch va a scatti, ma anche dato che devo domandarmi: perché sul PC c’è la rogna? Nello specifico, come mai i core libretro (che è il “backend” su cui si basa RetroArch e non solo) compilati per PC x86_64 sono assolutamente rotti? Ancora più precisamente, #QuickNES è rotto: non funziona il caricamento di stati. 🤮️

QuickNES è un core di #emulazione NES (no shit sherlock) che mi serve, sono praticamente costretta a preferirlo quando possibile perché, per la mia strategia di gaming in RetroArch sincronizzato, è l’unico che può girare su tutte le console dove mi serve… perché sul PocketGo (consolina portatile che uso oltre al 3DS) gli unici 2 altri core sono troppo lenti per girare al 100% NTSC/60Hz (e sappiamo che le ROM PAL per console casalinghe vecchie fanno spesso schifo, quindi non ho proprio scelta). 🪨️

I #savestate, al contrario dei salvataggi “normali” (SRAM), sono specifici ad ogni emulatore, quindi vanno creati e caricati solo con quello… viene da se che, se voglio sincronizzarli tra sistemi, devo usare lo stesso #emulatore su tutti. E, non solo per me in generale i savestate sono d’obbligo (soprattutto quelli salvati e caricati automaticamente, rispettivamente alla chiusura e all’apertura del gioco), ma quasi nessun gioco NES ha i salvataggi, e pochi hanno le password, quindi per il resto sono necessari a salvare i progressi. 🥴️

Quindi, com’è che sul PC questo core, e a quanto pare solo questo, riesce a creare savestate, ma poi caricandoli non succede niente (o forse, in un caso, dava un errore inutile, non ricordo)? Com’è che, oltre alla versione Flatpak (e Snap, che non ho), si può scegliere solo tra quella AppImage che fa segfault all’apertura del selettore di file, o quella di Debian per cui sono compilati solo 7 core in croce (tra cui manca QuickNES)? Ah, e com’è che non ha risolto il #bug nemmeno provare l’ultima build Windows x86_64 di RetroArch (in Wine, che sorprendentemente, per il resto, al di là di glitch con la finestra quando non massimizzata, funziona normalmente)? 😶‍🌫️️

Ma ancora, com’è che nessuno, e dico nessuno, pare aver segnalato questo #problema online, nonostante se mi succede con build del core sia nuove che vecchie di anni, significa che esiste da anni? Capita solo a me, perché ho un BIOS UEFI strano, o perché ho un pin della CPU rotto, o perché il microcode di AMD è buggato? O è capitato anche ad altra gente che, ritenendo come me che questo problema fosse individuale, ha esattamente come me evitato di segnalarlo? (È tutto così rotto.) 😭️

Sono ipotesi strane queste? Certo, ma abbiamo già verificato che il sistema operativo non c’entra, e che l’unica cosa che finora ho osservato cambiare il comportamento di questo emulatore è l’architettura CPU per cui è compilato! Questi problemi, assurdo ma vero, succedono sempre e solo su x86_64… è un’architettura proprio da buttare. O, magari, va buttato via il compilatore C per #x86_64 usato dal buildbot di #libretro… potrebbe essere qualsiasi cosa, a questo punto; il dato di fatto è che su ARM funziona e basta, viva ARM. 🙏️

https://octospacc.altervista.org/2024/09/17/librottro/

#bug #emulation #emulatore #emulazione #Libretro #problema #QuickNES #RetroArch #savestate #x8664

Retrogaming Stellare Archivi - fritto misto di octospacc

fritto misto di octospacc

Altri #problemi di #PlayStationPortable, ma in questo caso non colpa di #Sony: avevo visto (con rabbia e disperazione) che i #core Nestopia-UE e #QuickNES per #RetroArch (e questo punto chissà quanti altri!) facevano piantare per qualche secondo la #console, che poi si spegneva con un pop. A questo punto decido di vedere se anche su #PPSSPP… e si, succede la stessa cosa, quindi non è colpa del mio hardware. 🤯️

Il grazioso #emulatore mi dice però precisamente il motivo del #crash… un jump a NULL, che è una cosa non proprio bella (in alto in foto), e mi dice molto poco. Purtroppo sulla PSP mi serve uno di quei core, perché voglio tenere quanta più possibile della mia #emulazione centralizzata in RetroArch, e a quanto pare FCEUmm (l’unico altro disponibile per #emulare il #NES) ha qualche problema: inizialmente funzionava (come in basso a sinistra in foto), ma poi ha iniziato a rompere il video in modo #cursed (in basso a destra). (No, non ho provato a resettare tutta la configurazione, perché anche se risolvesse ora il #problema non potrei farlo ogni volta che si ripresenta.) 💀️

Purtroppo, come ormai sempre più mi capita, non trovo alcuna informazione rilevante al problema cercando sul web. E allora, unica mia possibilità: mi metto con l’animo in pace e provo a ritroso tutte le #build di RetroArch per la piattaforma, fino a trovare il punto di #crisi dove quei 2 core si sono rotti: a quanto pare, tra il 20 gennaio 2022 e il 5 marzo 2022; la #release 1.10.0 è a posto (stando a PPSSPP, ancora non ho provato sul vero metallo), mentre già la 1.10.1 presenta la #rogna. E noto una singola e particolare #differenza: il passaggio della #versione del #compilatore #GCC da 9.3.0 a 11.2.0. 🧐️

…A chi devo dare la colpa ora? Saranno stati quelli di GNU ad aver #rotto roba upstream? O piuttosto quelli dell’SDK per #PSP? Perché ho skimmato commit e release della roba di #Libretro, ma non riesco ad individuare il problema lì. Ma in ogni caso, perché certi core hanno smesso di funzionare brutalmente ed altri no? Questi sono i motivi per cui odio il #software. Ora non so nemmeno a chi devo creare la #issue a riguardo. 🗡️

Per ora, la mia unica #speranza è di usare questa versione vecchietta del #multiemulatore, sperando che non ci siano incompatibilità di savestate tra versioni diverse, perché voglio giustamente tenere quelle aggiornate sui dispositivi dove funzionano. Avendo poi più tempo, potrei tentare di compilare una versione recente del pacchetto usando il #compiler vecchio… ma probabilmente non ci riuscirò. 😩️

https://octospacc.altervista.org/2024/02/04/pspspsp-non-gradisce-nuovo-gcc/

#build #compilatore #compiler #console #core #crash #crisi #cursed #differenza #emulare #emulatore #emulazione #GCC #issue #Libretro #multiemulatore #NES #PlayStationPortable #PPSSPP #problema #problemi #PSP #QuickNES #release #RetroArch #rogna #rotto #software #Sony #speranza #versione

pspspsp non gradisce nuovo gcc - fritto misto di octospacc

Altri #problemi di #PlayStationPortable, ma in questo caso non colpa di #Sony: avevo visto (con rabbia e disperazione) che i #core Nestopia-UE e #QuickNES per #RetroArch (e questo punto chissà quanti altri!) facevano piantare per qualche secondo la #console, che poi si spegneva con un pop. A questo punto decido di vedere se anche su […]

fritto misto di octospacc

The QuickNES core is also getting switching of colour palettes via L/R buttons! #RetroArch #QuickNES
http://nitter.nixnet.services/libretro/status/1446479111678005248#m

2021-10-08 14:14:29

libretro (@libretro)

The QuickNES core is also getting switching of colour palettes via L/R buttons! #RetroArch #QuickNES