Per oggi avrei dovuto cacciare la soluzione di emulazione finalizzata per i giochi Windows [esenti da requisiti hardware irrealistici] con v86… ma a quanto pare è un po’ impegnativo, devo implementare almeno un’altra hack per soddisfare i requisti essenziali. Però, nel frattempo Boxedwine è rimasto un pensiero fisso, soprattutto dopo avaver constatato che la versione nativa su Windows e Linux funziona e basta: è praticamente plug-and-play con tutti i giochi che sono risaputi funzionare, al contrario del Wine “essenziale” proveniente da upstream o da una distro qualsiasi. 📦
Touhou 6 su Boxedwine per Windows mi è partito, e con una versione (la 5.0 almeno) gira pure bene, ci ho potuto giocare (anche se le ventole del portatile sono volate nel processo). Non credo che adesso magicamente riuscirò a farlo andare sulla versione web, perché c’è un inghippo: il giochino partiva con l’impostazione della grafica nativa, ma non se impostata su quella emulata (che credo sia l’unica utilizzabile nel browser), ma già è qualcosa: il vino inscatolato potrebbe tornarci utile quantomeno per creare repack di giochi che, con un singolo file che parte sia su Windows che su Linux, si giocano e basta senza alcun imprevisto dei soliti del gaming PC… 🦜
Però allora ho pensato: se quello che cambia tra build nativa e web di Boxedwine è solo il codice macchina dell’emulatore (e le sue chiamate all’API host), che però esegue sempre le stesse robe precise al suo interno, com’è che escono fuori quegli strani problemi di compatibilità, tipo il fatto che Wine 5.0 non parte sul browser? La risposta è: il 5.0 che ho provato io non è lo stesso che scarica la versione desktop. Questo è saltato fuori dopo che ho provato a far partire quello da web, e in effetti non crasha come l’altro giorno! E, addirittura, ci gira il 6.0, che nemmeno credevo fosse supportato! Detto in modo diverso: questo progetto è mantenuto un po’ a culo da quello che vedo, ci sono diversi download nominalmente equivalenti sulle diverse pagine ufficiali, sia di questi filesystem Wine che dell’emulatore in sé (ma per quello non c’è dubbio che la versione migliore sia quella dal Jenkins). 🧬
https://octospacc.altervista.org/wp-content/uploads/2024/05/Screenshot_20240527-160241_Firefox-Beta.pngPer fare tutte le prove possibili voglio ora avere sotto mano tutte le versioni dei rootfs che trovo, varie impostazioni di emulazione, e il caricamento immediato di applicazioni diverse, quindi ho iniziato a tirare su questo wrapper per la versione HTML; modificare file di configurazione o parametri URL ogni minuto era diventato doloroso, e la UX del launcher PC è scomodissima. Per ora è sul server casalingo, perché così posso applicare al volo modifiche ai file, ma se dovessi mettere troppe app e finire lo spazio allora creerò una repo Git. Boxedwine desktop offriva per il download anche queste tante altre versioni, quindi le ho messe… ma alcune sembrano ugualmente rognose (tra cui le 1.x, ironicamente), quindi indagherò meglio. Per il lago d’uria: https://hlb0.octt.eu.org/Misc/BoxedWine/ 💦https://octospacc.altervista.org/2024/05/27/lo-scatolvino-di-distrazione/
Quei gamer che come me hanno nell’animo il PC masterrace, ma nella pratica odiano il tedio contro cui ci si imbatte appena si vuole effettivamente giocare a qualcosa per PC, staranno con ansia aspettando progressi sulla questione di giochi Windows nel browser. Quindi, che ho fatto ieri? …Un cazzo di niente! 🥰
Ho perso mezza giornata cercando invano di far funzionare prima alcuni programmi di benchmark, e poi Touhou. Ho dovuto installare DirectX 9 per quei programmi, ma poi comunque questi non partivano, perché a quanto pare DX9 non include rendering via software per Direct3D, e in v86 non c’è alcuna GPU. Pazienza, per quelli me ne farò una ragione, non ho vitale bisogno dei benchmark… però per i giochi è una rogna. Sorprendentemente, Touhou 6 parte in questo ambiente mezzo sfasciato, ma c’è un problema: non so come il gioco gira, riesco anche a muovermi nei menu alla cieca e avviare una partita, ma viene renderizzato solo lo sfondo e letteralmente null’altro, quindi non si può effettivamente giocare. (Dettagli più precisi in questa chat qui.) 🤬
https://octospacc.altervista.org/wp-content/uploads/2024/05/photo_5080513907201780824_x8412736725975051660-320x169.jpghttps://octospacc.altervista.org/wp-content/uploads/2024/05/screenshot_2024-05-24-00-21-42-337_org2221662542601539196-960x418.jpgHo provato allora con DirectX 8a, che pare essere l’ultima versione con software rendering prima di DX10 (che lo ha reintrodotto dopo che fu tolto tipo), e stando a Wikipedia ES dovrebbe essere il minimo richiesto da Touhou 6 (altre fonti specificano semplicemente DX8 generico). E qui il gioco però smette di partire, restituendo un errore non molto chiaro… che ho decifrato con Reddit e Google Traduttore, ma la cosa non mi ha dato alcun aiuto, non so a cosa si riferisca l’errore esattamente, e nessuna opzione disponibile tra configurazione del gioco e impostazioni di Windows ha risolto il problema (chiede di cambiare una roba che online non vedo discutere, probabilmente manco esiste). 🐭Proprio stamattina ho voluto dare una chance a Boxedwine; pensandoci, posso usarlo in maniera complementare a v86, nei casi in cui questo non va bene. Fare tutto tra telefono e tablet (dato che non sono a casa) è stato un casino, tra lentezza generale, memoria che si satura (per questo devo usare due dispositivi alla volta) e via… e ugualmente non è servito A NULLA. A parte il tempo perso (tanto, maneggiare con gli ZIP sullo Ximi non è veloce) tentando di avviare gli ultimi pacchetti distribuiti dall’autore per Wine 1.7 e 5.0, che evidentemente non funzionano (il primo non so perché, il secondo è colpa di #11), usando il pacchetto di boxedwine.org sono riuscita ad almeno avviare il gioco, ma termina con un errore che credo sia proprio lo stesso di Windows 2000. Nella console di Wine vedo prima del crash una riga fixme:win:EnumDisplayDevicesW ((null),0,0x32f898,0x00000000), stub!, che può confermare i miei sospetti, ma non so se centri o sia una coincidenza. Guardando i file di Boxedwine credo ci sia DirectX dall’8 al 10, quindi non sarà un problema di librerie mancanti. 🐞
Se avete idee, per favore suggerite, perché sono proprio alla frutta, ho finito di giocare ancor prima di iniziare. Il problema è che il gioco non parte con software rendering, anche se in teoria potrebbe usarlo, sospetto che cerchi appunto una GPU e halti se non la trova. (Qui ho caricato il log di Wine.) Ieri sera ho fatto anche tardissimo per andare a letto, per via di questa roba, ma vi giuro ci ho messo un secolo a prendere sonno… questa cosa ora mi tormenta e devo risolverla: so che Touhou è abbastanza leggero da poter girare nel browser, se giochi anche molto più pesanti ce la fanno, quindi ora pretendo di averlo nel browser! Voglio giocarci in Sala Museo! Il problema sono ste cazzo di API; possibile che solo sulle console i giochi funzionano e basta? (Dovrò fare un emulatore Switch per il web, a proposito…) 🧱
Parlando di #emulatori non morti, forse saprete che ne esistono tipo solo 2 che emulano il #NintendoDSi (oltre alla versione base del #NDS), e #melonDS è quello che funziona meglio. 💫️
Mi sta essendo utile l’ #emulazione#DSiWare per controllare cose e catturare schermate sulla #FotocameraDSi senza dover per forza usare la #console reale, per quell’articolo che sto finendo*. Però, per quello non mi serve davvero scattare foto, e quindi mi è stata comoda la funzione per impostare come flusso della camera immagini salvate sul PC (Config > Camera Settings > Image file), che avevo generato al volo con Bing AI per averne della tipologia che mi serviva e con un’aspetto un po’ stock, dimostrative appunto. 🎁️
Preparate il #firmware DSi (che vi consiglio di scaricare da qui, è il dump che uso io e confermo che funziona) da dare all’emulatore, creando due cartelle separate per i file DS e #DSi, e rinominando i file in modo preciso, altrimenti la #app si lamenta:
biosdsi7.bin => dsi/bios7.bin
biosdsi9.bin => dsi/bios9.bin
biosnds7.bin => nds/bios7.bin
biosnds9.bin => nds/bios9.bin
dsfirmware.bin => nds/firmware.bin
dsifirmware.bin => dsi/firmware.bin
dsinand.bin => dsi/nand.bin
Fate “Boot firmware > DSi”, da lì si può avviare la magica #applicazione fotografica, date il permesso quando richiesto, e se tutto va bene potete godere. ❤️🔥️
*(Sto facendo progressi per l’articolone, ma troppo lentamente, nonostante io abbia scritto ben settemila parole vedo che mi mancano ancora troppe cose… la mente è pazza, questa situazione è assurda. 😵💫️)
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.) 💀️
https://octospacc.altervista.org/wp-content/uploads/2024/02/image-4-960x524.pngPurtroppo, 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 #release1.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. 🧐️
https://octospacc.altervista.org/wp-content/uploads/2024/02/image-5-960x275.png…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ò. 😩️