Sono sicuramente un po’ paxxerella per iniziare nuovi progettini mezzi complicati ancora prima di finire i precedenti, ma che ci voglio fare? Quantomeno, a ‘sto giro ho effettivamente portato #FrameNX, il programma iniziato ieri, ad uno stato di completezza, tant’è che da ora penso non avrò alcun intoppo ad usarlo… e quindi l’ho anche rilasciato già stasera pubblicamente con tanto di README quasi logorroico (il link di stamattina era privato): https://octt.itch.io/framenx 🪟
https://octospacc.altervista.org/wp-content/uploads/2024/05/screenshot_2024-05-05-02-14-47-843_io2733305805360369156-960x987.jpgLa UI è ancora grezza, ma ho migliorato i messaggi a schermo, aggiungendo avvisi a scomparsa quando si verifica un errore o viene fatta un’azione (qualcuno l’ho dimenticato però oooops, dovrò metterlo, ma poca roba). Funziona in ogni caso solo con la tastiera, perché il mouse è dannoso e #programmare le hitbox sarebbe uno sbattimento in più per nessun buon motivo, dato che comunque questa per ora è una #applicazione solo PC. (Ormai si sta costruendo una lore dietro questa interfaccia, ops.) ☠️In realtà sotto la scocca quella UI è comunque più complicata di quanto sembra, anche se è relativamente semplice, perché in primis già solo per le notifiche ho dovuto implementare tutto un sistema di coda… poi ho dovuto mettere il rendering video su un thread separato, perché l’accesso alla camera rallentava tutto il loop e quindi avrebbe inficiato sulla lettura degli input… ma spostarmi su un thread di sfondo ha introdotto non pochi casi limite strani che ho dovuto sistemare con ancora più codice… Comunque relativamente poco #codice, perché il #Python è simpatico e non è stato creato da gente che vuole vedere gli altri programmatori impiccarsi. 🦍
Btw, ho continuato a trovare altri problemi in #Pygame… Innanzitutto, un bug strano con lo stack dei joystick (cioè controller da gioco in generale, direi che il nome è scelto malino) che fa si che questi non mandino più eventi dopo essere stati inizializzati se non se ne tiene qualche reference nel codice (come una variabile assegnata che non muore), come se fossero levati dal garbage collector altrimenti… stranissimo. E poi, il fatto che per riprodurre il suono di dispositivi di input audio, tra metodi non wrappati e quindi richiamabili solo con la API grezza di SDL2, stack audio buggato in generale e comandi che letteralmente non sortiscono effetto, altri comandi che invece causano segfault alla chiusura del #programma… mi pare di stare programmando con una tempesta di raggi cosmici addosso. Ciò non lo gradisco. 😾
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. 💣️