La gestione dell'#Input dell'utente nei #Videogiochi è una questione molto delicata.
Se si sbaglia approccio, si rischia di degradare le prestazioni dell'intera applicazione.
Supponiamo - quindi - di dover gestire l'input della tastiera...
La prima cosa che verrebbe naturale fare, sarebbe controllare se i tasti risultino premuti durante il classico `update` del #GameLoop…
Probabilmente con una catena di `if` "infinita" che verrebbero testati ad ogni aggiornamento di frame.
È un po' - ormai - che cito l'architettura #ECS. Ma come funziona realmente?
Sintetizzando e semplificando all'estremo, possiamo dire che si basa su 3 principi fondamentali:
1. Separazione delle responsabilità.
2. Ottimizzazione computazionale.
3. Design orientato ai dati.
Quest'ultimo punto - purtroppo - nel mio caso non può essere rispettato, data la natura di #JavaScript in cui tutto è un oggetto e nulla può essere garantito come "contiguo" in memoria.
Ma a parte questo... 😎
Ho finalmente terminato il refactoring del progetto, dal più classico dei #GameLoop ad un'avanzata e nuova architettura #ECS.
Per arrivare a ciò, ho scritto e pubblicato una piccola libreria: una mia personalissima implementazione dell'architettura ECS in #TypeScript.
Qui il repository, per gli interessati: https://github.com/Byloth/micro-ecs
---
Nulla di definitivo, ancora, eh!
Può esser ancora migliorato e ottimizzato ulteriormente!
É tutto ancora in divenire...
Stay tuned! 😉
No, non ho abbandonato il progetto. GIAMMAI!
Anzi... Sono sempre più determinato a volerlo portare a termine.
Il Mondo ne ha bisogno! 😌
Scherzi a parte...
La mia #OCD nel voler fare le cose perfette, mi ha costretto a sperimentare molte strade differenti.
L'ultima che ho imboccato, mi ha portato dritto dall'architettura #ECS: https://en.wikipedia.org/wiki/Entity_component_system
L'ho studiata e ho riscritto tutto seguendone i sacri dettami, permettendomi qualche piccola modifica affine ai miei gusti (#OOP).
Dopo il consiglio di ieri (sempre di ALTISSIMO livello) da parte del buon @shurizzle, in cui mi suggeriva di lasciar perdere i `Proxy` e trovare una strada alternativa, mi son buttato in alcuni test di performance.
Risultato: l'esecuzione tramite `Proxy`, richiede oltre il 220% del tempo impiegato da una funzione classica! 🤯
Poiché l'ottimizzazione è LA Priorità, ho cercato una soluzione diversa e altrettanto valida che non comportasse alcun overhead.
Alla fine l'ho trovata. 😏
Mai definito un oggetto #Callable o #FunctionLike in #Python? 🤔
Niente di più facile: basta implementare il metodo built-in `__call__` nella propria classe e... Fatto. That's it. 😌
Mai provato -invece- a farlo in #JavaScript o -peggio- in #TypeScript?
Sì... È possibile farlo anche in JS! 😏
È necessario ereditare da `Function` e strutturare il costruttore in maniera un po' "particolare", affinché restituisca un oggetto `Proxy`...
Uno strumento POTENTISSIMO, per la cronaca...
"Come lo feci" di @byloth Von Frankenstein
#TileMap & #Mipmap: non vanno d'accordo...
Online è una cosa risaputa; «Everyone knows it!» - mi han risposto, in un forum!
«#YesBut... Why?» - e cadeva il silenzio...
Qualcuno ha provato a darmi delle risposte che -sul momento- ho preso per buone... In seguito, rivelatesi errate!
Ci ho messo 2 settimane...
Ma potrò lasciare ai posteri il mio retaggio: come usare tilemap e mipmap insieme.
https://discourse.threejs.org/t/seams-artifacts-between-texture-tiles-when-using-mipmaps/72979/12
«Si può fare!» 🤯
Got it! 🤯 I finally understand what the problem actually is and why this happens! Thanks again to everyone who took the time to help me with my question. Really appreciated! ❤ TL;DR So… If you’re interested -like me- in understanding what’s happening here and -more importantly- WHY it happens… You’re -of course- in the right place. 😉 It all started with this CodePen, which I’d already shared previously: At first, it wasn’t clear to me how the fwidth function ...
Migrazione a #ThreeJS.
Il primo problema è che -la libreria- non dispone di un componente già pronto per la gestione delle #TileMap (a differenza di #BabylonJS).
Online non ho trovato nulla che facesse al caso mio...
Mi metto -quindi- di buona lena ad implementarlo.
Un banale piano, una texture da caricare e qualche riga di #TSL da scrivere... E le famose #Mipmap?
Le abilito ma -anche il mio #Shader, come quello di Babylon- non le gestisce correttamente.
Qui il risultato. 😞
#BabylonJS è un ottimo strumento!
Estremamente potente e molto più dev-friendly, rispetto a #ThreeJS!
In particolar modo, per tutto quello che riguarda la grafica #3D.
Dal loro sito -dopotutto- si evince in maniera chiara!
Altro vale per il #2D, invece, dove lo trovo ancora un po' acerbo...
Ma -suppongo- non ci sia proprio l'interesse, da parte del core-team, a spingere in questa direzione!
Peccato!
Ho dovuto fare marcia indietro e passare a Three.js.
Si riparte da capo! 🥲
Alla fine, ho optato per #BabylonJS.
Per quale motivo?
1. È una libreria interamente scritta in #TypeScript.
2. Ha già un motore di rendering stabile basato su #WebGPU.
3. Offre nativamente alcune funzionalità molto interessanti, come la #GlobalIllumination e la gestione della fisica #Ragdoll.
4. Include il motore fisico #Havok: usato anche nei giochi AAA.
5. È ben documentata e con molti esempi.
6. È parecchio mantenuta, con nuove release e fix ogni pochi giorni.
Matteo Bilotta 
