Questo sito utilizza cookies solo per scopi di autenticazione sul sito e nient'altro. Nessuna informazione personale viene tracciata. Leggi l'informativa sui cookies.
Io uso per lo più Visual Stduio 2017 community, ma non ho compilato con esso.
Ho compilato in mode "relase" con code::block, con vari compilatori. Mingw compila, Cygwin no.
Ho solo windows 10 e kubuntu su cui provare i sorgenti.
Funziona finchè non tento di salvare. a quel punto si blocca il programma e quando tento il debug con visual studio... mi da quell errore.
P.s. comunque ho notato che il file lo salva. cioè se apporto dei cambiamenti alla mappa , li ritrovo.
Edit.. avendo 5 minuti ho provato a compilarlo su visual studio (sperando di aver fatto bene).
Trovo questo errore:
"più istanze di funzione in overload "Gdiplus :: Graphics :: DrawImage" corrispondenti all'elenco di argomenti: Mapping FILE: dlg_bits.cpp RIGA: 175
In più ci sono diverse segnalazioni per conversioni errate
Tipo nel main
Ti direi semplicemente di utilizzare i file come li hai appena strutturati.
Ovvero in binario, per non avere tante rotture nel programma durante il salvataggio
o l'apertura di una mappa.
Esportare in JSON o XML ti apre tantissime porte.
Un esempio, è poter utilizzare le tue mappe su un'applicazione android o ios tanto per dirne una.
Oppure per giochi in HTML5, e molto altro ancora.
Il file binario conviene tenerlo così come sta, esclusivamente per il salvataggio e lettura della mappa
dell'editor.
Riguardo alle icone, o al tipo di sprite, normalmente io uso dei flag.
niente byte o quant'altro. Al massimo, uso identificatori.
Ogni file ha il suo tot di sprite disposti in griglia o allineati.
1 potrebbe essere curva a destra
2 potrebbe essere curva a sinistra
3 il giocatore, etc.
normalmente una mappa viene salvata in byte si, ma con una sequenza ben precisa.
un esempio:
Codice sorgente - presumibilmente Plain Text
risorsa = Immagine.png
mappa =
{1,2,2,2,2,2,2,1,
3,0,0,0,0,0,0,3,
3,0,0,0,0,0,0,3,
3,0,0,0,0,0,0,3,
4,2,2,2,2,2,2,4 }
gli id vengono dati suddividendo in griglia tutti gli sprite.
ed ovviamente sai che a quell'id corrisponde un certo sprite.
Questo è il metodo che utilizzano tutti gli sviluppatori indie di giochi.
La endiannes è una specifica della CPU, non del sistema operativo.
Intel core sono little endian, AMD athlon big endian se ben ricordo.
Visto che ormai mi sono intromesso nella conversazione dico la mia dose di idiozie:
1) a te piace C, quindi immagino il sorgente sarà del testo lunghissimo con le tue convenzioni, se io volessi leggerlo hai scritto della documentazione? L'idea generale del sorgente? Documentazione di ogni funzione per doxygen?
2) perché GDI? Non era meglio qualcosa di più cross-platform? So che al giorno d'oggi con wine e macchine virtuali non è un vero problema, ma magari usare qualcosa di diverso poteva essere una esperienza migliore anche per chi vuole studiare il sorgente e non conosce le winapi.
3) io ti consiglio di guardare json, è un formato di serializzazione semplicissimo, anche più di xml. Scherzo, molto di più!
In effetti DrawImage() viene chiamato due volte di fila in due versioni diverse, ma non credo sia un problema. Qualcuno mi corregga se sbaglio.
Per quel che ho rilevato, il bug che mi assilla deriva dall'interazione le finestre di navigazione standard e il caricamento di un'immagine da file, non da DrawImage().
Sulle conversioni di tipo... credo che il mio codice faccia affidamento sulle conversioni automatiche in parecchie altre occasioni oltre a quella che rilevi nel main(). Il cast esplicito lo uso, ma non in TUTTE le situazioni! Molte volte quelle automatiche sono ragionevolmente affidabili. Nel caso che mi segnali, ad esempio, GetSystemMetrics() non credo che restituisca mai un valore negativo nel notificare le dimensioni dello schermo, e l'arrotondamento a intero che deriva dalla conversione automatica da float è opportuno nel caso specifico, perché è sempre un arrotondamento per difetto che riduce un poco le dimensioni della finestra (il che non è un problema, mentre potrebbe essere un problema aumentarle).
@ TheDarkJuster
1. nessuna documentazione che rispetti forme standard, solo commenti "a mano libera" in testa ad ogni funzione
2. GDI e non altro perché... ho imparato quello (più o meno) e non altro! 3. sarà fatto; non sei il primo a citarlo e a questo punto mi avete incuriosito
Ora stacco un momento e vado a provare il programma su XP, che ancora le parole di Thejuster mi frullano per la testa e devo togliermi il tarlo.
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.
Ho trovato l'errore! Ipotizzando che possa interessarvi, cerco di descrivere cosa stava succedendo.
GetSaveFileName() e GetOpenFileName() prevedono un membro della struttura OPEFILENAME che si chiama Flags. In quel membro si possono impostare diverse costanti che controllano alcuni aspetti del comportamento delle funzioni. Tra le tante costanti disponibili una è OFN_NOCHANGEDIR, che fa in modo che alla chiusura della finestra di dialogo venga ripristinata (se è stata cambiata durante la navigazione) la directory corrente iniziale. In precedenza, non avevo impostato quella costante in Flags, per cui caricando un file da una cartella che non fosse quella dove si trova l'eseguibile, la directory corrente veniva modificata sia da GetSaveFileName() sia da GetOpenFileName().
Siccome la mia CaricaSprite() carica i suoi file passando come percorso il semplice L"img/nomefile.png", il sistema aggiunge in automatico il percorso della directory corrente in testa a suddetto percorso. Se la directory corrente è quella iniziale si tratta della stessa directory che contiene l'eseguibile *E* la cartella "img/", ma se la directory corrente NON è più quella iniziale, il file viene cercato in un altro luogo (e non trovato) e la funzione creatrice di Image fallisce. La cosa "divertente" è che lo squadrone degli ingegneri ed espertoni di Microsoft non ha trovato soluzione migliore di far impostare come codice di errore lo Status OutOfMemory anziché quello (pur disponibile) FileNotFound. Volponi! Se una cavolata del genere l'avessi fatta io che sono un hobbista autodidatta pasticcione, va be', ma stiamo parlando di una squadra di teste d'uovo incaricate di occuparsi del sistema operativo oggettivamente più diffuso. Forte, eh?
Be', permettetemi d'essere orgoglioso d'essere uscito dal "labirinto" solo con le mie gambe e la mia testolina di cinquantenne "programmatore" della mutua. A volte la semplice determinazione dovuta all'entusiasmo per una certa cose può fare miracoli.
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.
Ciao AldoBaldo, vedo che sei esperto e forse questo mio consiglio per te è un po' come la scoperta dell'acqa calda.
Ritengo che è buona regola imporsi di aggiungere sempre ai programmi in sviluppo una "Private Sub MioDebug (byVal messaggio as string)" che accoda in un file testo, salvato nella cartella del programma, l'ora+messaggio.
questa routine va richiamata tutte le volte che il programma esegue operazioni cruciali, tipo salvataggio e caricamento file, concatenazioni di stringhe che generano indirizzi e percorsi, termine di una subroutine, confronti di valori che cambiano il flusso del programma ecc ecc.
Nel tuo caso se avevi inserito dopo i salvataggi e caricamenti: MioDebug("salvo il file in: " & percorsofile).
Avresti intercettato il problema.
Pensa che tale imposizione ti permette di monitorare il flusso del programma anche quando sei fuori l'ambiente di sviluppo.
Inoltre, non è il tuo caso, se si realizza un programma che lavora continuativamente, permette di individuare quei problemi che potrebbero saltare fuori dopo qualche tempo.
Scusa gli esempi Basic like, ma non sono da C++
Ultima modifica effettuata da Carlo il 24/03/2018 alle 6:00
