Questo sito utilizza cookies solo per scopi di autenticazione sul sito e nient'altro. Nessuna informazione personale viene tracciata. Leggi l'informativa sui cookies.
Cos’è? Si tratta d’un programma per Windows per l’elaborazione di mappe in forma di labirinto 2D sullo stile di quelle del classico gioco del Sokoban.
Qual è il formato delle mappe generate? Le mappe generate consistono in una serie di valori di tipo DWORD (praticamente un unsigned int a 32 bit in Win32) i cui quattro bit meno significativi indicano i passaggi “aperti” della mappa. L’identificazione dei passaggi avviene in senso orario a partire dall’alto.
Ad esempio, se i quattro bit meno significativi di una certa casella contengono il valore 5 (binario: 0111), risultano “aperti” i passaggi a nord, a est e a sud, mentre risulta “chiuso” il passaggio a ovest.
I rimanenti ventiquattro bit di ciascuno dei valori della mappa (quelli più significativi) possono essere individualmente attivati/disattivati per rappresentare le situazioni che si preferisce — dipende dall’uso che s’intende fare della mappa.
Formato dei file I dati elaborati vengono salvati in file di estensione .dat con una strutturazione molto semplice: il file è aperto da un’intestazione che occupa 19 byte e contiene la stringa del tutto convenzionale “MappaLabirinto.0001” e due valori interi senza segno a 32 bit che rappresentano rispettivamente la quantità delle caselle in verticale e in orizzontale della mappa; l’intestazione è seguita dai valori abbinati a ciascuna casella, ordinati in senso orizzontale, una riga dopo l’altra.
Dimensioni della mappa Il programma può elaborare mappe con dimensioni comprese tra un minimo di 6x4 caselle (minimo 6 caselle per riga, su 4 righe) e un massimo di 128x128 caselle. La quantità massima effettiva delle caselle impostabili è però molto probabilmente minore di 128x128, perché il limite effettivo dipende anche dalle dimensioni in pixel d’ogni casella e dalla risoluzione corrente dello schermo.
ATTENZIONE! Sono un hobbista e l'affidabilità delle mie conoscenze informatiche è molto limitata. Non prendere come esempio il codice che scrivo, perché non ho alcuna formazione accademica e rischieresti di apprendere pratiche controproducenti.
Al momento sono bloccato perché non riesco a risolvere un problema che ho già descritto in "GDI dà i numeri".
Tutto funziona come dovrebbe finché non si apre o si salva un file. Da quel momento, il programma non carica più gli sprite personalizzati da file anche se le dimensioni della casella impostate coincidono con quelle dei file.
DESCRIZIONE DETTAGLIATA DEL MALFUNZIONAMENTO
Provando questa serie di operazioni...
1. Lancio del programma (viene usata la grafica personalizzata, da file)
2. Modifica della mappa, tracciando un qualsiasi percorso
3. Cambio delle dimensioni delle caselle, dal menu Impostazioni->Dimensiona caselle... Non essendo disponibili file per caselle di dimensioni diverse da 64x64 pixel, le immagini precedentemente caricate da file vengono distrutte e sostituite da altre create "proceduralmente" dal programma
4. Ulteriore modifica della mappa, a piacere
5. Ripristino delle dimensioni 64x64 delle caselle, sempre dal menu Impostazioni->Dimensiona caselle... Dal momento che esistono file per quelle dimensioni delle caselle, le immagini create "proceduralmente" dal programma vengono distrutte e sostituite da quelle caricate dai file
...tutto fila liscio. Anche monitorando col task manager quel che accade, si nota che non si accumulano leak dovuti a un uso improprio di GDI/GDI+, né più comuni leak di memoria.
La serie delle operazioni 2-5 qui sopra può essere ripetuta anche duecento volte, non cambia nulla.
Ora introduciamo un cambiamento che non dovrebbe cambiare nulla ma che manda in palla GDI/GDI+.
Ripetendo i passi precedenti, poi aggiungendo...
6. Apertura d'una mappa preregistrata (ce ne sono diverse nella cartella "Esempi salvati") di dimensioni adeguate al monitor; "simmetrica 1.dat" dovrebbe andare bene.
7. Cambio delle dimensioni delle caselle, dal menu Impostazioni->Dimensiona caselle... Non essendo disponibili file per caselle di dimensioni diverse da 64x64 pixel, le immagini precedentemente caricate da file vengono distrutte e sostituite da altre create "proceduralmente" dal programma
8. Ripristino delle dimensioni 64x64 delle caselle, sempre dal menu Impostazioni->Dimensiona caselle... Dal momento che esistono file per quelle dimensioni delle caselle, le immagini create "proceduralmente" dal programma DOVREBBERO essere distrutte e sostituite da quelle caricate dai file, ma per qualche ragione new Image(L"nome_file") in CaricaSprite() incorre in un OutOfMemory di GDI+ e ci si ritrova costretti a continuare a usare le immagini "procedurali" anche se sono disponibili quelle personalizzate da file
...GDI/GDI+ sembra andare in palla.
CHE STA SUCCEDENDO? Mi gratto la capoccia fino a bucarmela, ma non ne esco.
P.S. Lo stesso malfunzionamento si verifica anche se anziché caricare un file ci si limita a salvare quello sul quale si sta operando - il problema si presenta in seguito all'apertura della finestra di dialogo standard usata da GetOpenFileName() e da GetSaveFileName().
ATTENZIONE! Sono un hobbista e l'affidabilità delle mie conoscenze informatiche è molto limitata. Non prendere come esempio il codice che scrivo, perché non ho alcuna formazione accademica e rischieresti di apprendere pratiche controproducenti.
Al momento sarei già contento di riuscire a capire come mai si verifica il malfunzionamento che ho descritto (e che si può provare testando direttamente il programma). Risolto quello, sarò ben lieto di accettare i consigli più disparati, purché mi vengano rivolti in modo elementare perché la mia preparazione da autodidatta non mi permette "voli pindarici", e un consiglio che non si riesce a comprendere risulta ben poco utile. Apprezzerei di buon grado anche "spinte" più dirette, tipo esempi concreti di elaborazione del codice portate avanti "prendendomi per mano e aiutandomi ad attraversare la strada".
La mia intenzione è quella di mantenere il programma il più semplice possibile, rendendolo tutt'al più più efficace nell'unico compito che avevo in mente: creare file con mappe generiche che possano essere usate nello sviluppo di altri programmi/giochi. Il bello è che al momento non ho la benché minima idea di quali potrebbero essere quei programmi/giochi, né se vedranno mai la luce!
ATTENZIONE! Sono un hobbista e l'affidabilità delle mie conoscenze informatiche è molto limitata. Non prendere come esempio il codice che scrivo, perché non ho alcuna formazione accademica e rischieresti di apprendere pratiche controproducenti.
code::block mi da come errore con Cygwin
windres: C:\Users\Michele\DOWNLO~1\EDITOR~1.00-\EDITOR~1\risorse.rc|88|syntax error|
(errore sul file risorse.rc alla riga 88)
Code::block con mingw32 nessun errore/warming
Code Lite mi da errore:
mingw32-make.exe[1]: *** [Debug/risorse.rc.o] Error 1
Debug in visualStudio:
Eccezione non gestita in 0x77E09ABA (ntdll.dll) in Editor mappe.exe: 0xC0000374: Heap danneggiato (parametri: 0x77E458E8).
Usi il compilatore mingw incluso in code::block?
io cerco sempre di provare i programmi , per quanto possibile, su più compilatori quando ho malfunzionamenti.
Se hai modo cambia compilatore
Ultima modifica effettuata da Mikelius il 15/10/2017 alle 22:15
Ho compilato con il mio CodeBlock e non ho ricevuto nessun errore.
Compilato su Win XP. codeblock 12 con Mingw32
Riassumo invece il discorso di aldo.
Non sò te, ma a me funziona benissimo.
Ho testato tutti i tuoi passaggi senza avere alcun problema!
Ripeto, almeno da me, su Windows XP funziona tutto perfettamente senza alcun tipo di errore.
Ho aperto e salvato mappe, modificato la dimensione delle caselle, dimensione della mappa,
disegnato nuovamente, salvato ecc. ecc. Nessun problema riscontrato.
Ultima modifica effettuata da Thejuster il 16/10/2017 alle 8:52
Sì, uso mingw32 in Code::Blocks.
Ho controllato la riga 88 del file delle risorse e non ci trovo niente di strano.
Più che altro mi lascia perplessa la segnalazione di "heap danneggiato"... a senso, sembrerebbe qualcosa che ha a che fare con l'allocazione dinamica della memoria, però perché viene riferita a un .dll? Mi sa che non ci capisco molto.
@ Thejuster
Mmm... bella storia! I problemi li ho riscontrati in Windows 7. Ho anch'io un computer con XP (che uso per fare musica, non per giocare "al programmatore"). Da quel che dici potrebbe essere un qualche tipo di incompatibilità? Appena ho tempo faccio anch'io qualche prova su XP. Se tutto funziona anche da me devo andare a leggere un po' di paginate su MSDN, perché io uso come reference un vecchio file di help che risale a Windows 98 e magari da allora son cambiate delle cose delle quali sono all'oscuro. C'è di buono che ho un punto di partenza dal quale cercare: GetOpenFileName() e GetSaveFileName(). Secondo me l'inghippo è lì.
C'è anche da dire che su Windows 7 compilo in Code::Blocks "16.qualcosa", mentre su XP compilo io pure con Code::Blocks "12.qualcosa". So per certo che il compilatore incluso nei due IDE non è lo stesso. Magari anche questo fa la differenza.
Al di là del bug, come ti sembra il programma? Può servire una cosa del genere? L'hai trovato pratico da usare? Cambieresti qualcosa?
Edit @ Mikelius. Ripensandoci, una segnalazione di heap danneggiato potrebbe proprio essere alla base delle segnalazioni di OutOfMemory di Gdiplus, che magari tenta di allocare e non ci riesce. Anche questo è da tenere presente. Grazie per avermelo fatto notare. Potresti controllare se si verifica sempre o solo nelle condizioni d'errore che ho descritto in un commento precedente? Su che sistema fai "girare" il programma?
"Eccezione non gestita" fa venire in mente un'eccezione "lanciata" da qualche oggetto e non "catturata" da alcun catch, lasciando quindi pendenti situazioni potenzialmente deleterie. Se non erro, i programmi compilati con mingw32 hanno però un meccanismo che in fase di debug chiude il programma con un messaggio d'errore standard in console; mi chiedo come mai non ho mai ricevuto alcuna segnalazione di "eccezione non gestita" per quella via. Bei misteri, eh?
Ultima modifica effettuata da AldoBaldo il 16/10/2017 alle 12:24
ATTENZIONE! Sono un hobbista e l'affidabilità delle mie conoscenze informatiche è molto limitata. Non prendere come esempio il codice che scrivo, perché non ho alcuna formazione accademica e rischieresti di apprendere pratiche controproducenti.
Non conosco json e di xml so invero pochino (ma potrei studiare, non credo sia così difficile, specie in fase di esportazione). Al di là del tipo di codifica, però, proprio non riesco a immaginare in che modo potrebbe essere più utile un file di tipo testuale formattato che uno binario tanto lineare ed esplicito come quello che ho usato.Stavo addirittura pensando di eliminare l'identificativo "MappaLabirinto.0001" per scarnificare ancora di più il formato: leggi le dimensioni della matrice, poi leggi i dati e riempila riga per riga; punto. Potrebbe anche essere il caso di prendere in considerazione la questione little/big endian ma al momento, pur sapendo di cosa si tratta, non ne ho le competenze (Windows come scrive? big o little?).
Potrebbe trattarsi di ambiti nei quali un "intervento esterno" sarebbe gradito.
Sul rendere più "visivo" il programma, ci avevo pensato ipotizzando di usare come "segnaposizione" il numero d'ordine del byte attivo oltre a quelli "di movimento". Poi ho ragionato: "e se uno vuole attivare più di un byte? quanti accidenti di casi sono possibili? a quel punto cosa visualizzo? decine di milioni di icone diverse? una sovrapposizione di icone? un numero binario a 28 cifre?". Già, perché si potrebbe pensare che i 28 bit rappresentano dei numeri (quali? raggruppando i bit in che modo?), o che rappresentano condizioni di selezione "sì/no" (e se ho tre o quattro "sì" contemporaneamente attivi sulla stessa casella? quale icona visualizzo?). La casistica è troppo vasta, per cui al momento credo che l'approccio aridamente astratto "acceso/spento" sia il più adatto allo scopo, anche se accetterei d'essere smentito con qualche pensata che non mi ha neanche sfiorato l'anticamera del cervello.
Per i bit di movimento la situazione è diversa.
Al momento i bit usati per indicare il movimento sono solo 4, con un massimo di 16 possibilità di combinazione. Inoltre, l'approccio visivo permette di capire senza sforzarsi troppo cosa si sta facendo mentre quello solo numerico sarebbe estremamente confuso, quindi tracciare una grafica "descrittiva" ha senso.
Ammetto che avevo pensato alla possiblità di creare mappe più articolate, prevedendo anche i movimenti in diagonale (a quel punto servirebbero 8 bit, con un massimo di 256 possibilità - complesso, ma ancora gestibile in termini di visualizzazione d'un percorso). Magari si può farne un "to do" a lungo termine.
Un altro ampliamento potrebbe essere la visualizzazione un po' più esplicita degli spostamenti obbligatoriamente unidirezionali, tipo "da questa casella puoi andare a destra, ma dalla casella alla sua destra non puoi venire verso questa casella"; questo tipo di ampliamento richiederebbe una tonnellata di frame aggiuntivi nello sprite e un bel po' di verifiche condizionali/switch per scegliere quello giusto, però credo che sarei in grado di implementarlo.
Insomma, le idee non mancano e prima o poi qualcosa succederà. Per ora ho in mente quel maledetto bug. Grrr!
P.S. gli spostamenti unidirezionali possono già essere inseriti nella mappa, ma la loro rappresentazione grafica è attualmente ben poco chiara.
Ultima modifica effettuata da AldoBaldo il 16/10/2017 alle 14:02
ATTENZIONE! Sono un hobbista e l'affidabilità delle mie conoscenze informatiche è molto limitata. Non prendere come esempio il codice che scrivo, perché non ho alcuna formazione accademica e rischieresti di apprendere pratiche controproducenti.
| 
