Creare mod: metodi per ridurre l'uso di memoria e banda

[Hamlet]

Per i programmatori dilettanti, e per chi programma per professione, alcune considerazioni alle quali sono arrivato ultimamente.
Se ne conoscete altre, suggerite!

- L'uso della memoria
Programmando si impara l'uso delle variabili, mi sono reso conto che l'abitudine comune di dichiararle prima del corpo del programma (in un mod per minetest) consuma spazio inutilmente. Fingiamo per esempio di scrivere 10 mod aventi 5 variabili ciascuna: stiamo allocando (riservando) spazi di memoria per 50 variabili.

Esempio pratico:
local s_MOD_PATH, s_userName, i_mobSconfitti, ecc.

Se pensate che un server ha mediamente 100 o 200 mod, immaginate quante variabili allocate (spazi di memoria riservati) possono esserci.

Per risolvere questo piccolo-grande problema, ultimamente scrivo i miei mod facendo molta attenzione a usare il minor numero possibile di variabili "locali-globali" (le classiche dichiarate a inizio programma), e a usare variabili "locali-locali" in procedure o funzioni; l'ambito delle variabili è limitato a quella porzione di codice, una volta eseguita la procedura o la funzione le variabili sono deallocate, liberando così spazi di memoria utili per altre cose.

Nei casi in cui è possibile, svuoto le variabili "locali-globali" assegnandogli "nil" a fine esecuzione se proprio non riesco a spostarle in una procedura o funzione.

È la scoperta dell'acqua calda, me ne rendo conto, ma mi domando quanti di noi ci abbiano mai fatto caso.

- L'uso della banda
A fare la parte del leone nel consumare banda sono le immagini (textures).

Innanzitutto è possibile ottimizzarle (personalmente uso optipng) riducendone la dimensione ed eliminando i metadati (es. "Created with The Gimp").
Spesso ho rilevato riduzioni di dimensione del 50%, se non del 95%.
Una bella differenza!

In secondo luogo, non si usano gli strati (overlay) e la colorazione hardware: si creano direttamente 10 immagini identiche ma dai colori differenti (pensate alle immagini usate per i blocchi contenenti minerali).

Il motore consente di creare 1 immagine, per esempio quella di un minerale, e applicarla sopra all'immagine del blocco di pietra che contiene quel minerale (ecco lo "strato", "overlay"), e colorarla in modo differente per ciascun nodo.

Quindi invece di avere 10 immagini di "minerali" (ores) se ne può creare una, applicarla e colorarla diversamente su ciascun nodo.

Risultato: invece di scaricare decine di immagini, se ne scarica una. Si risparmia anche spazio su disco.

Un altro esempio pratico sono le "skin", le "pelli" applicate al personaggio: invece di creare 100 skin diverse se ne può creare una neutra (l'omino nudo) alla quale poi potremo applicare un colore rosato se caucasico, sul nero se africano, ecc.
Sopra a questa potremo poi applicare uno strato (layer) per gli altri particolari: occhi, capelli, abiti, ecc.; ciascuno di essi a sua volta una forma neutra, successivamente colorata (colore degli occhi, colore della maglietta, ecc.)

Un rapido conteggio delle combinazioni possibili, pensando a parti essenziali di un personaggio, colorate dei 7 colori dell'arcobaleno:

scarpe - 7
pantaloni - 7
maglietta - 7
occhi - 7
capelli - 7

7 elevato alla 5^, cioè 7*7*7*7*7 = 16807

Meglio avere 16800 file .png in un enorme database, o averne 5 assemblabili in altrettante combinazioni?

Pensate al numero di texture che probabilmente scarichiamo connettendoci a un server, numero che potrebbe essere abbattuto a una manciata di immagini ben usate.


Ci sono poi altre finezze che riguardano la stesura stessa del codice; so che a volte usare n = (n + 1) è più veloce rispetto a n += 1 o ++n / n++... ma questa è "magia nera" per programmatori professionisti; non so in effetti se in LUA queste differenze esistano o siano presenti solo in altri linguaggi.


Se conoscete altri metodi per risparmiare memoria/banda/lag, condivideteli!

[Zughy]

Anch'io inizialmente usavo optipng ma ora vado di PngOptimizer che ottiene lo stesso risultato (se non migliore) e basta trascinare tutto in un colpo. Oltre che per Windows e Linux Debian/Ubuntu, lo si trova senza problemi anche sull'AUR per chi ha distro come Manjaro

https://psydk.org/pngoptimizer

[Hamlet]

Anch'io inizialmente usavo optipng ma ora vado di PngOptimizer che ottiene lo stesso risultato (se non migliore) e basta trascinare tutto in un colpo. Oltre che per Windows e Linux Debian/Ubuntu, lo si trova senza problemi anche sull'AUR per chi ha distro come Manjaro

https://psydk.org/pngoptimizer

Grazie per il suggerimento!

[_Zaizen_]

Ci sono poi altre finezze che riguardano la stesura stessa del codice; so che a volte usare n = (n + 1) è più veloce rispetto a n += 1 o ++n / n++... ma questa è "magia nera" per programmatori professionisti; non so in effetti se in LUA queste differenze esistano o siano presenti solo in altri linguaggi.

Su Lua non è possibile incrementare/decrementare le varibili con ++/-- quindi bisogna per forza usare n = n + 1.
Non ho mai ben compreso il perchè ma rimane una feature che se presente non dispiacerebbe.

[Hamlet]

Su Lua non è possibile incrementare/decrementare le varibili con ++/-- quindi bisogna per forza usare n = n + 1.
Non ho mai ben compreso il perchè ma rimane una feature che se presente non dispiacerebbe.

Penso che sia una scelta di "indispensabilità"... volendo tenere il linguaggio piccolo, semplice e compatto avranno deciso di non implementare quegli operatori.

Piacerebbe anche a me, ma, pazienza!