GameMaker Italia Forum

In alcuni rari casi(in genere nel 3d) potreste aver bisogno di usare array tridimensionali per immagazzinare dati. Un'esempio può essere fare un mondo cuboso in stile minecraft o semplicemente immagazzinare altri dati importanti ad una griglia per un particolare sistema di IA basato sulla diffusione o gestione dei gas.
Potreste ovviamente usare ds_list dentro una griglia o viceversa ma il risultato risulterebbe piuttosto lento e non vi permetterà veloci calcoli sulle aree come avviene per le ds_grid.
Ho così pensato di fare una semplice e veloce dll per gestire quelle che io chiamo "ds_cube" che non è altro che un'array tridimensionale e vi permetterà di gestire grosse quantità di dati in maniera molto veloce.
Per il momento ha solo le funzioni indispensabili: Tutte queste funzioni hanno dei controlli appositi per evitare che commettiate errori "gravi" quindi elimina memoria solo se esiste, non scrive/legge valori fuori dall'array ecc.

Ho testato tutto a dovere ma potrebbero esserci comunque dei problemi quindi se notate qualcosa di strano avvisatemi.
In caso di errori da parte vostra(leggere valori su un'indice che non esiste) semplicemente restituisce false, non ho ancora messo message box vari per debuggare facilmente ma ho intenzione di metterli(assieme ai commenti nelle varie funzioni).

Il mio obiettivo è quello di aggiungere funzionalità per i calcolo sulle aree anche se non ho ancora deciso se mettere o no un controllo sulle stringhe. Penso di no visto che avrei difficoltà con il tipo di dato restituito(forse è addirittura impossibile) quindi per ora mi accontento dei valori(che sono double)

Sono sicuro che interesserà a ben pochi e che finirà nel dimenticatoio ma intanto ho fatto qualcosa.
Link download: http://www.megaupload.com/?d=8AT4310J
Source: http://pastebin.com/pkArSPNG

giusto questi giorni sentivo la necessità di un array tridimensionale arrivi a "FAGIUOLO".
Grande jak

oggi mi sento rompipall... intendevo dire "preciso".

nessuno aspetta il post kilometrico e pignolo (ma anche teorico) del barone!

A livello fisico naturalmente ogni array è sempre monodimensionale: l'accessibilità è a una sequenza di word di memoria, non è organizzata in maniera bidimensionale. Quindi una cella di memoria ha una cella "prima" ed una cella "dopo", ma non ne ha una a "sinistra" ed una a "destra".
Per questa struttura fisica della memora l'array (monodimensionale) diventa un tipo di dato comodissimo per accedere alla memoria.
memorizzo l'indirizzo base dell'array
memorizzo quale elemento dell'array voglio accedere
accedo al byte (indirizzo base + elemento_array*dimensione_in_byte_di_un_elemento_dell'array)

per chi sa il C:

Basi di C ha scritto:vettore[3] è un operatore binario che compie questa operazione *(vettore + 3*sizeof(*vettore))

cioè "accedi alla zona di memoria" identificata dalla zona di memoria del primo elemento di vettore (in C il nome dell'array in realtà è una costante che "contiene" l'indirizzo di memoria del primo elemento utile dell'array).
questo, sempre in C, permette anche di fare. puntatore[2] equivale a *(punta + 2 * size_of(*puntatore));, e poichè puntatore contiene l'indirizzo del primo elemento di vettore accedo proprio a vettore[2].
Questo fa anche capire perchè i vettori devono avere l'indice che inizia per 0. E spiega perchè i linguaggi che hanno un indice del vettore che può iniziare non per zero sono "di serie B" (ok, dai, di alto livello ).

Tutto questo per spiegare come funziona il "vettore bidimensionale"...
(chiedo venia, non ho la certezza se il vettore multidimensionale è memorizzato "prima tutta la prima riga" poi "tutta la seconda riga" o al contrario "prima tutta la colonna", poi "tutta la seconda colonna".
Sono quasi certo sia il primo caso, invoco Sla per la correzione. Proseguo ragionando con il primo caso)

int vettore[3][4]; // un vettore 3 righe per 2 colonne

vettore[1][2] si traduce in
*(vettore + 1*size_of(*vettore[]) + 2*size_of(*vettore))
cioè accedo all'indirizzo di memoria di:
base del vettore
+ dimensione di una riga (pari al numero delle colonne) -> quindi la dimensione di 4 elementi (un elemento "riga" è come se "puntasse" ad un vettore composto da "numero di colonne" elementi
+ dimensione di due elemeti (la dimensione dall'oggetto puntato da vettore è un intero)
Nel caso specifico indirizzo base + 4 interi + 2 interi (sesto elemento, la numerazione parte da zero!)

il mio vettore 3*4 è
**** riga 0
**** riga 1
**** riga 2
ed io accedo alla X
**** riga 0
**X* riga 1 + 3 elementi base
**** riga 2
in realtà in memoria il mio vettore è:
******X***** //una riga da 3*4 elmenti ed accedo al sesto (numero da zero!)

E così via per ogni tipo di vettore con più dimensioni.

Quindi un vettore ndimensionale può essere realizzato con uno monodimensionale a patto di conoscerne a priori la size di ogni dimensione!
Per come gestisce GML i vettori se si ridimensiona a posteriori si fa del gran casino!!!!

in GML

var x, y, z.
x= max_righe_matrice; //numero righe
y= max_colonne_matrice; //numero colonne
z= max_altezza_matrice; //numero altezza....
//inizializzo tutto a zero!!!
vettore3D[(x*y*z)-1]= 0;

script_accedi_vettore_3d(a,b,c); //occhio: qui a,b,c sono i tre indici, vanno da 0 a (max_*_matrice-1)
return ( vettore3D[a*(y*z)+b*z+z] )

Inizialmente volevo fare un'unico array ed usare quel calcolo per fare le varie dimensioni dell'array ma poi per comodità quando farò calcoli su aree e chiarezza del codice ho deciso di fare un "vero" array(per così dire) senza dover usare richiami a funzione(dentro al codice c++) per usare un determinato valore.
E' assolutamente vero che con game maker(come con tutto) si potrebbe gestire un'array ndimensionale partendo da uno monodimensionale(bè sottosotto avviene così alla fine) ma game maker ha il difetto della mancanza di puntatori di conseguenza un'array è più difficile da gestire di una ds_grid in quanto quest'ultima è provvista di indice numerico. Con gli array devi usare nomi fissi mentre usando indici permette una rapida gestione di tutto il sistema.
Tempo che fu provai a fare una serie di script per una cosa che non ricordo sfruttando questo trucchetto dell'array ma senza indice numerico gli script diventavano poco riusabili(o lenti usando le funzioni per le variabili).

PS: Baron, ma come fai a rinunciare alle bellissime classi del c++? Io me ne sono innamorato appena le ho viste mentre tu sei ancora fedele al C. Non so come fai a resistere alla tentazione

Jak ha scritto:PS: Baron, ma come fai a rinunciare alle bellissime classi del c++? Io me ne sono innamorato appena le ho viste mentre tu sei ancora fedele al C. Non so come fai a resistere alla tentazione

oh bhè, ma non ci rinuncio... le ho usate eccome. Semplicemente ho usato molto più il C puro che non il C++.
Però sinceramente trovavo più affascinante programmare in C sul dos che non sotto windows, dove per poter usare le funzionalità ormai ritenute basilari ti dovevi studiare decine e decine di classi windows...
il C++ l'ho usato all'80% ancora sotto dos

premetto che non ho letto il mega baron-post, che probabilmente parla proprio di questo.. ma.. array in 3 dimensioni si possono fare anche in GM, e forse senza DLL è più veloce XD. Metti che X,Y,Z (maiuscole) sono le dimensioni del tuo array, basta che allochi X*Y*Z celle contigue, array[X*Y*Z] va benissimo.
Per accederci con un'interfaccia "tridimensionale" con i tre parametri x,y,z (questa volta minuscoli), farai così:
array[(X*Y)*z+x+X*y]

Sì, è esattamente quello che ha detto baron. Tuttavia l'idea originaria della dll era appunto la velocità per via dei calcoli sulle aree inoltre ricordati del limite di 32000 sugli array di gm(evitabili con le ds ma non è la stessa cosa)

Molto interessante jak. Una cosa che mi interesserebbe ancora di più sarebbe un test di performance, anche una cosa molto semplice tipo il tempo impiegato per (inserisci un numero molto alto) chiamate a funzioni ds_cube confrontato con l'equivalente su un array bidimensionale tipo ds_grid .

bè, le chiamate a dll sono relativamente lente, sicuramente più di leggere un'array o una ds_grid.
Si guadagna parecchio invocando external_call() direttamente piuttosto che fare degli script che invocano. Questo progetto inizialmente era pensato per calcoli sulle aree molto potenti e fare simulazione di path_finding, IA e diffusione di gas tramite appunto sistemi tipo diffusione ma non l'ho più continuata.
Anche utilizzarla per memorizzare grandi quantità di dati stile minecraft era una delle idee originarie.
Cioè, dopo che io stesso ho cominciato ad odiare il progetto ora lo vedete interessante?
Bè dai, se un giorno mi viene voglia potrei continuarla, per fortuna il source è ancora online anche se non ci metto molto a rifare una cosa simile...

Ah ma non ho visto che il topic ha già diversi mesi, penso che me lo sono perso quando lo hai postato a gennaio...

gennaio? io l'ho trovato in messaggi recenti, per questo ho risposto xD

Beh, se riesci a migliorarlo in performance, potrebbe essere interessante appunto utilizzarlo come motore voxel/minecraftiano.
O quantomeno complementarlo con tutte le funzioni di ds_grid circa il riempimento di volumi, il flood_fill 3D, path search, etc.
Fornire solo l'accesso al singolo elemento, a meno che non sia drammaticamente più veloce non giustifica una dll, si va di array 2D di liste o soluzioni native, multipiattaforma e con più funzionalità (ds_grid di array/ds_list?)

Circa la simulazione di fluidi/gas, è interessante, ma secondo me lo sviluppo diventerebbe un po' fine a se stesso. Voglio dire, è un esercizio interessante, ma penso ci rimarrei male se io sviluppassi qualcosa di simile per GameMaker e nessuno se ne servisse

NeatWolf ha scritto:

Spoiler

Bello il nuovo logo Jak, non pensavo il forum supportasse gli avatar animati Engine di cosa?

Jak ha scritto:

Spoiler

Nocche non ci sarebbe mai riuscito interamente da solo senza le mie "direttive".
E' incredibile che devo dirgli io come fare ciò che sa fare meglio
@neatwolf... probabilmente oggi saprai tutto

guidox ha scritto:

Spoiler

Senza dirlo a nessuno... l'ha fatto nocche... xD
E poi certo che supporta gli avatar animati [Guarda a sinistra]

NeatWolf ha scritto:

Spoiler

Evabbè, poteva essere una feature "VIP only"
Oh, si, finalmente potrò mettere un logo bello lampeggiange, di quelli "Epilepsy guaranteed 100%"

Và, resterò sintonizzato per veder di che si tratta.