Re: [Dlab-devel] Idee

[Bernardo I. <be...@de...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 27 May 2002 18:23, Mattix wrote:

 > Pensavo a una cosa...
 > Ditemi se conviene: perche non mettiamo tutti i #define in un file .h
 >  (ad esempio defines.h) in modo da averli tutti sott'okkio?
 > Chiaramente dovranno essere commentate accanto le loro funzioni.
 > Questo ci farà risparmiare un po' di spazio perchè sarà sufficente 
 > scrivere "#include defines.h" in ogni file che abbia bisogno dei 
 > #define.
 > Inoltre penso che sia molto più comodo anche perchè per settare le 
 > OPZIONI sarà sufficente andare a frugare in quel file invece di dare 
 > ogni volta una directory diversa.

 Si', e' un'ottima idea, ma non _TUTTE_ le definizioni. Direi di
identificare quelle definizioni che riguardano tipicamente la
configurazione del gioco (numero vite, velocita' spari, etc.) e
metterle magari in un include "config.h".

 Cosi' un eventuale playtester o utente finale puo' customizzare il
gioco secondo le proprie esigenze, pur non essendo un programmatore.

 Se ti va di farlo, non esitare!


 > Per quanto riguarda il mio personale lavoro volevo ringraziare chi ha
 > ulteriormente incasinato le cose cambiando i nomi dei bonus senza
 > rimettere i loro nomi nei files da compilare. Il quadratino rosso che
 > appare è una "cosa di sicurezza" che abbiamo inserito su idea di
 > bernardo per evitare che tutto crashi. In pratica quella dovrebbe
 > apparire quando l'oggetto bonus richiamato non è trovato.

 Si, infatti... il quadratino rosso fa capire che manca un'immagine...
Credo che ad aver rinominato le immagini sia stato mostro, ma vedo che
adesso il codice non torna neanche con i nomi, chi e' stato?

 > E pensare che avevo appena scritto a proposito del LASCIARE LE COSE A
 >  META'... VEDIAMO DI PROVVEDERE

 Approposito: le armi erano una cosa a meta' ma ora ci sta lavorando
qualcuno (chi? non ricordo...)


 > C'era anche il problema che quando il player prende un bonus dovrebbe
 >  succedere qualcosa: allora tutto quello che succedeva era che
 > venivano assegnati dei punti (cosa che ho tolto perchè non è quella la
 > funzione dei bonus) e nient'altro.

 A fare questo e' stato fede ;-)

 > C'era solo uno strano effetto collaterale che un bonus errato faceva 
 > cambiare tipo di sparo...

 Si ho visto... adesso e' a posto'?


 > Il bonus della vita invece non implementa la vita (e non è solo un 
 > discorso di SUPER-TEXT) e io non sono riuscito ancora a trovare dove
 > va  fatta la modifica perchè come ho già detto è tutto
 > incasinatissimo. Ora, io non sono abbastanza bravo per rimettere tutto
 > a posto come avevo proposto (ovvero ordinare tutte le collisioni per
 > argomenti in un unico file ad esempio, e non un pezzo quì, un pezzo là
 > delle stesse cose) e quindi vorrei sollecitare qualcuno che ci capisce
 > a fare questa cosa, altrimenti si rischia, come ha detto anche
 > bernardo, di arrivare a un punto in cui si fa prima a riscrivere tutto
 > che a riordinare i files.

 Un momento, sto guardando come sono fatte le collisioni e non mi
sembrano malissimo. I criteri sono:

 - nessun oggetto deve permettersi di alterare le variabili di
   un altro oggetto quando collide (ognuno pensa per se)

 - nella collide() non si puo':
    - cambiare la propria posizione
    - cambiare la propria velocita'
    - suicidarsi

 La seconda regola serve perche' la collide() viene chiamata sempre
su due diversi oggetti, ma non e' specificato in che ordine. Ogni
oggetto deve avere l'opportunita' di vedere posizione e velocita'
dell'altro.

 Per onorare questa regola, molti oggetti si salvano delle variabili
e cambiano stato al momento della collide() e poi fanno quello che
devono fare nella move().

 Una soluzione piu' semplice poteva essere di salvare velocita', tipo
e posizione di ciascun oggetto nella CollisionDetection() e poi passare
solo questi valori alla collide() di ognuno. Tra l'altro questo
design avrebbe garantito anche il rispetto della prima condizione!

 Pero' a pensarci bene, quasi sempre un oggetto ha bisogno di cambiare
stato e gestire la collisione nella move() perche' alcuni azioni durano
un certo tempo...


 > Se non ci avete fatto ancora caso, adesso non si compila più come un 
 > tempo: non si sa come ma adesso ci sono dei problemi con la libreria 
 >  time.h che prima non c'erano... che è successo? Qualcuno ha fatto
 > casino?

 Ah, si'... e' davvero un baco nell'include time.h del GCC 2.95.3.
Le due soluzioni sono:

 - aggiornarsi al gcc 3.1 (meglio)

 - commentare il prototipo doppio di time() in time.h (zozzo!)

- ----------------------------------------------------------------------
Try our multiplatform arcade classic: http://www.sf.net/projects/dlab/
- ----------------------------------------------------------------------

  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE88+7ZltU4TfxqZsoRAnvNAJ4oyDix7zs4Gii24GToJZ7ZyO3dmACfcVTZ
on4jUHaZv2NgzdJvYXYYXyE=
=PaDy
-----END PGP SIGNATURE-----