View Full Version : [CICLO 2] Storia 2
Ecco la seconda storia del secondo ciclo...
Storia:
Introduzione di una griglia (14 righe per 8 colonne) di caselle da 32x32 pixel ciascuna, che andrà a coincidere con l'area di gioco. I movimenti del diamante alla pressione dei tasti direzionali devono avvenire lungo la griglia (nelle direzioni permesse e senza dimenticare i bordi). La velocità di spostamento del diamante all'interno della griglia deve essere pari a circa l'80% di quella attuale (lo spostamento laterale da una casella all'altra deve essere pressocchè istantaneo, quello verticale più lento e fluido).
Riservato per la divisione in task.
Ecco i nuovi task. In accordo con Jocchan abbiamo aggiunto qualcosa in piu a quello che doveva essere la storia. In ogni caso ho il presentimento che finiremo presto anche questa, visto che sembrate un branco di lupi famelici alla ricerca di task da completare.
Task:
4.1 creare una texture 32x32 da usare come sfondo per le celle dell'area di gioco (Jocchan: completato)
4.2 disegnare le celle all'interno dell'area di gioco rappresentata da extents
(8 colonne x 12 righe = 112 celle) (71104: 1 giorno)
4.3 creare una nuova area di gioco per il secondo gicoatore e disegnare le celle anche li (71104: 1 giorno)
4.4 modificare lo spostamento laterale delle gemme. Alla pressione dei tasti destra e
sinistra lo spostamento nella colonna accanto deve essere istantaneo (Vifani: 2 giorni)
4.5 creare una texture 800x600 contenendo il fondale da usare per la finestra (Jocchan: completato)
4.6 disegnare il fondale del task 4.5 sotto alle aree di gioco (71104: 1 giorno)
5.7 creare un logo semitrasparente da mostrare sopra al fondale (Jocchan: completato)
5.8 disegnare il logo del task 5.7 in basso tra le due aree di gioco (cdimauro: 1 giorno)
5.9 spezzare la classe playarea in due o piu classi. (71104: x giorni)
5.10 auditing del codice e delle classi Test. Aggiungere test per il codice non testato. eliminare test non piu neccesari e modifcare quelli vecchi. (Tutti: 4 giorni)
I test me li invento domani mattina... se ne trovo. Ora non ho voglia :p
ciao ;)
mi prenoto per il 4.2 e 4.3, penso di farli in 1 giorno ciascuno, totale 2 giorni :)
Un piccolo avviso per quelli che devono fare un task che ha a che fare con una texture. Sul server per ora ci sono delle false texture che potete usare. cell.png, background.png, logo.png. Quando saranno finiti i task poi inseriro quelle che mi ha mandato Jocchan oggi pomeriggio :D
ciao ;)
I test me li invento domani mattina... se ne trovo. Ora non ho voglia :p ah ecco, mi pareva che non ci fossero... :mbe:
be', a sto punto me li invento io...
Task 4.4 prenotato. Un paio di giorni per la realizzazione.
completati :|
erano più semplici di quanto pensassi :p
ho fatto un paio di tests ma non è che potessi fare un granché perché la classe che ho aggiunto (PlayArea) è molto semplice: ha solo due metodi e deve solo disegnare...
mi prenoto per il 4.6 se non vi spiace :p
mi prenoto per il 4.6 se non vi spiace :p
Ma la notte dormire no? :D
Ma la notte dormire no? :D e tu? :D
cmq l'avrei fatto domani il 4.6 :D
Attenzione, c'è un piccolo errore nei task: le righe sono 14, non 12!
cdimauro
11-10-2005, 09:05
Mi prenoto per il task 5.8. Tempo previsto: 1 giorno.
mamma mia che cannibali.........a quando il ciclo3 ? :stordita: :p
Non mi torna una cosa... IMHO non è giusto fare un numero orizzontale di celle pari... In questo modo il diamante non comincerebbe a cadere da posizione centrale, ma bisognerebbe cominciare a farlo cadere dalla posizione 4 o 5...
Non mi torna una cosa... IMHO non è giusto fare un numero orizzontale di celle pari... In questo modo il diamante non comincerebbe a cadere da posizione centrale, ma bisognerebbe cominciare a farlo cadere dalla posizione 4 o 5...
daccordissimo... se deve passare da una cella all'altra in modo istantaneo nn può neanche partire da una posizione a metà di una e metà di un'altra :confused:
hola
valse
Attenzione, c'è un piccolo errore nei task: le righe sono 14, non 12!
Giusto. Errore mio :muro:
ciao ;)
Fermi tutti.
Prima di iniziare con la Storia 2, c'e' parecchio refactoring e testing da fare.
PlayArea ad esempio. E' una classe con due responsabilita':
1) Disegna la griglia
2) Gestisce la griglia di celle
C'e' solo un test. Qui c'e' chiaramente un problema che deve essere risolto prima di continuare. Andare avanti con una classe cosi' importante sostanzialmente non testata e che ha due responsabilita', e' una ricetta sicura per il disastro.
Questa classe non e' stata scritta Test First e si vede lontano un chilometro. Male. Sforzatevi di scrivere test first come abbiamo fatto io e Vicius in quel topic, perche' il risultato del non farlo e' una classe come questa non testata e pronta per creare problemi.
Bisogna intervenire subito. Scrivo un po' di test per questa classe oggi e poi aggiungiamo un task per implementarli prima di proseguire con lo sviluppo.
L'idea e' che prima di iniziare ad aggiungere nuove funzionalita' il codice dev'essere il piu' possibile minimale e ben fattorizzato.
Ed infine: Un task non e' concluso fino a che non ci sono i test relativi.
PlayArea non ha test, quindi il suo task non e' concluso. E non si passa ad una storia nuova se tutti i task non sono conclusi.
mi prenoto per il 4.2 e 4.3, penso di farli in 1 giorno ciascuno, totale 2 giorni :)
Preferisco che tu li faccia in 4 giorni ma mi scriva i test. Non e' una gara a chi va piu' veloce qui.
Se risparmi un giorno qui non scrivendo i test, poi perdiamo una settimana magari dopo, perche' stiamo accumulando dei debiti che dovremo pagare in seguito.
Quello che ci interessa non e' avere una velocita' di punta alta, ma una velocita' media costante e mediamente alta senza picchi o pozzi.
Voglio i test, e ne voglio tanti e possibilmente scritti prima :)
Altro esempio, classe Extents:
8 metodi pubblici, 3 test. C'e' chiaramente qualcosa che non va.
Ed infine:
public float clipX(float pos, float offset)
{
float posizione = pos;
if(posizione < left + offset)
{
posizione = left + offset;
}
if(posizione > right - offset)
{
posizione = right - offset;
}
return posizione;
}
Il prossimo che scrive il nome di una variabile in italiano lo mangio vivo :)
Grazie al cielo c'è fek :help:
Dunque. Che dici aggiungo questi due task:
5.9 spezzare la classe playarea in due o piu classi. (71104: x giorni)
5.10 auditing del codice e delle classi Test. Aggiungere test per il codice non testato. eliminare test non piu neccesari e modifcare quelli vecchi. (Tutti: 4 giorni)
ciao ;)
Perfetto :)
Se qualcuno ha problemi con lo scrivere i test per iniziare questi taskj, i primi li scriviamo noi.
Un'altra cosa. Ho visto che la build e' stata rotta per questi giorni, perche' checkstyle non passava.
Prima di ogni commit, lanciate la build di Ant esterna a Eclipse.
Non c'e' eccezione alla regola.
71104: hai fatto più danni della grandine :asd:
[checkstyle] E:\Java\diamonds\trunk\src\it\diamonds\PlayArea.java:14:5: Each var
iable declaration must be in its own statement.
[checkstyle] E:\Java\diamonds\trunk\src\it\diamonds\PlayArea.java:17:5: Each var
iable declaration must be in its own statement.
71104: hai fatto più danni della grandine :asd:
[...]
:rotfl:
Su dai 71104 metti a posto il codice.
ciao ;)
PlayArea ad esempio. E' una classe con due responsabilita':
1) Disegna la griglia
2) Gestisce la griglia di celle veramente per ora non gestisce nulla, la disegna soltanto...
C'e' solo un test. Qui c'e' chiaramente un problema che deve essere risolto prima di continuare. Andare avanti con una classe cosi' importante sostanzialmente non testata e che ha due responsabilita', e' una ricetta sicura per il disastro. un altro mi era venuto in mente ma non so come realizzarlo: avevo pensato di fare un test in cui la cella di PlayArea veniva creata con degli Extents (che ora vorrei capire perché si chiamano Bounds... :confused: ) e controllare che nessuna cella subisse clipping durante il disegno...
71104: hai fatto più danni della grandine :asd:
[checkstyle] E:\Java\diamonds\trunk\src\it\diamonds\PlayArea.java:14:5: Each var
iable declaration must be in its own statement.
[checkstyle] E:\Java\diamonds\trunk\src\it\diamonds\PlayArea.java:17:5: Each var
iable declaration must be in its own statement. è arrivato... -_-'
solo due issues, poteva andare peggio, pensa se avessi programmato col mio solito stile... e poi almeno il mio codice funziona :Prrr:
edit: ed è anche scritto completamente in inglese :Prrr:
5.9 spezzare la classe playarea in due o piu classi. (71104: x giorni) più che altro direi aggiungere una classe per gestire la griglia...
effettivamente PlayArea per il momento disegna solo una griglia di celle, e non gestisce la griglia stessa, penso che l'unica cosa da fare sia dargli un nome più significativo, e aggiungere un'altra classe per la gestione della griglia
e poi almeno il mio codice funziona :Prrr:
Perchè...il mio no ? :mbe:
aa, inoltre sono d'accordo con cionci quando dice che il numero di colonne dovrebbe essere dispari
effettivamente PlayArea per il momento disegna solo una griglia di celle, e non gestisce la griglia stessa, penso che l'unica cosa da fare sia dargli un nome più significativo, e aggiungere un'altra classe per la gestione della griglia ho aggiunto una classe Grid da me, però non so che devo fargli fare per ora: ci ho messo solo un Vector contenente degli Sprite e fa tutto lui...
ora metto un'istanza di Grid in PlayArea.
Perchè...il mio no ? :mbe: non so se il tuo funziona o no, ma non so chi sia stato a fare macello con le coordinate; c'è poca comunicazione tra di voi, ognuno sapeva il sistema di coordinate in modo diverso e il programma funzionava per miracolo (anzi, per caso); usatelo spesso il thread della knowledge (lo userò anch'io).
http://www.hwupgrade.it/forum/showpost.php?p=9790349&postcount=25 :p
solo due issues, poteva andare peggio, pensa se avessi programmato col mio solito stile... e poi almeno il mio codice funziona :Prrr:
Qual e' il test automatico che mi assicura che funzioni?
Senza test, io assumo che un metodo non funzioni ed il task relativo non sia concluso.
ho aggiunto una classe Grid da me, però non so che devo fargli fare per ora: ci ho messo solo un Vector contenente degli Sprite e fa tutto lui...
ora metto un'istanza di Grid in PlayArea.
In base a che cosa hai scritto del codice in una classe che non sai che devi fargli fare e soprattutto non hai i test che ti dicono che cosa fargli fare.
E' fondamentale che scriviate i test prima di scrivere il codice di produzione. Non voglio dover arrivare a imporvelo con le cattive (non accettando i commit), preferisco affidarmi al vostro buon senso. Se non avete chiaro come scrivere i test prima, iniziate con un task semplice e domandate. Ma non scrivete codice tanto per scrivere qualcosa, senza i relativi test.
non so se il tuo funziona o no, ma non so chi sia stato a fare macello con le coordinate; c'è poca comunicazione tra di voi, ognuno sapeva il sistema di coordinate in modo diverso e il programma funzionava per miracolo (anzi, per caso); usatelo spesso il thread della knowledge (lo userò anch'io).
Se la colpa e' di qualcuno, e' mia. Non voglio piu' vedere post di questo tipo.
Qual e' il test automatico che mi assicura che funzioni?
Senza test, io assumo che un metodo non funzioni ed il task relativo non sia concluso. infatti io parlavo di Extents e di tutte le correzioni che ho fatto durante la Storia 1
Il motivo per cui il numero di colonne deve essere pari l'ho spiegato nel topic sul design ;)
Si può anche inserire un numero dispari, ma questo aumenta la difficoltà del gioco, dato che sono necessari parecchi incastri per far quadrare tutto. Facendo un bilancio, è sicuramente sconveniente.
PlayArea.java R.I.P.
Una vita breve ma intensa.
A presto i test della Storia 2, quando Vicius e' contento del refactoring e della copertura dei test. C'e' da testare la classe Bounds (ex Extents).
ehm, :confused: scusate ma io stavo facendo il task 5.9 assegnatomi...
almeno avvisare per evitare di farmi lavorare inutilmente...
ora che devo fare? :confused:
ehm, :confused: scusate ma io stavo facendo il task 5.9 assegnatomi...
almeno avvisare per evitare di farmi lavorare inutilmente...
ora che devo fare? :confused:
Non hai lavorato inutilmente, hai fatto uno spike. Ma nella code base non ci dev'essere codice non testato per alcun motivo.
Aspettiamo i test e poi possiamo passare all'implementazione.
Nel frattempo e' un'ottima occasione per cercare opportunita' di refactoring nel codice e per aggiungere qualche test in zone deboli.
^TiGeRShArK^
11-10-2005, 17:15
Se la colpa e' di qualcuno, e' mia. Non voglio piu' vedere post di questo tipo.
Ti kiami Chet di secondo nome??? :mbe:
:sofico:
cmq io avrei voluto scrivere qualke test..
nei miei task ho solo dovuto modificare del codice già esistente ed ELIMINARE dei test ke testavano assunzioni non più vere.....:cry:
Dunque sto navigando il codice con clover e ho trovato un bel po di metodi non testati. Questa sera dovrei riuscire a scrivere quelli che mancano.
Come ultima cosa avrei una proposta da fare. Perchè non eliminare tutte queste eccezioni ? Possibile che ogni votla che si accede ad una proprieta, si carica un suono o una texture ci sia da fare una try/catch ? Tutto quello che facciamo ora è intercettare l'eccezione e terminare il programma. A questo punto ci conviene terminare il programma invece di generare l'eccezione.
In locale le ho rimosse tutte e il codice ne guadagna in quanto a leggibilità. e di molto.
ciao ;)
veramente io le eccezioni le trovo comodissime perché imho non ti devi neanche preoccupare di catturarle: se qualcosa va storto e non la catturi il programma si ferma e puoi vedere di preciso dov'è stata lanciata l'eccezione :p
molto più comodo che tutti quei valori di ritorno, anche perché Eclipse ti mette automaticamente il throws nei metodi :p
veramente io le eccezioni le trovo comodissime perché imho non ti devi neanche preoccupare di catturarle: se qualcosa va storto e non la catturi il programma si ferma e puoi vedere di preciso dov'è stata lanciata l'eccezione :p
molto più comodo che tutti quei valori di ritorno, anche perché Eclipse ti mette automaticamente il throws nei metodi :p
Certo sono utili ma usarle per tutto mi sembra stupido. Se c'è una eccezione va gestita in modo sensato non con un catch vuoto o un throws come stiamo facendo noi ora.
Se guardi per ora dentro ai catch ci sono solo queste cose:
Utils.fatalError(..);
assertTrue(false);
fail(...);
A questo punto Eliminiamo le eccezioni e spostiamo il fatalError dentro alle classi che generano le eccezioni.
ciao ;)
In locale le ho rimosse tutte e il codice ne guadagna in quanto a leggibilità. e di molto.
ciao ;)
Io direi di lasciare le sole eccezioni che segnalano un comportamento "eccezionale" (file non trovato, ad esempio) e non un semplice errore di programmazione.
E far fuori tutto il resto.
ma guarda che in java ci sono le eccezioni fatte proprio per segnalare gli errori di programmazione (eccezioni unchecked), ereditano da RuntimeException e non devono essere catturate per forza (tipo IllegalArgumentException è un'eccezione unchecked), quindi quando c'è da segnalare valori anomali di paramentri (quindi dovuti ad errori di programmazione) sono utlissime e non aggiungono nessun fastidio eccessivo, al contrario, quando manca la texture da caricare, per esempio, mi sembrano abbastanza utili ed eleganti...
Io direi di lasciare le sole eccezioni che segnalano un comportamento "eccezionale" (file non trovato, ad esempio) e non un semplice errore di programmazione.
E far fuori tutto il resto.
uhm non sono d'accordo. preferisco usare fatalError per stampare un messaggio significativo come "errore: non riesco a caricare la texture `data/diamond.png' quindi esco" che lanciare una eccezione per poi ritrovarmi un inutile e.printStackTrace(); system.exit(-1); o peggio ancora un throws che lascia arrivare il tutto alla jvm.
ciao ;)
ma guarda che in java ci sono le eccezioni fatte proprio per segnalare gli errori di programmazione (eccezioni unchecked), ereditano da Ru[...]
Uhm interessante questa storia delle unchecke exception. Spiega un po' :D
ciao ;)
per quanto riguarda il discorso di eliminare le eccezioni e mettere delle semplici chiamate a Util.fatalError non sono d'accordo, già il fatto che nel corpo del programma catturi l'eccezione e lanci fatalError mentre nei test lanci fail per esempio è un motivo per mantenere le cose come stanno, inoltre lasciano la libertà di gestire diversamente gli errori in diversi posti del programma...
per le eccezioni unchecked, questo è un pezzo di codice preso dal costruttore di Bounds:
if(!rectIsInsideTheScreen(left, top, width, height, config))
{
throw new IllegalArgumentException();
}
l'eccezione lanciata è un'eccezione unchecked, infatti non c'è nessun throws nell'intestazione del metodo, e quando costruisci Bounds non devi necessariamente usare un try..catch, anche se volendo si può anche aggiungere, in genere questo tipo di eccezioni vengono usate per segnalare errori di programmazione, ovvero casi che normalmente non dovrebbero verificarsi ma che è bene segnalare correttamente nel caso si verifichino anche per non avere sorprese in seguito...
per quanto riguarda il discorso di eliminare le eccezioni e mettere delle semplici chiamate a Util.fatalError non sono d'accordo, già il fatto che nel corpo del programma catturi l'eccezione e lanci fatalError mentre nei test lanci fail per esempio è un motivo per mantenere le cose come stanno, inoltre lasciano la libertà di gestire diversamente gli errori in diversi posti del programma...
Questo discorso mi sta bene.
L'importante e' che qualunque cosa si decida, in caso di errore il gioco si inchiodi e l'origine del problema sia chiara e ben documentata.
Per i dettagli implementativi del linguaggio, decidete pure voi, la cosa piu' semplice e elegante va bene.
[...]ammazione, ovvero casi che normalmente non dovrebbero verificarsi ma che è bene segnalare correttamente nel caso si verifichino anche per non avere sorprese in seguito...
Perfetto! È proprio quello che mi serviva.
ciao ;)
adesso all'improvviso ti piacciono di nuovo :p
adesso all'improvviso ti piacciono di nuovo :p
Se devo fare try/catch ovunque preferisco non usarle. Ora pero che le ho convertitein delle RuntimeException posso usarle come voglio io quindi mi piaciono :D
Giusto per passare il tempo con un po di statistiche. Per ora abbiamo un code coverage pari al 92,1% con i test. Se riesco a capire come esportare tutto su un report ve lo pubblico da qualche parte :)
ciao ;)
scusami, ma convertire tutte le eccezioni in runtime exception non mi sembra una soluzione elegante, è come dire che se non c'è la texture da visualizzare te ne freghi!! a parte il fatto che il try...catch non mi sembra introdurre tutta quella difficoltà di lettura del codice di cui parli, a me sembra ovvio che in certi casi (tipo mancanza della texture) devi catturare l'errore e gestirlo, tu dicevi di aggiungere direttamente nel codice dove viene lanciata l'eccezione un Util.fatalError, perchè il gioco deve terminare quando manca la texture, ma ciò IMHO toglie flessibilità nella gestione degli errori, perchè non utilizzare al meglio gli strumenti offerti dal linguaggio?
C'è un errore nel file del progetto:
Unbound classpath variable: 'CLOVER_RUNTIME' in project Diamonds
scusami, ma convertire tutte le eccezioni in runtime exception non mi sembra una soluzione elegante, è come dire che se non c'è la texture da visualizzare te ne freghi!! a parte il fatto che il try...catch non mi sembra introdurre tutta quella difficoltà di lettura del codice di cui parli, a me sembra ovvio che in certi casi (tipo mancanza della texture) devi catturare l'errore e gestirlo, tu dicevi di aggiungere direttamente nel codice dove viene lanciata l'eccezione un Util.fatalError, perchè il gioco deve terminare quando manca la texture, ma ciò IMHO toglie flessibilità nella gestione degli errori, perchè non utilizzare al meglio gli strumenti offerti dal linguaggio?
Non sono d'accordo. Per ora questa mi sembra la piu flessibile. Ci permette di scrivere codice senza dover scrivere le try/catch quando non ci servono (il 99% delle volte). Ad esempio è possibile accedere a config senza fare assurdi controlli oppure caricare una texture senza gestire ogni volta TextureNotFoundException. Se vogliamo gestirle in un punto particolare possiamo ancora farlo inserendo appunto try/catch. Se non vengono gestite arivano alla jvm che termina il programma stampando il messaggio.
ciao ;)
C'è un errore nel file del progetto:
Unbound classpath variable: 'CLOVER_RUNTIME' in project Diamonds
Colpa mia. Clover si deve essere infiltrato durante un commit :p
ciao ;)
La corpertura dei test ora è piuttosto buona quindi potete divertirvi a fare commit di tutti i task che volete.
ciao ;)
ma i test dei nuovi task...? :wtf:
ma i test dei nuovi task...? :wtf:
Uhm ma non doveva pensarci fek? :confused:
ciao ;)
Certo che è anche ora che incominciate a camminare con le vostre gambine. Su dai fatevi i test da soli se servono :Prrr:
ciao ;)
Certo che è anche ora che incominciate a camminare con le vostre gambine. Su dai fatevi i test da soli se servono :Prrr: ah no, stavolta aspetto che me li faccia lui, :Prrr: perché se fosse per me io riscriverei precisa com'era la classe PlayArea con il suo bel test che non testa quasi nulla (perché non c'era nulla da testare: è una classe che disegna soltanto...)
ergo onde evitare (mamma mia che latinista che sono :p) un'altra cancellazione del mio codice...
Scusatemi ragazzi, ma avrei bisogno di conoscere alcune informazioni per lo sviluppo del mio task.
La domanda è questa: la larghezza delle colonne è fissata? Lo spostamento laterale deve essere della stessa larghezze della colonne? Bisogna considerare un margine come bordo?
Scusatemi ragazzi, ma avrei bisogno di conoscere alcune informazioni per lo sviluppo del mio task.
La domanda è questa: la larghezza delle colonne è fissata?
Si per ora è della stessa larghezza di Gem. 32px.
Lo spostamento laterale deve essere della stessa larghezze della colonne?
Si.
Bisogna considerare un margine come bordo?
I bordi da considerare nelle collisioni sono in bound. Se non ricordo male il codice non dovresti essere costretto a modificare il codice delle collisioni.
ciao ;)
La domanda è questa: la larghezza delle colonne è fissata? è fissata secondo una costante che potrebbe anche cambiare :D
credo che sia abbastanza corretto considerarla uguale alla larghezza della texture delle celle, che per ora è 32; per ora mettici 32, poi quando faccio il mio task sistemo un po' di cose.
Lo spostamento laterale deve essere della stessa larghezze della colonne? io a direi il vero direi di fare uno spostamento molto veloce ma non del tutto istantaneo...
Bisogna considerare un margine come bordo? chiaramente se il diamante va a cozzare contro l'extent (o il bound che dir si voglia) si deve fermare...
Scusate ma se è così basta mettere un setSpeed(32,1) nel costruttore della Gem e questa si sposta di 32 pixel alla volta in orizzontale :D
Scusate ma se è così basta mettere un setSpeed(32,1) nel costruttore della Gem e questa si sposta di 32 pixel alla volta in orizzontale :D
Pur essendo piuttosto ignorante, posso dire la mia?
Eviterei un approccio del genere, dato che un semplice spostamento di una quantità costante di pixel, anche se coincide con la dimensione delle colonne, non ci garantisce al 100% che la gemma arrivi al posto giusto.
La sua posizione iniziale potrebbe non essere perfetta.
Ad un approccio del genere, inserirei una funzione di controllo che si assicuri del suo corretto posizionamento, magari valutando il numero della colonna in cui la gemma si trova e la coordinata orizzontale del suo hot spot, e corregga il tutto se il valore non è quello atteso.
In termini computazionali, dovrebbe avere complessità trascurabile (giusto un paio di calcoli), ma eliminerebbe ogni rischio di errore.
Poi magari è fatica inutile, ma ripeto che la programmazione non è il mio campo ^_^;;;;;;
Pur essendo piuttosto ignorante, posso dire la mia?
Eviterei un approccio del genere, dato che un semplice spostamento di una quantità costante di pixel, anche se coincide con la dimensione delle colonne, non ci garantisce al 100% che la gemma arrivi al posto giusto.
La sua posizione iniziale potrebbe non essere perfetta.
Ad un approccio del genere, inserirei una funzione di controllo che si assicuri del suo corretto posizionamento, magari valutando il numero della colonna in cui la gemma si trova e la coordinata orizzontale del suo hot spot, e corregga il tutto se il valore non è quello atteso.
In termini computazionali, dovrebbe avere complessità trascurabile (giusto un paio di calcoli), ma eliminerebbe ogni rischio di errore.
Poi magari è fatica inutile, ma ripeto che la programmazione non è il mio campo ^_^;;;;;;
Avevo pensato ad una cosa simile, ma devo attendere il parere di fek o vicius.
fek ogni volta mi dice di fare strettamente solo ciò che serve per completare il task nella maniera più semplice possibile.
Avevo pensato ad una cosa simile, ma devo attendere il parere di fek o vicius.
fek ogni volta mi dice di fare strettamente solo ciò che serve per completare il task nella maniera più semplice possibile.
C'è anche da dire che il task non è completo se c'è una percentuale (seppur piccola) di errore ;)
Comunque fek e VICIUS sono sicuramente più affidabili di me, quindi meglio attendere loro :)
caro Vifani, dico la mia: secondo me i Bounds del diamante non devono essere uguali a quelli dell'area di gioco, ma devono essere limitati alla colonna corrente in cui si trova il diamante; se l'utente preme la freccia sinistra o destra il bound deve essere esteso di una colonna a sinistra o a destra (sempre che non esca fuori dai bordi dell'area di gioco) e il diamante deve subire uno spostamento molto rapido nella direzione appropriata; deve continuare a muoversi finché le coordinate non subiscono il clipping orizzontale (e tra parentesi non sarebbe male come idea fare in modo che si possa determinare se uno Sprite ha subito un clipping durante l'ultima chiamata a move o setPos: in tal modo io potrei anche sviluppare un validissimo test per PlayArea... facciamo così?
altra soluzione più semplice (ma in realtà preferisco quella che ho esposto di sopra): il Bound corrisponde *sempre* all'area della colonna corrente; quando l'utente preme sinistra o destra il Bound viene traslato esattamente com'è (sempre che non si esca fuori dall'area di gioco) in senso orizzontale verso la nuova colonna corrente; in tal modo non appena il diamante subisce il move verticale viene fatto il clipping (anche orizzontale) e si posiziona automaticamente al posto giusto.
secondo me le soluzioni di 71104 sono eccessive, io farei più una sorta di classe wrapper che "quantizzi" il movimento orizzontale del diamante e ne assicuri un movimento corretto..
però fek stasera non si è fatto sentire e siamo bloccati (anche perché i miei task sono fondamentali per farvi procedere ^^')
per adesso farò come ho detto nel terzultimo post (prima soluzione) e casomai si riammazza PlayArea 1 altra volta.
Non sono d'accordo. Per ora questa mi sembra la piu flessibile. Ci permette di scrivere codice senza dover scrivere le try/catch quando non ci servono (il 99% delle volte). Ad esempio è possibile accedere a config senza fare assurdi controlli oppure caricare una texture senza gestire ogni volta TextureNotFoundException. Se vogliamo gestirle in un punto particolare possiamo ancora farlo inserendo appunto try/catch. Se non vengono gestite arivano alla jvm che termina il programma stampando il messaggio.
ciao ;)
rimango dell'idea che sia poco elegante, inoltre con i try catch si evidenziano meglio nel codice secondo me le parti più "sensibili", mentre adesso sono meno evidenti, certo, allo stato attuale del progetto può anche andare bene questa soluzione (anche se a me continua a non piacere), ma non è una gestione degli errori "robusta"
Avevo pensato ad una cosa simile, ma devo attendere il parere di fek o vicius.
fek ogni volta mi dice di fare strettamente solo ciò che serve per completare il task nella maniera più semplice possibile.
Se riesci a posizionare nella colonna centrale Gem poi benissimo modificare i valori delle velocità di default nella classe Gem. In questo modo non devi fare altro.
Per stare sul sicuro scrivi qualche test che mostri che l'ordinata del diamante meno l'ordinata del bordo sinistro è sempre un multiplo di 32 dopo la pressione di destra/sinistra e alla creazione.
ciao ;)
rimango dell'idea che sia poco elegante, inoltre con i try catch si evidenziano meglio nel codice secondo me le parti più "sensibili", mentre adesso sono meno evidenti, certo, allo stato attuale del progetto può anche andare bene questa soluzione (anche se a me continua a non piacere), ma non è una gestione degli errori "robusta"
I sorgenti di ora fanno esattamente quello che facevano prima (terminare il programma stampando un mesaggio ad ogni errore), ma con meno codice.
ciao ;)
io a direi il vero direi di fare uno spostamento molto veloce ma non del tutto istantaneo...
Questa era una idea. Ma per ora abbiamo preferito non complicare troppo la stroia. Magari piu avanti aggiungeremo anche l'animazione per gli psostamenti laterali.
ciao ;)
però fek stasera non si è fatto sentire e siamo bloccati (anche perché i miei task sono fondamentali per farvi procedere ^^')
per adesso farò come ho detto nel terzultimo post (prima soluzione) e casomai si riammazza PlayArea 1 altra volta.
Quella con bounds che trasla ? :confused:
Quello che secondo me ti conviene fare le segenti cose. Sempre che tu non ti diverta a vedere la tua classe gettata dalla rupe degli spartani da fek un'altra volta. :asd:
- creare una classe PlayAreaBackground in cui crei gli sprite, li posizioni e li disegni. Qui di test non dovrebbero essercene. La classe dovrebbe implementare Drawable. Si tratta di creare gli sprites e posizionarli nel costruttore e un foreach in draw.
- creare una classe PlayArea che al suo interno crea un istanza di Bounds e una di PlayareaBackground nel punto giusto dello schermo. Qui ci potrebbero essere molti cambiamenti in futuro ma per ora non ci interesa. L'unico metodo da tesatre sarebbe getBounds() per avere l'istanza di bounds creata da usare con i diamanti.
ciao ;)
[...] Sempre che tu non ti diverta a vedere la tua classe gettata dalla rupe degli spartani da fek un'altra volta. :asd: dimmi solo una cosa signor "asd": tu e fek preferite che io non lavori al progetto? perché è un po' che vi immagino così: :ahahah: (quello rosso sarei io e quello azzurro voi...)
percui se avete qualcosa da dirmi in proposito ditemelo apertamente: in caso cancellate pure la mia prenotazione a questi task senza che io continui a lavorare inutilmente...
- creare una classe PlayAreaBackground in cui crei gli sprite, li posizioni e li disegni. Qui di test non dovrebbero essercene. La classe dovrebbe implementare Drawable. Si tratta di creare gli sprites e posizionarli nel costruttore e un foreach in draw.
- creare una classe PlayArea che al suo interno crea un istanza di Bounds e una di PlayareaBackground nel punto giusto dello schermo. Qui ci potrebbero essere molti cambiamenti in futuro ma per ora non ci interesa. L'unico metodo da tesatre sarebbe getBounds() per avere l'istanza di bounds creata da usare con i diamanti. non dovevi dirlo -.-'
ora sono praticamente costretto a fare come dici :-|
comunque non sta a me implementare il movimento orizzontale, istantaneo o rapido che sia; io avrei semplicemente creato PlayArea, che per ora disegna solo le celle; in più avrei messo quel famoso test che mi è venuto in mente.
dimmi solo una cosa signor "asd": tu e fek preferite che io non lavori al progetto? perché è un po' che vi immagino così: :ahahah: (quello rosso sarei io e quello azzurro voi...)
percui se avete qualcosa da dirmi in proposito ditemelo apertamente: in caso cancellate pure la mia prenotazione a questi task senza che io continui a lavorare inutilmente...
personalmente non ho nulla contro di te. anzi ti ritengo piuttosto dotato come programamtore. secondo me ti manca solo un po di esperienza.
quella degli spartani era semplicemente un battuta. nulla piu. se ti ho offeso in qualche modo mi schuso.
non dovevi dirlo -.-'
ora sono praticamente costretto a fare come dici :-|
comunque non sta a me implementare il movimento orizzontale, istantaneo o rapido che sia; io avrei semplicemente creato PlayArea, che per ora disegna solo le celle; in più avrei messo quel famoso test che mi è venuto in mente.
guarda che il mio era solo un consiglio su come procedere per separare playarea in due classi distinte e testarla. non voleva essere assolutamente un ordine. il motivo principale per cui fek a fatto il revert di playarea era appunto perchè mancavano i test e faceva due cose distinte.
ciao ;)
boh, chiediglielo...
Oggi e domani sono in MS e senza un PC collegato.
cdimauro
13-10-2005, 10:18
Ho scritto il codice del test del mio task (TestLogo). Poi ho provveduto alla creazione della classe Logo che implementava quanto richiesto per far funzionare il test. Fin qui tutto ok. Poi ho provveduto a inserire nel codice di Game le (poche) istruzioni necessarie ad agganciare il logo all'area grafica. Qui sono sorti i problemi (da premettere che Ant mi dà l'OK e il test passa correttamente).
Ho eseguito il commit commentando, però, 3 righe in game.Java.
In createSprites:
//logo = new Logo(b1, b2);
fra la creazione delle playarea e del diamante.
sempre in createSprites:
//items.add(logo);
dopo l'add delle playarea.
In quit:
//logo.cleanup();
prima di tutti gli altri cleanup.
Questo per far continuare a funzionare correttamente Game esattamente com'era prima.
Il problema è che basta già decommentare la prima riga, quella della creazione / caricamento del Logo, per far bloccare il programma col seguente errore:
Exception in thread "main" org.lwjgl.opengl.OpenGLException: Invalid value (1281)
at org.lwjgl.opengl.Util.checkGLError(Util.java:56)
at org.lwjgl.opengl.Display.update(Display.java:567)
at it.diamonds.engine.DisplayImpl.update(DisplayImpl.java:67)
at it.diamonds.engine.Engine.updateDisplay(Engine.java:68)
at it.diamonds.Game.update(Game.java:129)
at it.diamonds.Game.main(Game.java:44)
Questo senza NEMMENO aver inserito l'oggetto in "items", e quindi farlo disegnare assieme agli altri. Infatti la creazione dell'oggetto va a buon fine, come pure tutto il resto del codice in createSprites: il fault si verifica all'atto di eseguire l'update, e quindi richiamando engine.updateDisplay().
Avete qualche idea su quale potrebbe essere il problema (ma sempre a me? :cry: )?
Un'altra cosa: potremmo finalmente deciderci ad utilizzare Config per memorizzare tutte le costanti e recuperarle soltanto da quest'oggetto? Così evitiamo di tenere costanti utili anche alle altre parti del codice o di doverle duplicare. Mi riferisco a quelle di cui è farcita createSprites (la dimensione dello schermo e delle playarea, ecc.) o altre parti del codice.
il problema è nella texture, infatti se provi a mettere
super(new Texture("diamond"), null);
al posto di
super(new Texture("logo"), null);
non crea nessun problema, adesso però bisogna capire cosa ha che non va logo..
cdimauro
13-10-2005, 11:10
Grazie per il suggerimento! Infatti così funziona perfettamente. Ho fatto il commit usando diamond.png al posto di logo.png, in attesa di informazioni in merito a quest'anomalia.
Un'altra cosa: avere due sistemi di riferimento diversi è seccante. Tra l'altro col riferimento attuale ci stiamo legando troppo a OpenGL.
Propongo di passare al sistema di riferimento ("classico") che ha come origine l'angolo in alto a sinistra, con l'asse delle Y che cresce verso il basso; allo stesso modo, per tutti gli oggetti (sprite, play area, ecc.) il riferimento dovrebbe essere l'angolo in alto a sinistra.
Secondo me tutto diventa più semplice da gestire.
ho l'impressione che il problema abbia a che fare con la dimensione dell'immagine, ma non ne sono sicuro e al momento non posso verificare meglio
cdimauro
13-10-2005, 11:12
Strano però se è veramente questo il problema. logo.png in effetti ha un'altezza dispari (129) e l'hot spot, con questo sistema di riferimento, mi torna la coordinata Y con .5 come decimale...
Ho appena fatto un update e mi trovo un po spaesato :)
Per trovare il codice di gem ho dovuto usare grep. Perchè gli è stato cambiato nome in GridSprite? Come nome mi sembra sbagliatissimo per due motivi. Non c'entra nulla con quello che fa la classe e oltretutto fornisce informazioni su come è implementata.
ciao ;)
l'ho rinominata GridSprite perché (come ho spiegato nel commit) rappresenta il particolare tipo di sprite gestito dalla classe Grid, che ancora non ho creato...
rispetto a Sprite, GridSprite aggiunge le seguenti caratteristiche:
- reagisce agli input della tastiera (c'è già)
- ha la "gravità" (c'è già)
- ha la capacità di "agganciarsi" ad una riga e ad una colonna specifica una volta che termina la sua caduta; a quel punto, una volta agganciata, qualsiasi chiamata a move ritorna false (e questa è da implementare)
poi casomai in futuro potremo anche differenziare i vari tipi di diamanti che cadono creando Gem, e tutte le altre per rubini, zaffiri, ecc., ma io consiglio piuttosto di usare la stessa classe passando in input al costruttore nomi di texture diverse.
cdmauro, non capisco due cose: :mbe:
- perché per disegnare il Logo hai fatto una classe apposta? Sprite andava già bene...
- perché nel costruttore di questa classe (praticamente vuota) hai preso in input due oggetti Bounds? non ho capito come mai li usi così...
:mbe:
cdimauro
13-10-2005, 13:10
Il mio task (5.8) era questo:
"disegnare il logo del task 5.7 in basso tra le due aree di gioco"
Quindi l'obiettivo era di disegnare un logo. E poteva andare benissimo uno sprite, ma avevo l'esigenza di vincolarlo alla condizione specificata subito dopo.
Per cui ho pensato di crearmi un'apposita classe, derivata da sprite, ma "specializzata" per questo compito; questo è il motivo per cui il costruttore di Logo prende come valori di input i due oggetti Bounds, ossia le due aree di di gioco. Mi sembra più leggibile così.
In effetti potevo anche creare un metodo createLogo(Bounds extents1, Bounds extents1) che tornava l'istanza di Sprite opportunatamente inizializzata.
Boh. Non so. M'è venuta così. Forse è la mania di specializzare le classi che mi ha portato a questo. :p
Al limite rifattorizzo tutto usando createLogo, se dite che è il caso. ;)
Comunque nessuno ha ancora commentato sulle mie proposte relative a Config e al sistema di riferimento. :(
per quanto riguarda il sistema di riferimento direi di usare quello con l'origine situato in basso a sinistra (non c'è motivo di fare inutili conversioni di coordinate quando passiamo il tutto a OpenGL), che poi è l'unico che usiamo a parte per i Bounds che prima o poi qualcuno si deciderà a convertire definitivamente (probabilmente io se non lo farà nessun altro :p).
per quanto riguarda Config, direi che lo stiamo già facendo... guarda il thread Diamonds Knowledge: lì trovi definite quelle che per ora sono le costanti che deve contenere.
l'ho rinominata GridSprite perché (come ho spiegato nel commit) rappresenta il particolare tipo di sprite gestito dalla classe Grid, che ancora non ho creato...
rispetto a Sprite, GridSprite aggiunge le seguenti caratteristiche:
- reagisce agli input della tastiera (c'è già)
- ha la "gravità" (c'è già)
- ha la capacità di "agganciarsi" ad una riga e ad una colonna specifica una volta che termina la sua caduta; a quel punto, una volta agganciata, qualsiasi chiamata a move ritorna false (e questa è da implementare)
poi casomai in futuro potremo anche differenziare i vari tipi di diamanti che cadono creando Gem, e tutte le altre per rubini, zaffiri, ecc., ma io consiglio piuttosto di usare la stessa classe passando in input al costruttore nomi di texture diverse.
Sei sicuro che fossero necessari tutti questi cambiamenti per disegnare una semplice griglia all'interno di Bounds?
ciao ;)
per quanto riguarda il sistema di riferimento direi di usare quello con l'origine situato in basso a sinistra (non c'è motivo di fare inutili conversioni di coordinate quando passiamo il tutto a OpenGL),
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 ;)
Strano però se è veramente questo il problema. logo.png in effetti ha un'altezza dispari (129) e l'hot spot, con questo sistema di riferimento, mi torna la coordinata Y con .5 come decimale...
Le texture devono avere dimensioni potenza di due. Ergo 129 non va bene. Se lo converti a 128 vedrai che funziona bene. L'unico modo per fare funzionare texture con coordinate dispari è usare un'apposita estensione che si chiama GL_EXT_NON_POWER_OF_TWO, che è di ultima generazione e non ancora supportata da alcuni processori grafici. Comunque non ne varrebbe la pena, meglio avere l'accortezza di usare dimensioni potenza di due e amen.
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. non sono due o tre classi, c'è da fare una marea di modifiche nel codice e i test potrebbero non aiutare in questo caso perché andrebbero modificati anche quelli... il programma potrebbe tornare a funzionare come prima, cioè per caso (o per miracolo che dir si voglia); non è meglio finire di convertire Bounds e tanti saluti? che importa come siamo abituati a pensare il riferimento cartesiano? e poi vorrei precisare che tu sei abituato a pensarlo con l'asse delle Y orientato verso il basso, ma in geomtria in genere non è così... verissimo che solitamente le client areas delle finestre di (penso) qualsiasi interfaccia grafica sono orientate verso il basso, ma se noi lavoriamo con uno strumento che funziona secondo la norma, inutile andare controcorrente.
cdimauro
13-10-2005, 14:33
per quanto riguarda il sistema di riferimento direi di usare quello con l'origine situato in basso a sinistra (non c'è motivo di fare inutili conversioni di coordinate quando passiamo il tutto a OpenGL), che poi è l'unico che usiamo a parte per i Bounds che prima o poi qualcuno si deciderà a convertire definitivamente (probabilmente io se non lo farà nessun altro :p).
Non sono d'accordo. Come ho già detto, ci stiamo vincolando troppo a una tecnologia, OpenGL, che è soltanto una soluzione di comodo che abbiamo trovato per il momento, visto che il progetto non è legato a niente. Potevamo usare anche SDL. Potevamo usare anche JOGL. Potevamo usare anche le SWING o le AWT, che almeno troviamo già nel pacchetto Java.
Il motivo per cui ho fatto sparire tutte le costanti (nelle parti in cui ho lavorato), vincolandole dentro i rispettivi moduli, è proprio quello di nascondere del tutto un dettaglio implementativo come questo.
Se domani volessimo effettuare il porting per dei telefonini, ad esempio, e ci ritroviamo con delle altre API che lavorano con un sistema di riferimento diverso, come facciamo?
Meglio lavorare con il sistema che a noi (programmatori. In particolare di giochi 2D :p) viene più facile da usare, e che è quello che ho esposto. ;)
per quanto riguarda Config, direi che lo stiamo già facendo... guarda il thread Diamonds Knowledge: lì trovi definite quelle che per ora sono le costanti che deve contenere.
Potresti aggiornarlo includendo tutte le altre costanti? PlayArea Width, Height, PlayPos1, PlayPos2, ecc. Al posto di Width e Height io metterei ScreenWidth e ScreenHeight, e comunque per le altre utilizziamo dei nomi più significativi.
Quando ci sono degli aggiornamenti, è meglio fare degli "up": così almeno capiamo che qualcosa è cambiato... ;)
per ora posso solo mettere dei suggerimenti, non posso scrivere statements falsi nella knowledge; li metterò sotto forma di statements quando avrò effettivamente apportato quelle modifiche al codice e quando avrò fatto un commit.
cdimauro
13-10-2005, 14:43
Le texture devono avere dimensioni potenza di due. Ergo 129 non va bene. Se lo converti a 128 vedrai che funziona bene. L'unico modo per fare funzionare texture con coordinate dispari è usare un'apposita estensione che si chiama GL_EXT_NON_POWER_OF_TWO, che è di ultima generazione e non ancora supportata da alcuni processori grafici. Comunque non ne varrebbe la pena, meglio avere l'accortezza di usare dimensioni potenza di due e amen.
Questo però è un vincolo (addizionale: non era nelle specifiche) che non possiamo accollarci. Coi giochi 2D è normalissimo realizzare grafica "su misura": mi serve un oggetto 5x5? Lo creo così: poco importa che le dimensioni non siano potenze di 2.
Questo costringerebbe i grafici a realizzare qualunque oggetto tenendo sempre presente le potenze di due. E' seccante.
Tra l'altro col sistema di coordinate attuali, con l'hot spot in mezzo all'oggetto, accadrebbe che un oggetto che ha una dimensione "visibile" di 129x129 dovrebbe essere esteso a 256x256, e l'hot spot finirebbe nell'angolo in basso a destra della parte visibile. Il che non è molto bello.
Se è possibile, questi "vincoli" dovrebbero essere gestiti dalla classe Texture, al momento del caricamento: se l'immagine è 129x129, si crea una texture 256x256, e gliela si schiaffa in mezzo :p.
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.
cdimauro
13-10-2005, 14:48
non sono due o tre classi, c'è da fare una marea di modifiche nel codice e i test potrebbero non aiutare in questo caso perché andrebbero modificati anche quelli... il programma potrebbe tornare a funzionare come prima, cioè per caso (o per miracolo che dir si voglia); non è meglio finire di convertire Bounds e tanti saluti? che importa come siamo abituati a pensare il riferimento cartesiano? e poi vorrei precisare che tu sei abituato a pensarlo con l'asse delle Y orientato verso il basso, ma in geomtria in genere non è così... verissimo che solitamente le client areas delle finestre di (penso) qualsiasi interfaccia grafica sono orientate verso il basso, ma se noi lavoriamo con uno strumento che funziona secondo la norma, inutile andare controcorrente.
Di sicuro dobbiamo deciderci a togliere di mezzo quest'anomalia della coesistenza dei due sistemi di coordinate. IMHO, chiaramente.
Poi su quale adottare, decidiamo insieme. Io voto per quello "raster", che nel 2D è il più diffuso e usato (finora ho visto soltanto le immagini .BMP con l'orientamento verso l'alto).
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à.
OpenGL l'abbiamo scelto apposta perché c'è anche su Linux...
non c'è sui cellulari, ok: cosa ci consigli di fare? non esiste imho toolkit o intefraccia grafica che sia che ci permetta di girare OVUNQUE; intanto pensiamo ai computers, poi penseremo ai cellulari...
Tra l'altro col sistema di coordinate attuali, con l'hot spot in mezzo all'oggetto, accadrebbe che un oggetto che ha una dimensione "visibile" di 129x129 dovrebbe essere esteso a 256x256, e l'hot spot finirebbe nell'angolo in basso a destra della parte visibile. Il che non è molto bello. no, ti sbagli! questo non accade perché l'hot spot è posizionato esattamente alla larghezza della texture diviso due e all'altezza della texture diviso due; il problema è un altro: Sprite eredita le sue dimensioni dalla texture che carica nel costruttore (se non ne carica nessuna rimane 0x0), quindi il problema attuale è il seguente: non è possibile creare sprites le cui dimensioni non siano diverse da potenze di due; il che va risolto semplicemente impostando valori differenti come width ed height (a fare lo stretching ci pensa OpenGL), ma rimane il problema di dove memorizzare le coordinate effettive dello sprite, visto che l'immagine della texture è di dimensioni diverse: qualsiasi soluzione proponi come minimo è poco elegante, e infatti è un bel problema...
Se è possibile, questi "vincoli" dovrebbero essere gestiti dalla classe Texture, al momento del caricamento: se l'immagine è 129x129, si crea una texture 256x256, e gliela si schiaffa in mezzo :p. ma così sbaglio o rimane una cornice nera...? :mbe:
Di sicuro dobbiamo deciderci a togliere di mezzo quest'anomalia della coesistenza dei due sistemi di coordinate. IMHO, chiaramente. su questo siamo tutti d'accordo.
Poi su quale adottare, decidiamo insieme. Io voto per quello "raster", che nel 2D è il più diffuso e usato (finora ho visto soltanto le immagini .BMP con l'orientamento verso l'alto). se decidiamo di fare così ok, ma... a nostro rischio e pericolo...
cdimauro
13-10-2005, 15:06
OpenGL l'abbiamo scelto apposta perché c'è anche su Linux...
non c'è sui cellulari, ok: cosa ci consigli di fare? non esiste imho toolkit o intefraccia grafica che sia che ci permetta di girare OVUNQUE; intanto pensiamo ai computers, poi penseremo ai cellulari...
Te l'ho detto: il sistema di riferimento più comune, anche nei computer, è quello che pone l'origine degli assi nell'angolo in alto a sinistra. Usiamo questo e creeremo meno problemi in tutti quei sistemi dotati di sole funzionalità 2D, e che in genere adottano questo tipo di riferimento.
intanto pensiamo ai computers, poi penseremo ai cellulari...
Approccio IMHO sbagliatissimo. Va bene implementare STRETTAMENTE quel che serve, ma non chiudere le porte al resto.
Sul fatto che OpenGL sia universale, inoltre, ho i miei dubbi: il PC che sto usando ora, ad esempio, lo supporta decisamente male. Eppure è un semplice PC Wintel, seppur molto vecchio. Per questo, eviterei di basare il codice su questa o quella libreria.
In ogni caso, non siamo affatto nel mio campo, quindi mi fido di voi ;)
no, ti sbagli! questo non accade perché l'hot spot è posizionato esattamente alla larghezza della texture diviso due e all'altezza della texture diviso due; il problema è un altro: Sprite eredita le sue dimensioni dalla texture che carica nel costruttore (se non ne carica nessuna rimane 0x0), quindi il problema attuale è il seguente: non è possibile creare sprites le cui dimensioni non siano diverse da potenze di due; il che va risolto semplicemente impostando valori differenti come width ed height (a fare lo stretching ci pensa OpenGL), ma rimane il problema di dove memorizzare le coordinate effettive dello sprite, visto che l'immagine della texture è di dimensioni diverse: qualsiasi soluzione proponi come minimo è poco elegante, e infatti è un bel problema...
ma così sbaglio o rimane una cornice nera...? :mbe:
Non ho capito... quindi tutto dovrebbe essere in potenza di due? :mbe:
Mi pare improbabile che debba essere per forza così... e se possibile evitiamo stretching di qualsiasi genere, ve ne prego :cry:
cdimauro
13-10-2005, 15:13
no, ti sbagli! questo non accade perché l'hot spot è posizionato esattamente alla larghezza della texture diviso due e all'altezza della texture diviso due;
E quindi non fai che confermare il problema. :p
Infatti, se l'immagine è 129x129 e la texture corrispondente sarà 256x256, e poni l'immagine a partire dall'angolo in alto a sinistra della texture, ti trovi con l'hot spot che si trova nel pixel in basso a destra dell'immagine.
Esempio con Immagine 5x5
XXXXX
XXXXX
XXXXX
XXXXX
XXXXX
Diventa
XXXXX---
XXXXX---
XXXXX---
XXXOO---
XXXOO---
--------
--------
--------
Nella texture. Con OO ho indicato i 4 pixel dell'immagine che diventerebbero l'hot spot.
il problema è un altro: Sprite eredita le sue dimensioni dalla texture che carica nel costruttore (se non ne carica nessuna rimane 0x0), quindi il problema attuale è il seguente: non è possibile creare sprites le cui dimensioni non siano diverse da potenze di due; il che va risolto semplicemente impostando valori differenti come width ed height (a fare lo stretching ci pensa OpenGL), ma rimane il problema di dove memorizzare le coordinate effettive dello sprite, visto che l'immagine della texture è di dimensioni diverse: qualsiasi soluzione proponi come minimo è poco elegante, e infatti è un bel problema...
Nessun problema, basta aggiornare Texture in modo da memorizzare come width e height le dimensioni dell'immagine caricata. In questo modo Sprite prenderebbe le dimensioni corrette. Mentre internamente utilizzarà pow2Width e pow2Height che serviranno per il rendering.
ma così sbaglio o rimane una cornice nera...? :mbe:
Se al posto del nero ci sono dei pixel trasparenti, no... ;)
cdimauro
13-10-2005, 15:15
se decidiamo di fare così ok, ma... a nostro rischio e pericolo...
Nessuno rischio e pericolo: meglio pensarci ora, che cambiare le carte in tavola in futuro, col progetto composto da molte più righe di codice.
Tra l'altro i cambiamenti si dovrebbero fare comunque, no? Al posto di cambiare Bounds, cambiamo Sprite & co. ;)
cdimauro
13-10-2005, 15:17
Non ho capito... quindi tutto dovrebbe essere in potenza di due? :mbe:
Mi pare improbabile che debba essere per forza così... e se possibile evitiamo stretching di qualsiasi genere, ve ne prego :cry:
Non ti preoccupare: non serve affatto lo stretching. ;)
Usando il sistema di riferimento con l'hot spot in alto a sinistra e facendo sì che la parte "in più" delle texture (che devono essere per forza con dimensioni aventi potenze di due) risulti trasparente, i grafici non avranno nulla da temere... :D :mano:
Non ti preoccupare: non serve affatto lo stretching. ;)
Usando il sistema di riferimento con l'hot spot in alto a sinistra e facendo sì che la parte "in più" delle texture (che devono essere per forza con dimensioni aventi potenze di due) risulti trasparente, i grafici non avranno nulla da temere... :D :mano:
Meno male :cincin:
Una delle cose che odio di più sono le bitmap "strecciate" (o stretchate o come vi pare), inevitabilmente il loro aspetto degrada oltre i limiti consentiti dal buongusto :doh:
Ragazzi mi dispiace ma non mi piace assolutamente la piega che sta prendendo lo sviluppo.
Come per tutti i sistemi di questo mondo esistono ed esisteranno sempre delle limitazioni e tentare di sviluppare il tutto senza appoggiarsi a librerie esterne a mio avviso è una pazzia. Esistono librerie che possono rendere il gioco portatile e al contempo aggiungere funzionalità estremamente utili e OpenGL è uno di questi. Si parlava di poter aggiungere qualche effetto 3D-like o cose di questo tipo e la tecnologia OpenGL è l'unica che consente di realizzare cose simili sfruttando l'accelerazione hardware e con una buona portabilità: Windows, Linux e MacOS. Non si esclude in futuro il supporto anche ai palmari e a cellulari compatibili OpenGL ES.
La limitazione relativa al sistema di coordinate è una limitazione relativa ad OpenGL (indipendente dal binding utilizzato), ma di fatto può essere superata. Il problema è che per superarla bisogna fare una operazione di traduzione delle coordinate che definirei "mentali" (cioè quelle che vi piacciono tanto con origine in alto a sinistra) a quelle che vuole OpenGL. Secondo me è una perdita di tempo, alla fine è solo questione di abitudine e non mi sembra il caso di farne un dramma.
Per quanto riguarda la limitazione della risoluzione delle texture, con DEVIL è abbastanza semplice convertire una texture da una risoluzione ad un'altra (anche se non so che tipo di filtro applichi), però invito i grafici a venire incontro alle esigenze di programmazione e cioè se dovete fare una texture 129x129, la fate 128x128 e amen, non mi sembra una tragedia. Vi ricordo che ai disegnatori di videogames 3D gli si impongono limitazioni molto più pesanti: numero massimo di poligoni per modello, numero di gruppi, numero massimo di modelli, superfici chiuse, texture potenza di due e di un tot massimo di risoluzione, ecc..
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.
Serve prima di tutto chiarezza.
Ad esempio, i grafici dovrebbero essere messi a conoscenza delle limitazioni per le texture, e delle caratteristiche che queste devono avere.
In ogni caso, bisogna vedere di trovare un metodo di visualizzazione alternativo delle immagini, dato che - per i frame di animazione dei personaggi - l'approssimazione a quadrato con lato potenza di 2 non mi sembra molto fattibile.
Ulteriori dettagli saranno graditi nel topic sulla grafica, così non incasiniamo questo ;)
Serve prima di tutto chiarezza.
Ad esempio, i grafici dovrebbero essere messi a conoscenza delle limitazioni per le texture, e delle caratteristiche che queste devono avere.
In ogni caso, bisogna vedere di trovare un metodo di visualizzazione alternativo delle immagini, dato che - per i frame di animazione dei personaggi - l'approssimazione a quadrato con lato potenza di 2 non mi sembra molto fattibile.
Ulteriori dettagli saranno graditi nel topic sulla grafica, così non incasiniamo questo ;)
No no, non devono essere per forza un quadrato. Possono anche essere rettangolari, ma le dimensioni in altezza e laghezza devono essere potenza di due, non necessariamente le stesse.
Aggiungo comunque che la maggioranza dei processori grafici (almeno in OpenGL) gestiscono texture anche senza dimensioni potenza di due, ma è sufficiente che siano pari.
da me lo stesso problema lo da con background.png, che è 800x600...
cmq, secondo me non bisogna vincolarsi a come fa l'openGL per quanto riguarda l'orientamento degli assi, dobbiamo fare una scelta e mantenerla, secondo me vanno bene come sono orientati adesso, e non è certo l'orientazione degli assi a creare i problemi, l'importante che se ne scelga una e si mantenga (come l'hotspot), io propongo di finire la storia, mantenendo le cose come stanno, e poi di definire un po di cose e portare un po di chiarezza, adesso che siamo ancora in tempo ad aggiustare le cose..
io propongo di finire la storia, mantenendo le cose come stanno, e poi di definire un po di cose e portare un po di chiarezza, adesso che siamo ancora in tempo ad aggiustare le cose.. ok, io sono d'accordo; dunque finiamo questa storia ;)
cdimauro
14-10-2005, 10:20
Ragazzi mi dispiace ma non mi piace assolutamente la piega che sta prendendo lo sviluppo.
Come per tutti i sistemi di questo mondo esistono ed esisteranno sempre delle limitazioni e tentare di sviluppare il tutto senza appoggiarsi a librerie esterne a mio avviso è una pazzia. Esistono librerie che possono rendere il gioco portatile e al contempo aggiungere funzionalità estremamente utili e OpenGL è uno di questi.
Indubbiamente, ma ti ricordo che stiamo sviluppando un gioco 2D, non uno 3D.
OpenGL l'abbiamo scelto perché abbiamo trovato una soluzione veloce a un problema che avevamo: quello di rappresentare la grafica fluidamente su diversi sistemi.
Se avesse funzionato la modalità "full screen" di Java standard, non avremmo avuto bisogno di appoggiarci a delle librerie esterne e non avremmo avuto tutti i problemi che si sono verificati finora a causa di questa scelta.
Purtroppo per adesso il supporto di Java a funzionalità come questa per tutte le piattaforme non è ancora maturo.
Si parlava di poter aggiungere qualche effetto 3D-like o cose di questo tipo e la tecnologia OpenGL è l'unica che consente di realizzare cose simili sfruttando l'accelerazione hardware e con una buona portabilità: Windows, Linux e MacOS.
Certamente, ma quest'ipotesi è venuta DOPO la scelta di OpenGL, non prima.
Quello di usare delle librerie che permettessero di gestire grafica 3D non era un requisito del progetto, ma al contrario rappresenta la soluzione più comoda che abbiamo trovato a un problema preciso.
Questo non vuol dire che si debba stravolgere il progetto a causa di questa scelta. L'idea era anche quella di cambiare il back-end del gioco per farlo girare su sistemi che non supportano OpenGL: legadoci mani e piedi a questa libreria sarebbe alquanto difficile farlo.
Non si esclude in futuro il supporto anche ai palmari e a cellulari compatibili OpenGL ES.
Quanti sono? Perché IMHO la maggior parte, per bene che vada, supporta soltanto J2ME senza OpenGL ES.
La limitazione relativa al sistema di coordinate è una limitazione relativa ad OpenGL (indipendente dal binding utilizzato), ma di fatto può essere superata. Il problema è che per superarla bisogna fare una operazione di traduzione delle coordinate che definirei "mentali" (cioè quelle che vi piacciono tanto con origine in alto a sinistra) a quelle che vuole OpenGL. Secondo me è una perdita di tempo, alla fine è solo questione di abitudine e non mi sembra il caso di farne un dramma.
Indubbiamente, ma noi stiamo realizzando un progetto che rappresenta un gioco 2D. E nel 2D normalmente si utilizza quel sistema di riferimento.
Per quanto riguarda la limitazione della risoluzione delle texture, con DEVIL è abbastanza semplice convertire una texture da una risoluzione ad un'altra (anche se non so che tipo di filtro applichi), però invito i grafici a venire incontro alle esigenze di programmazione e cioè se dovete fare una texture 129x129, la fate 128x128 e amen, non mi sembra una tragedia. Vi ricordo che ai disegnatori di videogames 3D gli si impongono limitazioni molto più pesanti: numero massimo di poligoni per modello, numero di gruppi, numero massimo di modelli, superfici chiuse, texture potenza di due e di un tot massimo di risoluzione, ecc..
Hai detto bene: ai disegnatori di videogame 3D. Qui stiamo realizzando un videogame 2D, per cui limitazioni come quella delle coordinate che devono essere potenze di 2D sono troppo esagerate. Un engine 2D è diverso da un engine 3D.
Comunque non c'è bisogno di alcuno stretching, che tra l'altro altera la grafica (e i grafici, per esperienza personale, non amano le alterazioni alle loro opere d'arte :p): basta utilizzare il suggerimento che ho esposto. Carichiamo l'immagine nella parte in alto a sinistra di una texture, e il resto lo riempiamo con un "colore trasparante". In questo modo quando la texture verrà tracciata, a video vedremo soltanto la parte dell'immagine originale.
E' sufficiente cambiare soltanto l'implementazione di Texture in modo da mappare opportunamente le immagini su texture con coordinate aventi potenze di 2. Tutto il resto non dovrebbe cambiare di una virgola.
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.
Non è in discussione l'adozione di OpenGL, ci mancherebbe! Questa libreria bene o male funziona e ha risolto il problema che avevamo inizialmente.
Il punto è quello di non introdurre nel progetto dei vincoli derivanti dall'adozione di OpenGL, che è ben diverso. Quello delle immagini aventi potenze di 2 come coordinate non era e non è un requisito del progetto.
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.
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.
Sei sicuro che fossero necessari tutti questi cambiamenti per disegnare una semplice griglia all'interno di Bounds?
ciao ;)
No, sono certo che non lo fossero e non ci siamo proprio.
Sto vedendo molti cambiamenti non dettati ne' da test ne' da necessita' di implementazione e la cosa non mi sta piacendo affatto.
Direi di abbandonare la Storia 2 per questo Ciclo e ripensarla per bene per il prossimo Ciclo 3.
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.
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.
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
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...
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.
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
14-10-2005, 12:05
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.
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 -_-'
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.
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.
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 :mano:
Anche perchè il problema potrebbe essere affrontato in altri modi che non abbiamo considerato...visto che le istruzioni openGL da cambiare sarebbero veramente poche...
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.
Questa Storia e' spostata al prossimo ciclo. Potete chiudere il topic?
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.