Ieri ho effettivamente provato un po’ il #gaming Switch dal 3DS in portatilità, alla fine, e… che dire. 7/10. Certo, ogni tanto la connessione fa scherzetti e il gioco inizia a freezare per un po’, ma nel complesso si gioca con un lag accettabile e un video senza strani artefatti, veramente apprezzabile. Devo però capire perché in certi rari momenti il client crasha completamente invece di riuscire a ristabilire la connessione, e temo anche la batteria del 3DS si appiattisca troppo velocemente con questa #applicazione… ma vabbè, a sistema consolidato potrei anche usare il telefono. 🐚
Visto che voglio provare meglio il setup, mi sono portata avanti e ho fatto un programmino per #PC che legge direttamente gli input del gamepad virtuale e li invia alla #console; quindi, eliminando quegli altri due programmi necessari, sostituendoli con uno solo. La finestra inoltre visualizza il video da dispositivi di cattura standard, e quando lo implementerò riprodurrà anche audio, quindi sostituirà anche il riproduttore multimediale… per ora non ho ancora la scheda di cattura HDMI, quindi devo ancora usare SysDVR, ma almeno mi mostra il video della webcam (che mi serve per navigare nei menu di sistema, il DVR non lo trasmette), quindi già scendo da 4 app e finestre a solo 2. ✨️
https://octospacc.altervista.org/wp-content/uploads/2024/05/image-1.pngImplementare la lettura degli input del controller, e l’invio al demone sys-botbase tramite socket TCP, è stato un po’ intricato, ma alla fine il codice è venuto pulito, i tasti rimappabili tramite file config, e sorprendentemente sembra tutto ben funzionante dal primo momento… Nel senso, i comandi sembrano rispondere bene senza particolari accorgimenti; anzi, anche meglio di NXController, perché io invio direttamente i valori degli stick analogici alla console, mentre lui deve leggere valori rimappati alla tastiera e quindi tutti digitali. In effetti non ci avevo pensato quando mi era venuta questa #idea, ma effettivamente ho migliorato la mia #UX anche in questo modo, ora ho input più precisi. 🤏️Volevo inizialmente usare Ren’Py, ma ho subito scoperto che non include funzioni per accedere ai dispositivi video, né tantomeno ha la classe camera nella sua implementazione di #Pygame, quindi… ho usato semplicemente Pygame, e in poche righe di codice funziona già tanta roba, anche se la UI non è delle migliori. Dovrò investigare se davvero non ci sarebbe stato verso di usare l’altro engine oppure si, perché potrebbe tornare utile in futuro. Ancora versione molto WIP, diversi bug da sistemare, ma almeno l’ho già caricata … poi creerò anche dei pacchetti standalone (che includono già #Python e le librerie) per Windows e Linux. L’ho chiamato #FrameNX comunque, meglio evitare qualunque pretesto di violazione del trademark di #Nintendo per il nome #Switch… 🚨️
Ma, ovviamente, non era un mio #progetto secondario se non saltava fuori un #problema inaspettato mentre programmavo e testavo… il codice che controlla la versione dell’OS di pygame.camera è rotto su Windows Server, e quindi l’inizializzazione fallisce… evviva. L’ho identificato e sistemato subito, ho anche inviato la PR #4221, quindi non è stato un vero problema, però… che cazzo, non è possibile che tutto quello che finisce in mano a me si rompe… trovare bug in librerie così utilizzate e famose senza fare nulla di particolare non è roba da tutti, eppure ormai siamo ad uno a settimana, e chissà cosa mi riserva il futuro. 💣️