[CICLO 2] Storia 2

[fek]

Originariamente inviato da VICIUS

Secondo me ci convine fare come ha gia detto cdimauro. Siamo tutti abituati a pensare con l'origine degli assi e "hot-spot" in alto a sinistra e cambiare ora soltanto perchè opengl usa un sistema diverso mi sembra assurdo visto che abbiamo la possibilità di continuare a dusare il nostro modificando il codice di due o tre classi.

ciao

Si'. Nella prossima Storia avremo un task per scrivere tutti i test necessari per fare questo cambiamento. La maggior parte di noi e' abituata cosi' e va bene.

Nota: il topic dei task non e' la sede opportuna per discutere scelte filosofiche di questo tipo. Per favore, apriamo un altro topic in caso acadesse di nuovo.

[fek]

Originariamente inviato da cdimauro

Questo costringerebbe i grafici a realizzare qualunque oggetto tenendo sempre presente le potenze di due. E' seccante.

Alla fine della fiera costringe solo a sprecare spazio in una texture per renderla potenza di due, e poi passare le coordinate all'interno della texture dove e' posizionato lo sprite.
Si tratta di aggiungere alcuni parametri a Sprite e lo faremo nella prossima Storia.

Meglio ancora utilizzando il sistema di riferimento "raster" che proponevo: la parte visibile 129x129 finirebbe nell'angolo in alto a sinistra della texture 256x256, e il resto non sarebbe comunque utilizzato né creerebbe problemi.

Questa e' una soluzione interessante da valutare.

[fek]

Originariamente inviato da Jocchan

OpenGL???
L'obiettivo è che il gioco venga eseguito praticamente OVUNQUE, non che venga eseguito e basta. Non dobbiamo considerare solo l'eventualità di un porting per cellulari, ma già partire dal presupposto che il codice DEVE essere il più possibile universale. E' una scelta di design anche questa, in fondo.
Sfruttare le OpenGL magari può aiutarci parecchio, ma non possiamo e non dobbiamo basare il codice su di esse, o addio portabilità.

Esatto. Le classi Sprite e Texture dovranno astrarre le OpenGL e disaccoppiare l'applicazione dai dettagli della libreria di presentazione. Noi decidiamo il nostro sistema di coordinate, l'Engine si occupa di "tradurre" dal nostro al sistema della libreria' di presentazione. La mappatura sara' sempre strettamente un texel per pixel con nessuno stretching (a meno di effetti particolari, ma questo e' un caso diverso).

Avremo un meeting per definire questi punti in sospeso:
- il nostro sistema di coordinate
- come organizzare gli sprite all'interno delle texture

[cionci]

Cerchiamo di non farsi prendere dalla 'foga' di scrivere codice... Il bello di questo metodo di progettazione sta proprio lì...scrivere solo le cose che sono necessarie a far passare i test...
Questo implica diverse cose:
1) i test vanno scritti prima
2) il codice da scrivere molte volte si limita a qualche riga
3) molto raramente dietro ad un task c'è una "rivoluzione", spesso ci si limita a fare un paio di refactoring ed a scrivere una classe o a modificarne una esistente. IMHO se dietro ad un task si nasconde una rivoluzione obbligata allora il task è stato scritto male (non mi riferisco a questo caso in particolare).
4) le classi che fanno troppe cose, fanno molte cose che non dovrebbero fare: parola chiave semplificazione

Questo è quello che ho imparato osservando (visto che in questi giorni non posso dare il mio contributo) l'operato e le correzioni apportate da fek...

Comunque la mia intenzione non è quella di fare una ramanzina a nessuno, ma è solo un tentativo di recuperare gli obiettivi originali che forse si sono un po' persi in questa Storia...

[fek]

Originariamente inviato da Vifani

