View Full Version : [CICLO 3] Storia 2
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). Lo spostamento laterale da una casella all'altra deve essere pressocchè istantaneo, quello verticale invece più lento e fluido. Lo sfondo dell'area di gioco è una texture unica da 256x448 pixel.
Task:
3.2.1 Realizzare la Texture 256x448 trasparente da usare come sfondo per l'area di gioco. (Jocchan: completato)
3.2.2 Creare una classe PlayAreaBackground che disegna la griglia usando la texture del task 3.2.1 (Gammaglobulino: 1 giorno)
3.2.3 Creare una matrice di sprite MxN allineate al background e disegnare i diamanti contenuti (71104: completato)
3.2.4 Inserire un diamante nella colonna centrale. Dev'essere possibile inserire un diamante solo dall'ultima riga di ogni colonna. Aggiungere a Texture la possibilità di abiltare l'uso del canale alpha. (Vifani: 2 giorni)
3.2.5 Alla pressione dei tasti destra/sinistra il diamante deve spostarsi nella colonna addiacente istantaneamente. (fpitt: 2 giorni)
3.2.6 Spostare la gestione della gravita e le collisioni dei diamanti nella classe che gestisce la griglia.
Le modalità sono le stesse della storia precedente. Ci si prenota. Si postano i test e poi dopo la conferma si procede con il codice e commit.
ciao ;)
3.2.1
3.2.3 COMPLETATO -0 +3 (71104)
3.2.4 COMPLETATO -3 +4 (Vifani)
3.2.5 COMPLETATO -3 +5 (cionci)
3.2.6 COMPLETATO -3 +5 (fpitt)
Gammaglobulino
24-10-2005, 16:24
Mi prenoto per il 3.2.2
:cool:
30 minuti.
Sborone! :D
L'unita' minima che usiamo e' il giorno!
Gammaglobulino
24-10-2005, 16:37
Sborone! :D
L'unita' minima che usiamo e' il giorno!
Considerando che non sò nemmeno aprire Eclipse anche troppo :D
Mi prenoto per il 3.2.2
:cool:
30 minuti.
Tutto tuo. :)
ciao ;)
io vorrei fare il 3.2.3, 1 giorno forse 2, solo che bisogna prima chiarire bene se ci sarà in futuro la possibilità di creare i diamantoni, o le power gems, o come si chiamano, perché in tal caso più che come matrice di MxN io la griglia la gestirei come un vettore.
comunque prima di passare a questa storia io e fek adesso dovevamo fare un po' di refactoring incapsulando Rectangle in Bounds... (adesso apro il thread)
comunque prima di passare a questa storia io e fek adesso dovevamo fare un po' di refactoring incapsulando Rectangle in Bounds... (adesso apro il thread) come non detto :D
io vorrei fare il 3.2.3, 1 giorno forse 2, solo che bisogna prima chiarire bene se ci sarà in futuro la possibilità di creare i diamantoni, o le power gems, o come si chiamano, perché in tal caso più che come matrice di MxN io la griglia la gestirei come un vettore.
comunque prima di passare a questa storia io e fek adesso dovevamo fare un po' di refactoring incapsulando Rectangle in Bounds... (adesso apro il thread)
Fatto. Il task è tutto tuo.
ciao ;)
Fatto. Il task è tutto tuo. allora per adesso la gestisco come una matrice, poi casomai refattorizzeremo...
Mi prenoto per il 3.2.4. Tempo di realizzazione: 2 giorni a partire dal giorno di completamento del task 3.2.3.
3.2.5, tempo stimato, 1 giorno dalla fine del 3.2.3
Mi prenoto per il 3.2.4. Tempo di realizzazione: 2 giorni a partire dal giorno di completamento del task 3.2.3.
Ok.
3.2.5, tempo stimato, 1 giorno dalla fine del 3.2.3
OK.
ciao ;)
ehm, scusami Vicius, ripensandoci, dato che non so quando verranno effettivamente finiti gli altri task, e dato che nei prossimi giorni non ho molto tempo libero, potresti togliere la mia prenotazione, eventualmente, se non c'è nessuno che si è prenotato per quando verrò finito il 3.2.3 e io sono libero da altri impegni, me ne occupo io, ok?
Mi prenoto io per il 3.2.5, tempo stimato 2 giorni
ehm, VICIUS, qui mi sa che famo un altro bel casino e poi dobbiamo di nuovo tornare indietro co sti revert mostruosi e perdiamo un'altra marea di tempo... ancora una volta mi sono preso un task fondamentale che ho quasi finito (test compresi) solo che non vorrei che a fek il codice sembrasse troppo complesso... io ho cercato di fare le cose IL PIU' SEMPLICE POSSIBILE, ho fatto test per tutti quanti i metodi e ho svolto il task parzialmente test first ^^'
comunque per sicurezza oggi faccio un commit che non sarà definitivo (per cui ragazzi non ci lavorate ancora) ma domani vorrei il tuo parere e casomai anche quello di fek :)
71104:
Le modalità sono le stesse della storia precedente. Ci si prenota. Si postano i test e poi dopo la conferma si procede con il codice e commit.
ehm, VICIUS, qui mi sa che famo un altro bel casino e poi dobbiamo di nuovo tornare indietro co sti revert mostruosi e perdiamo un'altra marea di tempo... ancora una volta mi sono preso un task fondamentale che ho quasi finito (test compresi) solo che non vorrei che a fek il codice sembrasse troppo complesso... io ho cercato di fare le cose IL PIU' SEMPLICE POSSIBILE, ho fatto test per tutti quanti i metodi e ho svolto il task parzialmente test first ^^'
comunque per sicurezza oggi faccio un commit che non sarà definitivo (per cui ragazzi non ci lavorate ancora) ma domani vorrei il tuo parere e casomai anche quello di fek :)
Miii che testa dura. :muro: Prima di fare il commit e cominciare a scrivere codice vogliamo vedere test.
ciao ;)
ehm, scusami Vicius, ripensandoci, dato che non so quando verranno effettivamente finiti gli altri task, e dato che nei prossimi giorni non ho molto tempo libero, potresti togliere la mia prenotazione, eventualmente, se non c'è nessuno che si è prenotato per quando verrò finito il 3.2.3 e io sono libero da altri impegni, me ne occupo io, ok?
Non ti preoccupare. Lo assegno a fpitt.
ciao ;)
Miii che testa dura. :muro:
Vai di revert :fagiano:
71104: non esistono commit non definitivi...i commit devono essere tutti definitivi... Usiamo un paradigma evolutivo, non involutivo :sofico:
Miii che testa dura. :muro: Prima di fare il commit e cominciare a scrivere codice vogliamo vedere test. CHEEEEEEEE????? e quando mai nella storia precedente ho fatto così... O_O'
ma nella storia precedente non mi avete detto nulla in proposito... O_o'
cmq ecco i test:
public class TestPlayerGrid extends TestCase
{
private Config config;
private Bounds bounds;
private int rows;
private int cols;
private PlayerGrid pg;
public void setUp()
{
config = Config.createForTesting();
bounds = new Bounds(40, 40, 256, 448, config);
pg = new PlayerGrid(config, bounds);
rows = pg.getRows();
cols = pg.getColumns();
}
public void testDimensions()
{
assertEquals(pg.getRows(), rows);
assertEquals(pg.getColumns(), cols);
assertEquals(rows, config.getIntProperty("rows"));
assertEquals(cols, config.getIntProperty("columns"));
try
{
pg.getAt(0, 0);
pg.getAt(rows - 1, 0);
pg.getAt(0, cols - 1);
pg.getAt(rows - 1, cols - 1);
}
catch(IllegalArgumentException e)
{
fail("legal arguments rejected");
}
}
private void retrievalTest(boolean empty)
{
for (int y = 0; y < rows; y++)
{
for (int x = 0; x < cols; x++)
{
if (empty)
{
assertNull(pg.getAt(y, x));
}
else
{
assertNotNull(pg.getAt(y, x));
}
}
}
}
private void insertionTest()
{
for (int y = 0; y < rows; y++)
{
for (int x = 0; x < cols; x++)
{
assertTrue(pg.addGem(y, x, "diamond"));
assertFalse(pg.addGem(y, x, "diamond"));
}
}
}
private void removalTest()
{
for (int y = 0; y < rows; y++)
{
for (int x = 0; x < cols; x++)
{
assertTrue(pg.removeGem(y, x));
assertFalse(pg.removeGem(y, x));
}
}
}
public void testCells()
{
retrievalTest(true);
insertionTest();
retrievalTest(false);
removalTest();
}
public void testAssignBounds()
{
pg.addGem(0, 0, "diamond");
assertSame(pg.getAt(0, 0).getBounds(), bounds);
pg.removeGem(0, 0);
}
public void testDraw()
{
MockEngine engine = new MockEngine();
for (int y = 0; y < rows; y++)
{
for (int x = 0; x < cols; x++)
{
pg.addGem(y, x, "diamond");
}
}
pg.draw(engine);
assertEquals(engine.getNumberOfQuadsDrawn(), rows * cols);
for (int y = 0; y < rows; y++)
{
for (int x = 0; x < cols; x++)
{
pg.removeGem(y, x);
}
}
}
}
vediamo se riesci a dirmi quali sono i test che ho fatto prima e quali quelli che ho fatto dopo :Prrr:
Mi prenoto per il 3.2.1.
Tempo stimato: 1 giorno.
In realtà ci metterò cinque minuti, devo solo separare un layer da un psd e upparlo sul mio server, ma facciamo finta che la situazione sia più complicata :P
EDIT: Fatto.
http://lnx.rc6.it/diamonds/tasks/grid.png
L'immagine occupa 4K ed ha un'opacità del 73%.
Mi prenoto per il 3.2.1.
Tempo stimato: 1 giorno.
In realtà ci metterò cinque minuti, devo solo separare un layer da un psd e upparlo sul mio server, ma facciamo finta che la situazione sia più complicata :P
EDIT: Fatto.
http://lnx.rc6.it/diamonds/tasks/grid.png
L'immagine occupa 4K ed ha un'opacità del 73%.
Vic, aggiungi un task per disegnare sprite trasparenti per favore. Oppure raffaele te ne occupi tu come aggiunta al tuo task?
CHEEEEEEEE????? e quando mai nella storia precedente ho fatto così... O_O'
Resetta tutto, lo facciamo stasera io e te in TDD sul forum e poi facciamo il refactoring di ieri. Te lo faccio scrivere nella meta' del codice.
Vic, aggiungi un task per disegnare sprite trasparenti per favore. Oppure raffaele te ne occupi tu come aggiunta al tuo task?
C'è il canale alpha nella png non dovrebbe bastare quello per creare la trasparenza nella texture?
ciao ;)
C'è il canale alpha nella png non dovrebbe bastare quello per creare la trasparenza nella texture?
ciao ;)
Bisogna comunicare alla GPU che lo si vuole usare per fare alpha blending. In termini tecnici bisogna settare un paio di stati, nulla di complesso.
C'è il canale alpha nella png non dovrebbe bastare quello per creare la trasparenza nella texture? no, a quanto pare non basta: gli sprite che disegnamo non hanno le trasparenze, bisogna abilitare il canale alpha in OpenGL (non so come si faccia per le textures).
Ok. Allora aggiungo un settimo Task alla lista.
ciao ;)
Ok. Allora aggiungo un settimo Task alla lista.
ciao ;)
Non c'e' bisogno, e' davvero semplice (e non puo' essere testato). Aggiungilo semplicemente al task di Raffaele.
Gammaglobulino
25-10-2005, 13:36
Di seguito i test che vorrei implementare per la classe PlayAreaBackground:
Abstract:
La classe si deve occupare di disegnare la texture proveniente dal task 3.1.2 nell'area di gioco.
Test da effettuare:
1. la texture esiste e le dimensioni sono quelle specificate
2. MockDisplay esiste correttamente inizializzato
3. le coordinate di destinazione del metodo Draw() siano valide
Approvate?
Me la vedo io nel mio task per quei due stati, non è un problema.
Di seguito i test che vorrei implementare per la classe PlayAreaBackground:
Abstract:
La classe si deve occupare di disegnare la texture proveniente dal task 3.1.2 nell'area di gioco.
Test da effettuare:
1. la texture esiste e le dimensioni sono quelle specificate
2. MockDisplay esiste correttamente inizializzato
3. le coordinate di destinazione del metodo Draw() siano valide
Approvate?
Bring it on! :)
Me la vedo io nel mio task per quei due stati, non è un problema.
Come vuoi. Ti faccio un aggiunta al tuo task allora cosi non ti scordi :D
ciao ;)
Come vuoi. Ti faccio un aggiunta al tuo task allora cosi non ti scordi :D
ciao ;)
In realtà questa funzionalità è già implementata in enable() di Texture. La implementai già io tempo fa. In ogni caso magari è possibile aggiungere un test al riguardo utilizzando una texture con canale alpha di trasparenza ed una senza canale alpha per verificare che tutto sia effettivamente riconosciuto.
Ragazzi, mancano due giorni alla chiusura del Ciclo 3 e manca ancora un task da assegnare. Non fate i timidi e prenotatevi.
io devo ancora finire il mio, comunque vorrei avere chiara una cosa: una volta che ci si è prenotati per un task, che vuol dire che bisogna presentare prima i test, poi attenedere la conferma e poi procedere? bisogna postare proprio il codice dei test (che inizialmente non compilerà) oppure bisogna solo scrivere una test list?
io devo ancora finire il mio, comunque vorrei avere chiara una cosa: una volta che ci si è prenotati per un task, che vuol dire che bisogna presentare prima i test, poi attenedere la conferma e poi procedere? bisogna postare proprio il codice dei test (che inizialmente non compilerà) oppure bisogna solo scrivere una test list?
Io preferirei vedere il codice di almeno alcuni dei test.
ciao ;)
Io preferirei vedere il codice di almeno alcuni dei test.
ciao ;)
Diciamo che la test list e' obbligatoria. E poi il codice di almeno uno dei test piu' significativi, quello che possiamo chiamare "Acceptance test" e ci dice quando il task e' effettivamente completato.
il mio task ora dovrebbe essere completo, salvo qualche refactoring o qualche eventuale dimenticanza; ho fatto il commit.
se nessuno si prenota per il task rimanente posso provare a farlo io, passo passo e test driven; sarà lungo perché vanno cambiate un bel po' di cose, e se non si procede alla mia solita maniera piaciona (:D) ci vuole un bel po' di tempo, diciamo 2 giorni.
Se fek ha voglia lo potremmo fare in pair programming io e lui domani sera...
Se fek ha voglia lo potremmo fare in pair programming io e lui domani sera...
Vicius, puoi farlo tu con cionci domani sera? Io sono out la sera fino a lunedi'.
IMPORTANTE.
Se i task assegnati all'inizio della settimana non sono completati entro stasera vengono riassegnati. Domani sera si chiude il Ciclo e chi c'e' c'e'. E se la Storia non si completa, salta alla settima prossima e rallenta lo sviluppo. Quindi sotto! :)
Azz...stasera non sono a casa... Se volete lo rpendo io (anche senza fare pair programming), ma come termine devo dare martedì sera... Nel fine settimana non ci posso lavorare...
Se i task assegnati all'inizio della settimana non sono completati entro stasera vengono riassegnati. Domani sera si chiude il Ciclo e chi c'e' c'e'. E se la Storia non si completa, salta alla settima prossima e rallenta lo sviluppo. Quindi sotto! :)
Quindi ignora il mio messaggio precedente...e mi prenoto per farlo al prossimo Ciclo... Se me lo date per buono ci comincio già a lavorare...
Quindi ignora il mio messaggio precedente...e mi prenoto per farlo al prossimo Ciclo... Se me lo date per buono ci comincio già a lavorare...
Preferirei che questa Storia si chiudesse venerdi' cosi' possiamo affrontare due Storie il Ciclo prossimo e non una sola oltre a chiudere questa.
Un piccolo sforzetto? :)
sorry, ma io potrei non fare in tempo per stasera... (purtroppo io le lezioni le ho di pomeriggio e oggi torno a casa alle 7:30 O_o')
Stasera non sono a casa... Forse mi ci metto un po' oggi pomeriggio o domani, ma data la complessità del task non so riesco...
Si fa così...io ci lavoro un po'...poi ti so dire se e come..
Riguardo alla collissione, si gestisce solo con i bordi della griglia ? Non ancora con eventuali altri diamanti, vero ?
Fek per favore segnati che anche io ho completato il mio task... in dieci minuti :sofico:
Solo due task su sei completati. Su gente che fine avete fatto ?
ciao ;)
Altra cosa... Anche la reazione all'input deve passare da Gem a PlayGrid ?
Che ne dite di questi test ?
private Point origin;
private Grid grid;
private Gem gem;
private MockEngine engine;
private int gridColumns;
private int gridRows;
public void setUp()
{
gridColumns = 8;
gridRows = 14;
origin = new Point(40, 40);
grid = new Grid(gridRows, gridColumns);
grid.setOrigin(origin.x(), origin.y());
gem = Gem.createForTesting();
engine = MockEngine.createForTesting(800, 600);
}
public void testGravity()
{
grid.setGravity(gem.getGemSize());
grid.insertGem(0, 4, gem);
grid.draw(engine);
assertTrue(grid.isGemAt(1, 4));
assertEquals(grid.getGemAt(1, 4), gem);
grid.draw(engine);
assertFalse(grid.isGemAt(1, 4));
assertTrue(grid.isGemAt(2, 4));
assertEquals(grid.getGemAt(2, 4), gem);
}
public void testBottomCollision()
{
grid.setGravity(gem.getGemSize());
grid.insertGem(gridRows-2, 4, gem);
grid.draw(engine);
assertTrue(grid.isGemCollided());
assertTrue(gem.isDropped());
assertEquals(grid.getGemAt(gridRows-1, 4), gem);
grid.draw();
assertFalse(grid.isGemCollided());
assertEquals(grid.getGemAt(gridRows-1, 4), gem);
}
}
Config nella classe Bounds cosa ci fa ?
Che ne dite di questi test ? anziché assertEquals per confrontare oggetti usa assertSame ;)
Config nella classe Bounds cosa ci fa ? niente in effetti :D retaggi :fiufiu:
niente in effetti :D retaggi :fiufiu: aspe no, che sto a di, serve eccome!! serve in checkValue
Altra cosa... Anche la reazione all'input deve passare da Gem a PlayGrid ?
Si'.
Collisioni solo coi bordi.
aspe no, che sto a di, serve eccome!! serve in checkValue certo però che si potrebbe benissimo eliminare... il codice sarebbe più semplice... non vedo perché mai limitare gli sprites all'interno dello schermo, se possono uscire fuori sono più flessibili ;) solo che VICIUS ha voluto fare di testa sua :muro:
niente in effetti :D retaggi :fiufiu:
Hai voglia di provare a toglierlo ?
Hai voglia di provare a toglierlo ?a toglierlo non ci vuole niente, non serve lavorare coi test, basta semplicemente controllare che dopo la rimozione i test passino ancora tutti; comunque prima di toglierlo aspetto altre conferme: VICIUS voleva metterci quel controllo a tutti i costi.
e poi gente vi ricordo che manca ancora un refactoring importante: Bounds deve usare Rectangle O.o'
e bisogna farlo prima di iniziare una nuova storia secondo me, prima lo si fa e meno cose bisogna cambiare.
e poi gente vi ricordo che manca ancora un refactoring importante: Bounds deve usare Rectangle O.o'
e bisogna farlo prima di iniziare una nuova storia secondo me, prima lo si fa e meno cose bisogna cambiare.
Fermate tutto su Bounds ora. Se Vicius ha messo il controllo ha le sue ragioni. Per favore lasciate stare questo refactoring e concentratevi sugli altri task che abbiamo da concludere.
IMPORTANTE.
Se i task assegnati all'inizio della settimana non sono completati entro stasera vengono riassegnati. Domani sera si chiude il Ciclo e chi c'e' c'e'. E se la Storia non si completa, salta alla settima prossima e rallenta lo sviluppo. Quindi sotto! :)
Si però fek bisogna chiarire che io ho scritto due giorni a partire dal completamento del task 3.2.3 che solo oggi vedo "completato", quindi io ci posso fare poco.
Si può fare un passaggio di parametri per riferimento in Java ?
Inoltre se io volessi fare una cosa del genere:
Gem grid[][] = new Gem[X][Y];
Gem gridTemp[][] = new Gem[X][Y];
grid = gridTemp;
Avviene un'assegnamento membro a membro ?
La collisione va testata con tutti i bordi o solo con quello in fondo ?
Il movimento laterale viene comunque limitato dal Bounds di Gem...
Si però fek bisogna chiarire che io ho scritto due giorni a partire dal completamento del task 3.2.3 che solo oggi vedo "completato", quindi io ci posso fare poco.
C'e' anche un -3 che sta ad indicare l'inizio del task spostato in avanti :)
Ragazzi, quei numeri servono a me, non sono un'indice di prestazioni individuale. Non dovete fare a gara per abbassarlo magari compromettendo la code base. Ignorateli.
La collisione va testata con tutti i bordi o solo con quello in fondo ?
Il movimento laterale viene comunque limitato dal Bounds di Gem...
Solo col fondo, perche' il movimento laterale e' limitato da un'altro task. Comunque si sta creando un po' di confusione fra uno Sprite "libero" ed uno "agganciato" alla Griglia. Vedo se riesco a chiarificare la situazione in questa Storia o nella prossima.
Si può fare un passaggio di parametri per riferimento in Java ?
Inoltre se io volessi fare una cosa del genere:
Gem grid[][] = new Gem[X][Y];
Gem gridTemp[][] = new Gem[X][Y];
grid = gridTemp;
Avviene un'assegnamento membro a membro ?
C'e' solo un cambio di label qui, nessuna copia di dati.
C'e' anche un -3 che sta ad indicare l'inizio del task spostato in avanti :)
Ragazzi, quei numeri servono a me, non sono un'indice di prestazioni individuale. Non dovete fare a gara per abbassarlo magari compromettendo la code base. Ignorateli.
No ma guarda che di quei numeri mi interessa poco. Il discorso è che dire "un ciclo deve essere completato in una settimana" e poi magari un task è dipendente dal completamento di un altro che a sua volta viene concluso due giorni prima della scandenza.... beh... Insomma le cose sono due: o il completamento entro una settimana è un'indicazione flessibile e "di massima", oppure ci si deve sforzare di organizzare i cicli con task indipendenti tra loro.
No ma guarda che di quei numeri mi interessa poco. Il discorso è che dire "un ciclo deve essere completato in una settimana" e poi magari un task è dipendente dal completamento di un altro che a sua volta viene concluso due giorni prima della scandenza.... beh... Insomma le cose sono due: o il completamento entro una settimana è un'indicazione flessibile e "di massima", oppure ci si deve sforzare di organizzare i cicli con task indipendenti tra loro.
Per prima cosa ricordiamoci che e' un gioco di squadra e se non si riesce a completare una Storia entro la fine del Ciclo, allora la colpa e' di tutti, o al massimo e' solo mia. Ora che sappiamo di chi e' la colpa, possiamo capire come fare a concludere con piu' regolarita' i Cicli, perche' questo, se salta', e' il secondo consecutivo.
Una prima soluzione e' di ridurre il numero di task per adattarsi meglio alla Velocita' del team (a questo mi servono quei numeri).
Una seconda soluzione e' di cercare di rendere i task il piu' possibile indipendenti l'uno dall'altro, ma questa soluzione e' attuabile fino ad un certo punto: ci sara' sempre e comunque dipendenza fino ad una certa misura. E' inevitabile.
Da parte vostra, quando vi prenotate per un task, iniziatelo possibilmente in giornata o, se ha dipendenze, appena e' concluso il task da cui dipende. Ancora meglio se discutete con chi ha il task di dipendenza per concordare una strategia comune.
Quello che non voglio vedere e' post del tipo "Lo faccio in 30 minuti" e al giovedi' ancora non si vedono neppure i test. Questo e' male, perche' blocca tutto il team e io o vicious dobbiamo riassegnare il task.
^TiGeRShArK^
27-10-2005, 14:47
ehm... io x ora sono out xkè domani sera parto e devo ancora fare le valigie e sistemare un pò la casa... :muro:
Ho messo la funzione che reagisce all'input...però c'è un problema nel gioco se premo un tasto il diamante si muove nella direzione giusta, ma fino al limite del bound...
Queste test però passa tranquillamente:
public void testGemsMoving()
{
grid.insertGem(0, 3, gem);
grid.moveAllGems(xStep, 0);
assertSame(grid.getGemAt(0, 4), gem);
grid.draw(engine);
assertSame(grid.getGemAt(1, 4), gem);
grid.moveAllGems(xStep * 10, yStep);
assertSame(grid.getGemAt(2, 7), gem);
grid.draw(engine);
assertSame(grid.getGemAt(3, 7), gem);
Gem otherGem = new Gem("diamond", bounds);
grid.insertGem(0, 1, otherGem);
grid.moveAllGems(-xStep * 2, yStep);
grid.draw(engine);
assertSame(grid.getGemAt(2, 0), otherGem);
}
Il metodo che reagisce all'input è questo:
public void reactToInput(Input input)
{
if(input.isKeyDown())
{
moveAllGems(0, yStep);
}
if(input.isKeyLeft())
{
moveAllGems(-xStep, 0);
}
if(input.isKeyRight())
{
moveAllGems(xStep, 0);
}
}
Ora non capisco...forse nell'input rimane settato il tasto che non risulta mai rialzato...
Sembra sempre di più quel problema...visto che se debuggo mettendo la gravità nel gioco a zero, viene processato comunque una volta sola il tasto...e quando viene processato lo spostamento avviene regolarmente...
A vedere il test sicuramente e' un problema dal lato dell'input e purtroppo questo non puo' essere testato, bisogna procedere per vie manuali.
Prova ad aggiungere magari qualche output in console per verificare che il messaggio di keyup sia correttamente intercettato e passato alla game logic.
Purtroppo in ufficio non ho accesso al repository. Vicius, puoi controllare tu per favore?
Sembra sempre di più quel problema...visto che se debuggo mettendo la gravità nel gioco a zero, viene processato comunque una volta sola il tasto...e quando viene processato lo spostamento avviene regolarmente...
Ok, quindi NON e' un problema dal lato input? Il messaggio di keyup viene intercettato regolarmente?
Devo allora fare il commit perchè altrimenti VICIUS non può fare niente...
Ok, quindi NON e' un problema dal lato input? Il messaggio di keyup viene intercettato regolarmente?
A me sembra comunque un problema dal lato input... Interrompendo l'esecuzione con un breakpoint in reactToInput lo spostamento funziona correttamente... Sembra che reactInput venga richiamato troppe volte al momento che avviene il keydown... Ora faccio un prova mettendo uno static in reactInput per contare quante volte ci entra...
Mi risulta che reactToInput con una sola pressione del tasto Left venga chiamato 45 volte (con il tasto che risulta premuto)... Quindi il problema è quello... Non capisco come mai funzionava prima... Se non sbaglio avevamo già avuto questo problema... Come era stato risolto ?
Ma io faccio il commit ? Si cerca dopo di scovare l'errore ? Dal mio punto di vista il codice che ho scritto è corretto (almeno per quanto riportano i test)...
Allora ho capito... La differenza sostanziale rispetto a prima è che ora mi sposto istantaneamente da una casella all'altra in orizzontale e verticale, mentre prima ci si spostava di pochi decimi di pixel...quindi anche se ci entrava 45 volte lo spostamento era comunque minimo...
La strada dovrebbe essere quella di:
- mettere una funzione clear in Input che mette lo stato dei tasti premuti come non valido
- riilevare il keyup e rendere nuovamente lo stato di questi tasti come valido
- controindicazioni: non si può tenere sempre premuto un tasto per continuare a spostarsi in una direzione
Altra strada:
- rendere nuovamente attivo il tasto dopo un intervallo di tempo (questo sarebbe ottimo per continuare a spostarsi senza alzare il tasto)
Ho messo una sleep in Game per rendersi conto per bene del problema...
Se mi date il via io faccio il commit...
Ah...ho messo anche un piccolo controllo secondo il quale gli input smettono di essere processati quando la gemam arriva sul fondo...
Ant mi da la Build verde quindi faccio il commit...
PS: le altre classi sono tutte rimaste identiche...esclusa la gravità in Gem, ma il controlle delle collisioni c'è sempre, così come tutti i test...
Attetnzione !!! C'è casino nel repository !!! I file sorgenti sono andati a finire in bin e non sono stato io !!!
Attetnzione !!! C'è casino nel repository !!! I file sorgenti sono andati a finire in bin e non sono stato io !!! questo problema è "olderrimo", ormai si è detto da secoli che bisogna fare il commit solo della cartella src... chi è stato stavolta ??? :D dai su, che non vi facciamo niente... :D
comunque ragazzi proporrei di iniziare a prendere l'abitudine di usare i comandi "get lock" e "release lock" del repository (ad intuito penso di aver capito cosa sono, anche se il manuale non l'ho letto :D cmq andrebbero sperimentati, si evitano problemi di sincronizzazione come quello che abbiamo avuto io e fek l'altro ieri).
Attetnzione !!! C'è casino nel repository !!! I file sorgenti sono andati a finire in bin e non sono stato io !!!
E' tutto in ordine adesso?
Se vuoi lo metto in ordine...ma i cambiamenti che ha fatto quella persona andranno persi...
Sto facendo un casino che la emtà basta...cancellandoli da bin me li ha cancellati anche da source...tanto avevo fatto un backup...
Sto facendo un casino che la emtà basta...cancellandoli da bin me li ha cancellati anche da source...tanto avevo fatto un backup...
Ouch. Ci dici quando il repository e' di nuovo in ordine?
Ricorda che puoi sempre tornare ad una revision precedente.
Ok...ora è in ordine...
fek: dai una controllatina a quella cosa dei tasti...
Ottimo! Via libera con 3.2.6 e poi abbiamo finito con un giorno d'anticipo e abbiamo tre giorni per fare solo refactoring e proporre la build di fine ciclo a Jocchan :D
(le strigliate funzionano sempre :p)
C'è ancora casino...mi sta facendo impazzire questo repositori... Ora ci aggiungo l'ultima volta i miei file, altrimenti faccio un revert...
quando il repository è ok, avvertici cionci, che io e fpitt ci apprestiamo a fare refactoring del tuo task, secondo una nuova interpretazione...
Vai...è pronto...
Però ditemi i refactoring che fate...voglio vedere...
il refactoring lo facciamo in TDD, su una discussione che sto per aprire, anzi, se vuoi partecipare..
Dopo cena non ci sono...vado a giocare a D&D...
Fermo restando che come da accordo con fek il mio task dovrebbe essere espresso meglio e cioè io dovrei consentire l'inserimento della gemma solo dalla testa della griglia in una colonna il che non significa consentirlo SOLO in quel caso.
I test a cui avevo pensato sono una riproposizione in chiave dell'inserimento in colonna di alcuni test già sviluppati.
public void testInsertionIntoColumn()
{
assertFalse("there's a Gem at (0,1) before insertion", grid.isGemAt(0, 1));
grid.insertGemIntoColumn(1, gem);
assertTrue("insertion failed", grid.isGemAt(0, 1));
}
public void testTwoInsertionsIntoColumn()
{
grid.insertGemIntoColumn(1, gem);
assertFalse("there's a Gem at (0,1) before insertion", grid.isGemAt(3, 0));
grid.insertGemIntoColumn(2, gem);
assertTrue("insertion failed at (0,1) ", grid.isGemAt(0, 2));
}
public void testRedundantInsertionIntoColumn()
{
try
{
grid.insertGemIntoColumn(1, gem);
grid.insertGemIntoColumn(1, gem);
}
catch (IllegalArgumentException e)
{
return;
}
fail("Double insertion at same column should not be allowed");
}
Inoltre per il discorso dell'alpha channel:
public void testTextureWithAlpha()
{
Texture texture = new Texture("diamond");
assertEquals("texture has no alpha channel", GL11.GL_RGBA, texture.getFormat());
}
public void testTextureWithoutAlpha()
{
Texture texture = new Texture("diamondnoalpha");
assertEquals("texture has alpha channel", GL11.GL_RGB, texture.getFormat());
}
I test per il tuo task vanno benissimo, passa pure a implementarli.
Io non metterei i test su OpenGL perche' le librerie non si testano: il loro contratto ci garantisce il funzionamento.
Tutto ok, il task è completo.
Anche 3.2.5 e' completo. Manca 3.2.6 e abbiamo finito.
Anche 3.2.5 e' completo. Manca 3.2.6 e abbiamo finito.
C'è da controllare perchè la texture del task 3.2.2 viene disegnata nel posto sbagliato. E anche perchè la gemma non scende piu da sola.
ciao ;)
Scusate...io non sono d'accordo su come si sta svolgendo il task 3.2.6...
Non capisco perchè se non vi tornava qualcosa di come l'ho fatto non me l'avete detto a me, ma avete inserito altra gente a farlo...
In pratica il refactoring di fek ha tolto tutto quello che avevo fatto quindi il task 3.2.6 sta per essere fatto dall'inzio... Non sono arrabbiato perchè è stato tolto tutto, ma perchè non potevo farle io le correzioni ? E soprattutto perchè non mi è stato detto niente ?
Se nella griglia ci può essere un solo diamante, perchè ne viene già disegnato più di uno ?
Ho postato tutti i test qui sul thread, perchè non mi è stato detto subito che i test non andavano bene ?
Scusate...io non sono d'accordo su come si sta svolgendo il task 3.2.6...
Non capisco perchè se non vi tornava qualcosa di come l'ho fatto non me l'avete detto a me, ma avete inserito altra gente a farlo...
In pratica il refactoring di fek ha tolto tutto quello che avevo fatto quindi il task 3.2.6 sta per essere fatto dall'inzio... Non sono arrabbiato perchè è stato tolto tutto, ma perchè non potevo farle io le correzioni ? E soprattutto perchè non mi è stato detto niente ?
Se nella griglia ci può essere un solo diamante, perchè ne viene già disegnato più di uno ?
Ho postato tutti i test qui sul thread, perchè non mi è stato detto subito che i test non andavano bene ?
Cionci, e' stata una decisione mia ed ho fatto io il refactoring. Purtroppo sei uscito appena ho iniziato il refactoring, per questo non ho potuto dirti nulla prima di finirlo.
Non ti e' stato detto subito che non andava bene perche' ho impiegato del tempo per capire il codice e il test, quindi ho capito solo dopo che non era il task da implementare. C'e' stato un difetto di comunicazione, ma non potevo lasciare la code base con un task non richiesto, quindi ho iniziato e finito il refactoring tutto ieri sera e poi ho postato il risultato.
E' stata solo una mia decisione. Il restante task e' partito dal mio refactoring.
cionci, come ha già detto fek in passato, evitiamo tutti quanti di sviluppare attaccamenti "sentimentali" e roba del genere al nostro codice: quello che ci interessa è la qualità finale del programma, se qualcuno ritiene opportuno fare refactoring basta che proceda passo passo con i test opportuni (vedendoli fallire e poi risolvendoli), e chi ha scritto il codice che è stato poi sostituito non se la deve prendere a male; non arrabbiamoci per i "soprusi", ce ne saranno e saranno tutti giustificati perché è un lavoro di squadra (anche il mio codice ne ha subiti, ma ho capito che non dovevo prendermela). a ogni modo ricorda che qualsiasi stesura di codice non è mai inutile perché costituisce sempre e comunque esperienza per tutta la squadra: adesso il task 3.2.6 è fatto in un certo modo, e per arrivarci abbiamo dovuto leggere il tuo codice per capire che non andava bene; il tuo codice era in lista d'attesa, e sebbene sia stato cancellato, è servito anche quello. ;)
inoltre ricorda che le decisioni del Coach sono sacrosante: se lui decide una cosa inutile discuterne, e non perché fek abbia più esperienza di noi (be' magari anche per quello :stordita: ), ma perché lui è stato scelto come Coach, cioè come quella persona che decide al disopra di tutti e chi non è d'accordo amen, sarà d'accordo col tempo. questa figura è assolutamente indispensabile perché accelera i tempi di sviluppo di molto! ;)
cionci, come ha già detto fek in passato, evitiamo tutti quanti di sviluppare attaccamenti "sentimentali" e roba del genere al nostro codice: quello che ci interessa è la qualità finale del programma, se qualcuno ritiene opportuno fare refactoring basta che proceda passo passo con i test opportuni (vedendoli fallire e poi risolvendoli), e chi ha scritto il codice che è stato poi sostituito non se la deve prendere a male; non arrabbiamoci per i "soprusi", ce ne saranno e saranno tutti giustificati perché è un lavoro di squadra (anche il mio codice ne ha subiti, ma ho capito che non dovevo prendermela). a ogni modo ricorda che qualsiasi stesura di codice non è mai inutile perché costituisce sempre e comunque esperienza per tutta la squadra: adesso il task 3.2.6 è fatto in un certo modo, e per arrivarci abbiamo dovuto leggere il tuo codice per capire che non andava bene; il tuo codice era in lista d'attesa, e sebbene sia stato cancellato, è servito anche quello. ;)
fek ma che hai fatto a quest'uomo? Un lavaggio del cervello? :eek: :D
fek ma che hai fatto a quest'uomo? Un lavaggio del cervello? :eek: :D non mi chiamare uomo, mi fai sembrare veccho! :Prrr:
sono un ragazzo :Prrr:
fek ma che hai fatto a quest'uomo? Un lavaggio del cervello? :eek: :D
Lavaggio del cervello o meno, ha afferrato completamente la filosofia che stiamo seguendo per lo sviluppo. Il che è ottimo ;)
fek ma che hai fatto a quest'uomo? Un lavaggio del cervello? :eek: :D
Ma se lo ho avuto a disposizione solo per un paio di orette :D
^TiGeRShArK^
29-10-2005, 19:12
Ma se lo ho avuto a disposizione solo per un paio di orette :D
minkia! :eek:
non oso pensare in un paio di giorni come diventava! :sofico:
cdimauro
30-10-2005, 09:10
Ma se lo ho avuto a disposizione solo per un paio di orette :D
E cosa c'hai fatto? :asd: :D :p
cionci, come ha già detto fek in passato, evitiamo tutti quanti di sviluppare attaccamenti "sentimentali" e roba del genere al nostro codice: quello che ci interessa è la qualità finale del programma, se qualcuno ritiene opportuno fare refactoring basta che proceda passo passo con i test opportuni (vedendoli fallire e poi risolvendoli), e chi ha scritto il codice che è stato poi sostituito non se la deve prendere a male; non arrabbiamoci per i "soprusi", ce ne saranno e saranno tutti giustificati perché è un lavoro di squadra (anche il mio codice ne ha subiti, ma ho capito che non dovevo prendermela). a ogni modo ricorda che qualsiasi stesura di codice non è mai inutile perché costituisce sempre e comunque esperienza per tutta la squadra: adesso il task 3.2.6 è fatto in un certo modo, e per arrivarci abbiamo dovuto leggere il tuo codice per capire che non andava bene; il tuo codice era in lista d'attesa, e sebbene sia stato cancellato, è servito anche quello. ;)
inoltre ricorda che le decisioni del Coach sono sacrosante: se lui decide una cosa inutile discuterne, e non perché fek abbia più esperienza di noi (be' magari anche per quello :stordita: ), ma perché lui è stato scelto come Coach, cioè come quella persona che decide al disopra di tutti e chi non è d'accordo amen, sarà d'accordo col tempo. questa figura è assolutamente indispensabile perché accelera i tempi di sviluppo di molto! ;)
Forse ancora non ci siamo capiti, non mi provoca dispiacere che il mio codice venga buttato...l'unica cosa che mi aspettavo è che mi dicesse: "Hai sbagliato qui, qui e qui... Vuoi fare il refactoring ?". Io avrei detto "Sì, volentieri"... Basta, solo quello... Bastava cestinare la parte del lavoro che andava sopra al task 3.2.5 e gli altri potevano continuare beatamente a lavorare sul task 3.2.5...visto che sia la gestione delle collisioni con il fondo che la gestione della gravità funzionavano perfettamente e sono state realizzate in maniera molto simile a come le ho realizzate io...
Forse ancora non ci siamo capiti, non mi provoca dispiacere che il mio codice venga buttato...l'unica cosa che mi aspettavo è che mi dicesse: "Hai sbagliato qui, qui e qui... Vuoi fare il refactoring ?". Io avrei detto "Sì, volentieri"... Basta, solo quello... ma se il refactoring lo voleva fare fek mica puoi pretendere di farlo tu!! il tuo codice è stato cancellato senza preavviso perché non possiamo mica aspettare te (o me o qualsiasi altra persona) per andare avanti a sviluppare il progetto!
Bastava cestinare la parte del lavoro che andava sopra al task 3.2.5 e gli altri potevano continuare beatamente a lavorare sul task 3.2.5...visto che sia la gestione delle collisioni con il fondo che la gestione della gravità funzionavano perfettamente e sono state realizzate in maniera molto simile a come le ho realizzate io... in tal caso allora considera che anche il task 3.2.3 (il mio, quello della classe Grid) è stato realizzato in maniera molto simile a come l'avevo fatto io (perlomeno l'implementazione) ma la differenza è stata semplicemente nel modo di lavorare: io avevo lavorato senza molta esperienza di TDD e in un modo che andava un po' "controcorrente", cioè non era ben uniformato al resto della squadra e soprattutto a quello di fek; fek invece mi ha fatto quasi arrivare alla forma pura del TDD, :D che in teoria ammette modifiche a una sola riga di codice ad ogni test :asd:
nel tuo caso invece, per quel poco che ho visto, tu hai sviluppato il tuo task in fretta e furia a causa del limite di tempo, forse con dei test non molto adatti, o forse con un'implementazione troppo complessa, fek invece l'ha rifatto sicuramente meglio di te ma non dal punto di vista della qualità del codice, bensì da quello della metdologia usata (penso che lui abbia più esperienza di te in TDD e comunque lui è quello che meglio di tutti sa uniformarsi alla metodologia che deve essere usata da tutto il team, che poi è la sua :D).
vuoi considerare tutto ciò un errore di fek nell'aver posto un limite di tempo? ok, è un errore di fek :) quando qualcosa è colpa di qualcuno è sempre colpa sua ;) solo che noi non dobbiamo dire è colpa di fek, dobbiamo evitare di bloccarci su queste cose, dobbiamo dire che è colpa di chet e andare avanti col progetto!! ;)
Discorso eccellente ;)
Non dobbiamo mai dimenticare che:
1. abbiamo delle scadenze per i singoli task
2. è un lavoro di squadra, non conta CHI faccia le cose ma solo che tutto venga fatto (possibilmente bene)
3. tutti possono intervenire sul lavoro di tutti, specialmente se chi lo aveva fatto non è disponibile (non dobbiamo rallentare i lavori per nessun motivo)
ma se il refactoring lo voleva fare fek mica puoi pretendere di farlo tu!! il tuo codice è stato cancellato senza preavviso perché non possiamo mica aspettare te (o me o qualsiasi altra persona) per andare avanti a sviluppare il progetto!
in tal caso allora considera che anche il task 3.2.3 (il mio, quello della classe Grid) è stato realizzato in maniera molto simile a come l'avevo fatto io (perlomeno l'implementazione) ma la differenza è stata semplicemente nel modo di lavorare: io avevo lavorato senza molta esperienza di TDD e in un modo che andava un po' "controcorrente", cioè non era ben uniformato al resto della squadra e soprattutto a quello di fek; fek invece mi ha fatto quasi arrivare alla forma pura del TDD, :D che in teoria ammette modifiche a una sola riga di codice ad ogni test :asd:
nel tuo caso invece, per quel poco che ho visto, tu hai sviluppato il tuo task in fretta e furia a causa del limite di tempo, forse con dei test non molto adatti, o forse con un'implementazione troppo complessa, fek invece l'ha rifatto sicuramente meglio di te ma non dal punto di vista della qualità del codice, bensì da quello della metdologia usata (penso che lui abbia più esperienza di te in TDD e comunque lui è quello che meglio di tutti sa uniformarsi alla metodologia che deve essere usata da tutto il team, che poi è la sua :D).
vuoi considerare tutto ciò un errore di fek nell'aver posto un limite di tempo? ok, è un errore di fek :) quando qualcosa è colpa di qualcuno è sempre colpa sua ;) solo che noi non dobbiamo dire è colpa di fek, dobbiamo evitare di bloccarci su queste cose, dobbiamo dire che è colpa di chet e andare avanti col progetto!! ;)
Aiuto...ormai l'abbiamo perso... fek ma davvero, cosa gli hai fatto a questo ragazzo in quelle poche ore? :D
comunque quoto tutto ;)
ma se il refactoring lo voleva fare fek mica puoi pretendere di farlo tu!! il tuo codice è stato cancellato senza preavviso perché non possiamo mica aspettare te (o me o qualsiasi altra persona) per andare avanti a sviluppare il progetto!
71104 basta.
C'e' stata un'incomprensione fra me e cionci dovuta al fatto che avevo fretta di mettere gli altri in condizione di lavorare con quel refactoring. La fretta non e' mai buona consigliera e avrei potuto aspettare la mattina. Ho invece preso una decisione diversa.
In generale, comunque, il refactoring del codice non deve necessariamente essere fatto da chi lo ha scritto, ma e' buona norma che venga fatto anche da altri, di modo da poter condividere il codice fra tutti e avere piu' persone che conoscono e possono intervenire su piu' parti della code base. Idealmente tutti dovrebbero essere in grado di fare refactoring e intervenire su tutto il codice.
E' andata cosi', abbiamo imparato per il futuro e non commetteremo piu' gli stessi errori. Ora andiamo avanti col progetto.
Io e cionci per il prossimo ciclo faremo un task in Pair Programming per sdebitarmi :D
chiedo scusa, ma la griglia deve essere 8 x 12 o 8 x 14, perchè adesso il background è 8 x 12, ma il diamante scende di altre due righe (ovvero la Grid, per intenderci, è 8 x 14)
come non detto, appena corretto:D
Anche se con qualche problemuccio, abbiamo concluso questo Ciclo in tempo e Vicius sta preparando la nuova build per il Customer. Complimenti a tutti :)
Anche la code base continua ad essere decisamente pulita, date un'occhiata soprattutto a Grid.java, ad esempio, e datevi una pacca sulla spalla per il buon lavoro svolto.
Questo ciclo ha visto la nascita di qualche nuova clase e la triste dipartita di due classi che ci hanno accompagnato per un pezzo del viaggio; date un mesto addio a CoordSystem e Bounds, ci mancheranno, ma non ci servono piu'.
Una conseguenza dell'eliminazione di queste classi e' la necessita' di riscrivere alcuni test in termini di Grid e non piu' di Bounds:
- testSoundAfterCollision
- testHotSpot
Chi se ne occupa?
Un altro test ora sta dando dei problemi, ma non riesco a capire esattamente il suo significato:
- testRapidInputs
71104 te ne occupi tu?
Un altro test ora sta dando dei problemi, ma non riesco a capire esattamente il suo significato:
- testRapidInputs
71104 te ne occupi tu? il test l'avevo scritto io e serviva a testare la pressione contemporanea o quasi dei tasti freccia destro e sinistro; il test simula la pressione dei due tasti, fa reagire la griglia, simula il rilascio di uno dei due, e fa reagire la griglia due volte; se parte un'eccezione il test fallisce. il significato di tutto ciò era evidenziare il seguente comportamento errato (che prima si verificava): Grig.reactToInput alla prima chiamata spostava la gemma una volta a destra e una a sinistra, ma siccome dopo il primo spostamento la variabile cell non veniva aggiornata la gemma si sdoppiava; alla seconda chiamata di Grid.reactToInput uno dei due tasti freccia era rilasciato, perciò una delle due gemme continuava a muoversi in una delle due direzioni senza sdoppiarsi nuovamente; alla terza chiamata però la gemma continuando a muoversi doveva essere reinserita nella posizione dove già era presente la sua copia, e questo provocava la IllegalArgumentsException.
successivamente ho messo il test per correggere la doppia inserzione di una stessa gemma, perciò la seconda parte del test (cioè la seconda e terza chiamata di Grid.reactToInput) non serviva più per evidenziare il problema; adesso ho corretto il test che è diventato così:
public void testRapidInputs()
{
try
{
grid.insertGemIntoColumn(1, gem);
input.generateKey(KeyCode.vk_Right);
input.generateKey(KeyCode.vk_Left);
grid.reactToInput(input);
}
catch(Exception e)
{
fail("rapid input sequences make the program crash");
}
}
il codice, che è tutt'ora errato, fallisce questo test perché la gemma ancora si sdoppia (lo puoi verificare facilmente col debugger) a causa del fatto che cell non viene aggiornata.
resta da chiedersi: perché il codice è ancora errato? be', io l'avevo corretto, ma se il log non mente tu hai erroneamente tolto la correzione che avevo fatto... :D
ora l'ho rimessa e la gemma non si sdoppia più ;)
Una piccola precisazione su quanto fatto per eliminare CoordSystem. Essenzialmente ho spostato l'origine in OpenGL in alto a sinistra. Questo porta ad avere le coordinate Y che vanno da 0 a -height. Poiché noi non diamo coordinate negative e per evitare di fare l'orribile operazione di traduzione delle coordinate fatta da CoordSystem, ho effettuato a livello di Projection Matrix uno scaling a -1 dell'asse Y ed una traslazione sempre sull'asse Y. Inoltre, poiché così le texture venivano visualizzate a testa in giù ho effettuato a livello di texture matrix uno scaling -1 sempre sull'asse Y. Morale della favola abbiamo l'origine in alto a sinistra e tutte le operazioni di conversione prima fatte a mano, ora sono fatte dal processore grafico ;)
^TiGeRShArK^
30-10-2005, 21:31
bravo raffaele..
se capivo qualkosa di open gl l'avrei fatto io..
ma viste le mie scarse conoscenze ho dovuto creare CoordSystem...
ma cmq il grosso del lavoro ke ho fatto è stato riportare le coordinate con l'origine in alto a sinistra xkè erano tutte spostate..
meno male ke ora se la vede la skeda video a fare tutto! :D
Anche se con qualche problemuccio, abbiamo concluso questo Ciclo in tempo e Vicius sta preparando la nuova build per il Customer. Complimenti a tutti :)
Anche la code base continua ad essere decisamente pulita, date un'occhiata soprattutto a Grid.java, ad esempio, e datevi una pacca sulla spalla per il buon lavoro svolto.
Questo ciclo ha visto la nascita di qualche nuova clase e la triste dipartita di due classi che ci hanno accompagnato per un pezzo del viaggio; date un mesto addio a CoordSystem e Bounds, ci mancheranno, ma non ci servono piu'.
Una conseguenza dell'eliminazione di queste classi e' la necessita' di riscrivere alcuni test in termini di Grid e non piu' di Bounds:
- testSoundAfterCollision
- testHotSpot
Chi se ne occupa?
Un altro test ora sta dando dei problemi, ma non riesco a capire esattamente il suo significato:
- testRapidInputs
71104 te ne occupi tu?
Benissimo, non vedo l'ora di testare la build ;)
P.S.: Se mi passate la build entro stasera, avrò modo di testarla domani mattina (avrò per le mani un pc più decente di quello che sto usando ora).
Ci sono alcuni problemi in questo momento. Se vuoi ti metto il file zip da qualche parte anche con questi problemi.
ciao ;)
Ci sono alcuni problemi in questo momento. Se vuoi ti metto il file zip da qualche parte anche con questi problemi.
ciao ;)
Se puoi, per favore, intanto passami lo zip con i problemi... e se riusciamo a risolverli entro stasera, magari anche quello senza, così ho con certezza almeno una versione ;)
Ciao e grazie! :D
Ecco lo zip.
www.pigaz.org/static/Diamonds-20051030.zip
ciao ;)
ragazzi, il bug è veramente complesso da correggere perché le correzioni che ho provato a fare fanno fallire una marea di test; la prima cosa che bisognerebbe fare sarebbe spostare quell'orrido moveGem dal metodo draw al metodo reactToInput (ma chi è stato a gestire il movimento di gravità all'interno di draw??? O_o oltrettutto così la velocità di caduta raddoppia per non so quale motivo... infatti mi sembrava più veloce la gemma...); ho messo un TODO e ho aggiunto test (per ora commentato) che dobbiamo riuscire a far passare:
public void testDrop()
{
grid.insertGem(GRID_ROWS - 1, 0, gem);
grid.reactToInput(input);
assertTrue(gem.isDropped());
}
si trova in TestGridReactionToInput e per ora è commentato perché se lo decommento non passa.
PS: attualmente la build è verde.
BlueDragon
31-10-2005, 00:14
La gemma rimbalza sul fondo come una pallina gommosa :D
Dando una prima occhiata ho visto che nel metodo move di Gem, si fa affidamento sul metodo hasCollidedWithFloor di Sprite, che ritorna il valore della variabile omonima. Peccato che questa variabile venga fatta passare da false a true solo all'interno di un if che dipende dall'esistenza di bounds (bounds != null)...però nessuno inizializza mai bounds in Sprite..visto che ormai quella classe l'abbiamo abbandonata..:) Ora mi leggo un altro po' di codice (non avendo partecipato a questo giro sono rimasto un po' indietro) poi magari provo a scrivere qualche test e ad aggiustare qualcosa.. :)
BlueDragon
31-10-2005, 01:11
Ok, trovato il bug della pallina rimbalzante...praticamente la pallina veniva mossa con il test delle collisioni (moveGemWithCollisionControl) solo quando si spostava di riga (isGemOnNextRow) mentre in tutti gli altri casi veniva semplicemente mossa con move....Quindi aveva libertà di muoversi fino a metà della sua altezza sotto il bordo inferiore, poi scattava a true il controllo isGemOnNextRow e moveGemWithCollisionControl rimetteva tutto apposto...
Conosco il motivo del bug e so anche cosa cambiare nel codice (praticamente basta spostare un paio di chiamate o giù di lì), ora la cosa divertente sarà provare a fare tutto in TDD... :D
BlueDragon
31-10-2005, 02:06
Come amo il TDD!! :D
Qual'era il problema? Era che il diamante andava oltre il bordo inferiore.
Ok, testiamolo:
public void testBottomBound()
{
grid.insertGem(gridRows-1,1,gem1);
grid.draw(new MockEngine());
assertFalse("Gem moved beyond bottom bound!",(gem1.getY()+gem1.getHeight()>grid.getBounds().getBottom()));
}
Bene, il test fallisce. Risolviamolo nel modo più semplice possibile...
Come possiamo fare in modo che la gemma non si muova mai superando i bordi? Beh, c'è un bel metodo già bello scritto che la muove controllando eventuali collisioni con i bordi (moveGemWithCollisionControl)...usiamo quello....:D
private void moveGem(Gem gem)
{
Cell cell = findGemCell(gem);
if(isGemOnNextRow(gem, cell))
{
updateGemCell(gem, cell);
}
else
{
moveGemWithCollisionControl(gem,cell);
(anziché gem.move(0, gravity); che c'era prima)
}
}
Lanciamo la build...tutto apposto! Lanciamo il gioco...sì, effettivamente il diamande ora si adagia sul bordo senza andare oltre.
1 test scritto, 1 riga di codice modificata, 1 bug risolto. Ma quant'è comodo il TDD! ;)
Il server ora è giù, quindi non ho committato... Non so se domattina mi sveglio presto (probabilmente no ;)), se volete committare al posto mio quando torna su il server fate pure :)
il codice, che è tutt'ora errato, fallisce questo test perché la gemma ancora si sdoppia (lo puoi verificare facilmente col debugger) a causa del fatto che cell non viene aggiornata.
resta da chiedersi: perché il codice è ancora errato? be', io l'avevo corretto, ma se il log non mente tu hai erroneamente tolto la correzione che avevo fatto... :D
ora l'ho rimessa e la gemma non si sdoppia più ;)
Si', l'avevo tolta io :)
Se l'avessi fatto di proposito, non sarebbe stato cosi' chiaro quanto siano utili i test che si scrivono prima di correggere un bug. Immagina che cosa sarebbe accaduto se non ci fosse stato un test ed il bug introdotto nuovamente dal mio refactoring fosse sopravvissuto fino a che qualcuno non lo avesse manualmente testato (magari fra due cicli). Si sarebbe persa traccia del motivo della nuova introduzione del bug, e magari si sarebbero perse ore per capire nuovamente il problema col debugger.
Invece cosi' il tuo test e' fallto e l'hai corretto nuovamente in pochi secondi.
Ti serviva una dimostrazione pratica di quanto tempo fa risparmiare lo scrivere i test?
bravo raffaele..
se capivo qualkosa di open gl l'avrei fatto io..
ma viste le mie scarse conoscenze ho dovuto creare CoordSystem...
ma cmq il grosso del lavoro ke ho fatto è stato riportare le coordinate con l'origine in alto a sinistra xkè erano tutte spostate..
meno male ke ora se la vede la skeda video a fare tutto! :D
CoordSystem e' stato un passo utilissimo per capire il problema e trovare la soluzione ideale: abbiamo prima messo in piedi una bozza di soluzione, ha funzionato, per ora andava bene cosi'. Poi io e raffaele abbiamo avuto un altro problema, abbiamo ragionato su una possibile soluzione e abbiamo visto che spostare CoordSystem nella matrice di proiezione avrebbe risolto entrambi i problemi. Tipico esempio di design evolutivo.
E' interessante notare come tutto quello di cui parlavamo in linea teorica si sta passo dopo passo avverando sul nostro esempio pratico. E non sto pilotando l'esempio per far accadere le cose: il mio di ieri e' stato un genuino errore di refactoring, ad esempio.
ragazzi, il bug è veramente complesso da correggere perché le correzioni che ho provato a fare fanno fallire una marea di test; la prima cosa che bisognerebbe fare sarebbe spostare quell'orrido moveGem dal metodo draw al metodo reactToInput (ma chi è stato a gestire il movimento di gravità all'interno di draw??? O_o oltrettutto così la velocità di caduta raddoppia per non so quale motivo... infatti mi sembrava più veloce la gemma...); ho messo un TODO e ho aggiunto test (per ora commentato) che dobbiamo riuscire a far passare:
public void testDrop()
{
grid.insertGem(GRID_ROWS - 1, 0, gem);
grid.reactToInput(input);
assertTrue(gem.isDropped());
}
si trova in TestGridReactionToInput e per ora è commentato perché se lo decommento non passa.
PS: attualmente la build è verde.
Separa pure l'applicazione della gravita' dal metodo draw. Draw() si deve occupare solo di disegnare e idealmente dev'essere un metodo che non muti alcun comportamento osservabile (const in C++).
ragazzi, scusate ma oggi sono molto impegnato tutto il giorno, mi sa che non potrò dare retta a Diamonds, perciò se ne dovrà occupare qualcun altro ^^
oppure io domani.
BlueDragon
31-10-2005, 11:31
Ho committato i cambiamenti descritti sopra. Ora magari do un'occhiata alla questione draw&gravity :)
BlueDragon
31-10-2005, 12:28
Ok, ho spostato il moveGem da draw a reactToInput seguendo le annotazioni lasciate da 71104, cioé ho cancellato la riga moveGem da draw ed ho decommentato il seguente codice in reactToInput:
if(null != gemUnderControl)
{
moveGem(gemUnderControl);
}
Fallivano numerosi test in TestCellSideCollision perché in tutti quei test si supponeva che chiamando grid.draw(engine) si applicava la gravità. Li ho cambiati tutti mettendo al loro posto grid.reactToInput(input);
I test passano tutti, fra poco committo.
PS: A pensarci bene avrei dovuto prima guardare i test, modificarli per far richiedere la gravità in reactToInput anziché draw e poi modificare il codice... :sofico:
BlueDragon
31-10-2005, 13:53
Sì Jocchan, ho fatto il commit di quello che ho scritto sopra :)
Ed anche di quello che stavo per postare (vedi sotto), ad eccezione del refactoring aggiuntivo, che ora ri-controllo da capo prima di committare:
Ho decommentato il test proposto da 71104 in TestGridReactionToInput:
public void testDrop()
{
grid.insertGem(GRID_ROWS - 1, 0, gem);
grid.reactToInput(input);
assertTrue(gem.isDropped());
}
Per farlo passare ho deciso di rendere il metodo drop() di Gem pubblico, e di farlo chiamare a Grid quando la gemma tocca il fondo. In fondo (:D) è Grid che deve gestire le collisioni e quindi è Grid che deve informare Gem se è "dropped".
In Gem però la gestione del flag dropped è ancora delegata verso Sprite, che a sua volta decide le collisioni con il suo bound (che ormai non setta nessuno). E' una parte che andrebbe rimossa, ma io per adesso non l'ho fatto (immagino che richieda la modifica di alcuni test dalla gestione bounds alla gestione grid).
Una volta messo il gem.drop() quando si verifica la collisione, il test passa.
Ho aggiunto anche un if (!gem.isDropped()), altrimenti ripetiamo il drop ed il suono associato.
Avevamo già un test per la ripetizione dei suoni che avrei potuto usare? Sul momento ho aggiunto semplicemente l'if senza test (ahi, ahi!).
Refactoring aggiuntivo:
Sia la gemma che la grid emettono un suono.
Visto che non era specificato di passare i suoni da Gem a Grid, e che avere un suono per gemma potrebbe essere più flessibile che avere solo il suono di grid, ho deciso di eliminare la gestione suono di Grid (setCollisionSound e playSound).
Ho quindi modificato anche i due test che richiedevano l'emissione di un suono sul fondo e la non-emissione di suoni nel mezzo della griglia, semplicemente inserendo il suono nella gemma anziché nella griglia.
Ho tolto anche gemCollided ed il suo metodo isGemCollided da Grid. Non li usava nessuno (a parte draw che metteva gemCollided a false), quindi per adesso sono commentati...se poi continueremo a non usarli, li cancelleremo..altrimenti se servono ci basta scommentare :)
PS: Il refactoring aggiuntivo è ora committato :)
Ho tolto anche gemCollided ed il suo metodo isGemCollided da Grid. Non li usava nessuno (a parte draw che metteva gemCollided a false), quindi per adesso sono commentati...se poi continueremo a non usarli, li cancelleremo..altrimenti se servono ci basta scommentare :)
Non lasciare codice commentato, levalo pure, se ci dovesse servire e' sempre li' nel repository.
Io preferirei avere la gestione del suono e delle collisioni in Grid piuttosto che in Sprite.
BlueDragon
31-10-2005, 14:26
Non lasciare codice commentato, levalo pure, se ci dovesse servire e' sempre li' nel repository.
Io preferirei avere la gestione del suono e delle collisioni in Grid piuttosto che in Sprite.
Ooops..ho committato pochi secondi prima di leggere il tuo post :D
Cmq al momento la situazione è che le collisioni le gestisce Grid ma abbiamo una parte di codice ora superfluo che permetterebbe di gestirle anche da Sprite.
Per quanto riguarda il suono è Grid che dice a Gem di suonare visto che ne chiama il metodo drop(), però i suoni sono settati gemma per gemma anziché esserci un solo suono di Grid.
Ooops..ho committato pochi secondi prima di leggere il tuo post :D
Cmq al momento la situazione è che le collisioni le gestisce Grid ma abbiamo una parte di codice ora superfluo che permetterebbe di gestirle anche da Sprite.
Per quanto riguarda il suono è Grid che dice a Gem di suonare visto che ne chiama il metodo drop(), però i suoni sono settati gemma per gemma anziché esserci un solo suono di Grid.
Allora va bene. Elimina pure il codice che che gestisce le collisioni in Sprite e non ci serve piu'.
BlueDragon
31-10-2005, 15:41
Allora va bene. Elimina pure il codice che che gestisce le collisioni in Sprite e non ci serve piu'.
Refactoring time!
Gem:
Eliminato totalmente il metodo move, visto che dopo i refactoring non era altro che una copia del move di Sprite, che è automaticamente ereditato dalla classe.
Grid:
Eliminato tutto il codice che avevo lasciato commentato.
Sprite:
Eliminati bounds,hasCollidedWithFloor ed i loro accessori, nonché il test di Bounds nel metodo move, che è passato da circa 20 a 2 righe..;)
Nessun test modificato, build verde...era proprio codice superfluo :)
Commit eseguito.
ragazzi, scusate ma oggi sono molto impegnato tutto il giorno, mi sa che non potrò dare retta a Diamonds, perciò se ne dovrà occupare qualcun altro ^^
oppure io domani. come non detto: mi hanno dato buca :|
Si', l'avevo tolta io :)
Se l'avessi fatto di proposito, non sarebbe stato cosi' chiaro quanto siano utili i test che si scrivono prima di correggere un bug. Immagina che cosa sarebbe accaduto se non ci fosse stato un test ed il bug introdotto nuovamente dal mio refactoring fosse sopravvissuto fino a che qualcuno non lo avesse manualmente testato (magari fra due cicli). Si sarebbe persa traccia del motivo della nuova introduzione del bug, e magari si sarebbero perse ore per capire nuovamente il problema col debugger.
Invece cosi' il tuo test e' fallto e l'hai corretto nuovamente in pochi secondi.
Ti serviva una dimostrazione pratica di quanto tempo fa risparmiare lo scrivere i test? si vabbè, di' la verità che l'hai fatto apposta :D
vabbè scherzi a parte ti do' ragione ma solo quando si programma in team di più persone e magari con esperienze molto diverse; se il programma è fatto da una sola persona secondo me ancora non servono, anzi hanno un costo di mantenimento troppo elevato.
BlueDragon
31-10-2005, 18:04
Visto che ieri è stata annunciata la dipartita della classe Bounds, ho fatto un altro po' di refactoring: ho tolto la classe Bounds e sostituito tutti i riferimenti che vi erano ancora a quella classe sostituendoli con la classe Rectangle :)
Ho lasciato cmq la variabile di nome "bounds" in Grid senza rinominarla perché effettivamente è un buon nome..."bounds" sono i limiti della griglia, e sono di tipo "Rectangle" :)
Sto creando un esercito di piccoli mostri :D
La prima storia del ciclo 4 è pronta, quando volete possiamo proseguire ;)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.