love2d stavolta che gira, nonostante la octo-oriented programming!
Sorprendentemente, appena qualche ora di sonno e qualche ora di scrittura magica un pochino avanti e indietro più tardi, e ho effettivamente trovato una soluzione al problema problemoso delle prestazioni imbarazzanti di Love2D caricato di una tale OOP che non gira affatto bene su una viemmina come quella di Lua… e, anche se come previsto il modo che ho dovuto mettere in atto è abbastanza spaventoso, non è nemmeno inadatto alla produzione, e anzi: è gnammastico. 😳
L’obiettivo in mente era una roba del tipo: avere nel possibile una programmazione orientata ad oggetti che, per ridurre l’overhead causato da troppi lookup in tabelle e troppe chiamate di funzioni in poco tempo, fosse basata principalmente sulla composizione, desiderio che è anche comune in Lua… ma, volendo evitare Lua, perché voglio invece qualcosa di fortemente tipizzato, perché altrimenti so che finisce rapidamente tutto a spacc. In questo senso, Teal è interessante, però, per motivi che ora non frecano, non mi convince più di tanto… e allora ho ragionato su cosa si potesse fare con TypeScript… 😨
Ecco: sorprendentemente, sfruttando semplicemente gli oggetti anonimi (uguali a quelli di JavaScript, che si mappano perfettamente a tabelle di Lua) in congiunzione con il sistema di tipi composti di TypeScript (che funzionano come le interfacce nella OOP, ma indicano tipi di oggetti), evitando completamente le classi del linguaggio… con la proprietà intrinseca degli oggetti in JavaScript (e in Lua, duh, in qualunque linguaggio interpretato) di essere componibili, ma combinati coi tipi lì, si riesce ad avere a livello di sviluppo tutta la sicurezza dei tipi di TypeScript, ma in output codice Lua estremamente pulito!!! (E che, per inciso, evita completamente l’uso delle metatabelle, anch’esse causa di rallentamenti.) 🤯
Benchmark stavolta niente, poiché palle, e anche perché i “fottuti rettangoli” hanno mostrato prestazioni negative inaspettate rispetto alle 2 versioni scritte a mano ieri in Lua… ma non perché il codice sputato fuori da TypeScriptToLua in questo caso sia sporco, quanto più perché ho già iniziato a reimplementare con questo nuovo paradigma il mio motorino desiderato, che ovviamente dell’overhead in più lo ha comunque, ma… Stavolta, la demo di Breakout sul 3DS è magicamente giocabile, non va più a 5 secondi al frame!!! (E sul PC mi si aggira su 1-2% di CPU, che è wow.) 🗽
Ora… boh, solo le pareti che mi tengono compagnia quando programmo sapranno dirmi come andrà avanti questo affarino. A parte il fatto che ho dovuto già ripensare abbastanza la API da come l’avrei voluta inizialmente — dovendo farla deviare già parecchio da HaxeFlixel, perché non sembra esserci modo di avere i tipi completamente sicuri dovendo allo stesso tempo minimizzare gli oggetti nidificati e le catene di funzioni — ci sono alcuni dettagli per cui questa cosa degli oggetti pseudoclassisti funzionano che mi sanno di strano, perché praticamente devo tenere le definizioni all’effettivo completamente separate dalle implementazioni (quindi, per esempio, devo usare Cacca.new() per creare una nuova cacca, ma TCacca per riferirmi al tipo…), ma sarà un TypeScript skill issue. 😶
C’è anche da dire che con questo mio accrocco non c’è incapsulazione, implementarla sarebbe un casino e costerebbe (per via di come funziona Lua, che costringe ad usare funzioni anonime per implementare questa cosa; funzioni che verrebbero interamente copiate su ogni singolo oggetto) lo spreco di un fottio di memoria (termine tecnico)… ma non lo vedo come un problema; casomai dovesse servire il distinguere campi pubblici da privati, basterà rubare la convenzione di Python per cui le variabili che iniziano con gli underscore sono ad uso interno. E, davvero, l’unico aspetto negativo di questa macchinazione credo sia il fatto di non poter ottimizzare ulteriormente senza ridurre il riuso del codice, avendo svariate chiamate a funzioni miste che per quanto piccole sarebbero meglio inlinate, cioè copincollate dal compilatore anziché lo sviluppatore, se solo Lua lo permettesse… (…E se scrivessi un postprocessore Lua per fare esattamente ciò???)
#demo #development #LOVE2D #Lua #OOP #optimization #optimizing #ottimizzazione #programmazione #typescript #TypeScriptToLua