Comunque secondo me è necessario definire dei paletti. Insomma stare a discutere al Ciclo 2 Storia 2 ancora se usare o meno OpenGL mi sembra ridicolo. Si fanno delle scelte all'inizio e le si mantiene a meno di gravissimi problemi imprevisti, ma questi che state citando non sono imprevisti: fek sicuramente sapeva di questo discorso delle texture ad esempio.

Infatti non c'e' alcuno spazio di discussione sull'usare OpenGL o meno. Si usa OpenGL.
Qualunque differenza fra OpenGL e l'"astrazione" che scegliamo per conto nostro sara' adattata dalle classi dell'Engine che nasconde i dettagli implementativi della libreria di rasterizzazione.

Ovviamente i grafici dovranno comunque sottostare a questi dettagli, ma e' un problema parzialmente inevitabile. Se fosse un peso troppo grosso, non ci costera' nulla prendere uno sprite 129x129 e caricarlo in una texture 256x256 programmaticamente, nascondendo anche questo dettaglio agli artisti. Vedremo se ci converra' in termini di tempo oppure gli artisti si possono adattare.

Questi problemi sono comunissimi e non vanno trasformati in occasioni di stress: c'e' un problema, si trova la soluzione piu' comoda per tutti. Qualcuno non sara' d'accordo con la soluzione scelta, amen, una decisione va presa comunque e poi si va avanti con quella.

[fek]

Originariamente inviato da cionci

Cerchiamo di non farsi prendere dalla 'foga' di scrivere codice... Il bello di questo metodo di progettazione sta proprio lì...scrivere solo le cose che sono necessarie a far passare i test...
Questo implica diverse cose:
1) i test vanno scritti prima
2) il codice da scrivere molte volte si limita a qualche riga
3) molto raramente dietro ad un task c'è una "rivoluzione", spesso ci si limita a fare un paio di refactoring ed a scrivere una classe o a modificarne una esistente. IMHO se dietro ad un task si nasconde una rivoluzione obbligata allora il task è stato scritto male (non mi riferisco a questo caso in particolare).
4) le classi che fanno troppe cose, fanno molte cose che non dovrebbero fare: parola chiave semplificazione

Questo è quello che ho imparato osservando (visto che in questi giorni non posso dare il mio contributo) l'operato e le correzioni apportate da fek...

Comunque la mia intenzione non è quella di fare una ramanzina a nessuno, ma è solo un tentativo di recuperare gli obiettivi originali che forse si sono un po' persi in questa Storia...

Stampate questo post e appendetelo al PC e imparatelo a memoria

Vi ricordo i nostri punti fermi:
- semplicita'
- qualita' del codice
- produttivita'

Aggiungo solo di abituarsi a non avere un attaccamento morboso al codice che scrivete: spesso e volentieri vedrete dei revert del codice che avete scritto. Non e' una punizione.
Stiamo portando avanti un progetto e l'unica cosa che conta e' portare il progetto avanti al meglio: se questo necessita' un revert di un pezzo di codice o del refactoring, lo faccio, chiunque lo abbia scritto, e qualunque reazione emotiva potrebbe causare all'autore. Mi interessa solo la qualita' del codice.

[cdimauro]

Originariamente inviato da fek

Alla fine della fiera costringe solo a sprecare spazio in una texture per renderla potenza di due, e poi passare le coordinate all'interno della texture dove e' posizionato lo sprite.
Si tratta di aggiungere alcuni parametri a Sprite e lo faremo nella prossima Storia.

Questa e' una soluzione interessante da valutare.

Me n'è venuta in mente un'altra, che potrebbe risolvere capra e cavoli, come si suol dire.

Ne parliamo al meeting.

P.S. Non era mia intenzione scatenare un putiferio. Se i miei messaggi sono sembrati "duri", me ne scuso. Non so qui per piantare casini, ma per imparare.

[71104]

Originariamente inviato da fek

No, sono certo che non lo fossero e non ci siamo proprio.

rinominare Gem in GridSprite e aggiungere Grid non faceva parte dei task 4.2 e 4.3, ma del 5.9 (non ricordo se era quello il numero): PlayArea si occupa di disegnare la griglia del giocatore, e Grid di gestirla.

Sto vedendo molti cambiamenti non dettati ne' da test ne' da necessita' di implementazione e la cosa non mi sta piacendo affatto.

non abbiamo avuto dei test su cui basarci per questa storia, abbiamo dovuto farli noi -_-'

[Vifani]

Originariamente inviato da cdimauro

Tanto per fare un altro esempio: a me non piace neppure l'uso dei float per le coordinate. Con dei giochi 2D gli int sono più che sufficienti. Al più i float si dovrebbero usare soltanto se strettamente necessario. Si potrebbero benissimo convertire gli int in float soltanto quando c'è da renderizzare le texture.

Non c'è alcun problema nell'uso degli interti. Invece di glVertex2f si usa glVertex2i ed il problema è risolto. Per chiamate come glTranslatef o glTexCoord che richiedono necessariamente i float, gli si fa il cast nella chiamata e amen.

Originariamente inviato da cdimauro

Per me è una questione di ottimizzazione. Se domani volessi convertire Diamonds per farlo funzionare su un telefonino con J2ME, e non c'è OpenGL ES, mi ritroverei:
- coi float, che appesantiscono molto l'esecuzione dei calcoli;
- con la conversione dal sistema di coordinate cartesiano a quello raster;
- con le immagini che occupano molto più spazio (visto che i grafici potrebbero essere costretti a rilasciare file aventi per dimensioni potenze di 2, anche quando l'area realmente utilizzata è decisamente inferiore).

Paradossalmente così penalizziamo molto le piattaforme con hardware poco potente, che sono costretti a fare molto più lavoro di quel che dovrebbero, mentre su hardware più potente (se ci sono le OpenGL, generalmente vuol dire che lo è) tutto ciò sarebbe indifferente.

Per chiudere il discorso (poi lo riapriamo quando ci sarà anche fek): l'uso delle OpenGL non dovrebbe porre vincoli al progetto, visto che si tratta soltanto di UNA soluzione a un problema che avevamo.

Per adesso chiudiamo questo ciclo e poi, comunque, è meglio riparlarne.

Mi dispiace ma tutte queste considerazioni sono delle gravissime mancanze di coerenza con quanto mi è stato detto da fek. Lui ha sempre parlato di uno sviluppo improntato alla definizione dei test e alla realizzazione delle soluzioni più semplici possibili, senza alcuna considerazione relativa alle prestazioni.

Inoltre, io non so se qualcuno ha definito i requisiti di questo progetto, ma ben prima del suo inizio è necessario definire la piattaforma target. Ora se i cellulari non sono stati definiti all'inizio, i cellulari non verranno supportati in questo sviluppo. La realizzazione dei task tenendo conto di quello che eventualmente forse potrebbe essere necessario per il corretto funzionamento del tutto sui cellulari non è una cosa che è stata detta o richiesta.

A quanto so io questo è nato come un progetto semplice e tale deve rimanere. Il discorso del supporto ai cellulari, se necessario, verrà affrontato in un altro progetto.

[cionci]

Originariamente inviato da Vifani

A quanto so io questo è nato come un progetto semplice e tale deve rimanere. Il discorso del supporto ai cellulari, se necessario, verrà affrontato in un altro progetto.

Concordo
Anche perchè il problema potrebbe essere affrontato in altri modi che non abbiamo considerato...visto che le istruzioni openGL da cambiare sarebbero veramente poche...

[fek]

Originariamente inviato da Vifani

A quanto so io questo è nato come un progetto semplice e tale deve rimanere. Il discorso del supporto ai cellulari, se necessario, verrà affrontato in un altro progetto.

Il supporto ai cellulari non e' un requisito di questo progetto e non deve inficiare il design.

[fek]

Questa Storia e' spostata al prossimo ciclo. Potete chiudere il topic?