View Full Version : BUGLIST - Bughunters' Official Thread
I bug sono divisi per livello di priorità. Segnalatemeli via mail (su rc6.it), io vedrò di tenere aggiornata la lista.
LEGENDA:
A - questo bug causa un crash e/o impedisce di proseguire nel gioco
B - questo bug non causa un crash, ma e' un grave problema di visulizzazione e/o compromette il gameplay
C - questo bug è un piccolo problema di visualizzazione e non compromette il gameplay
D - questo bug è noto ma DEVE essere totalmente ignorato: la sua soluzione fa parte della wish list
FIXED - bug fixato
------------------------------------------------
BUG LIST
6) B - Vedi qui: http://www.hwupgrade.it/forum/showpost.php?p=20939974&postcount=116
IMPORTANTE: per prenotarsi per la risoluzione dei bug è assolutamente necessario seguire le priorità: se ci sono bug di livello A liberi non ci si può prenotare per quelli di livello B, e così via.
BUG FIXATI
1) D (FIXED) - Il tasto per ribaltare la coppia nella griglia di destra (il trattino) non funziona più: è possibile ribaltare solo la coppia di sinistra.
2) A (FIXED) - Cancellando una riga di gemme tutte uguali con sopra una Big gem, la griglia freeza. - VICIUS
3) B (FIXED) - Quando una Big gem cade in seguito ad una Crush, questa continua a cadere oltrepassando il bordo inferiore della griglia, fino a raggiungere la prima riga con il bordo superiore. - 71104
4) B (FIXED) - Quando si crea una Big gem da 2x2 e si cercano di mettere accanto altre due gemme in modo da formarne una da 2x3 (2 righe, 3 colonne), la Big gem e l'ultima gemma inserita scompaiono, resta solo la penultima.
5) B (FIXED) - Se una flashing gem tocca il fondo della griglia senza avere nulla intorno non viene cancellata (mentre, invece, dovrebbe sparire da sola). - Jappilas
7) C (FIXED) - Il numero massimo di Stone da inviare dopo una Crush deve essere settato a 99. - VICIUS
8) B (FIXED) - E' possibile che le stone non completino la loro trasformazione in gemme. - Bonfo
9) D (FIXED) - Quando la griglia 1 fa game over, la seconda viene aggiornata una volta (la pair continua a scendere) prima di accorgersene e fermarsi. VICIUS
10) C (FIXED) - Il gioco parte anche se si sceglie Quit nel menu principale.
11) B FIXED - Quando una flashing gem cancella un chest, le stone adiacenti NON devono essere cancellate. L'unico modo per cancellare una stone deve essere mediante una crush vicina causata da un chest. - Baol
12) A (FIXED) - Le stone non si trasformano in gemme ed il gioco crasha.
13) B (FIXED) - Le gemspair diventano invisibili se vengono spostate nella colonna più a sinistra. - VICIUS
14) B (FIXED) - Le gemme cancellate da un flashing, se innescano una crush, non devono essere considerate nel conteggio della sua durata, dei punti, e del numero di stone da inviare all'avversario.
15) B (FIXED) - Deve essere possibile ridurre ulteriormente NormalGravity.
16) B FIXED - Quando si verifica una situazione come quella descritta in questo post (http://www.hwupgrade.it/forum/showpost.php?p=21667055&postcount=427), il comportamento deve essere quello indicato nel post stesso. - jappilas
17) C (FIXED) - Il delay tra le ripetizioni dell'animazione dei droppable non viene rispettato. - thebol
Ehm... metterlo sticky?? ;)
due suggerimenti:
1) mettere i contrassegni colorati all'inizio della descrizione anziché alla fine, così uno li vede tutti subito incolonnati e comincia dai bug della gravità che gli interessa
2) cambiare il marchio FIXED in una semplice F nera, così viene una sola lettera allineata agli altri marchi
due suggerimenti:
1) mettere i contrassegni colorati all'inizio della descrizione anziché alla fine, così uno li vede tutti subito incolonnati e comincia dai bug della gravità che gli interessa
2) cambiare il marchio FIXED in una semplice F nera, così viene una sola lettera allineata agli altri marchi
1. Ci sto.
2. Il FIXED va bene lo stesso, è più leggibile :)
AnonimoVeneziano
30-01-2008, 21:12
Il Bug dell' input che hai segnalato te sembra essere dovuto al fatto che colui che ha scritto il file "KeysConfig" possiede una tastiera con Layout americano . Nella tastiera americana, nello stesso punto dove noi abbiamo il "-" c'è invece lo "/" . Per questo da noi non funziona. Però ho fatto qualche prova e sul mio PC anche mettere "KEY_MINUS" non funziona . Boh, dovrò indagare meglio ...
Ciao
Io in questo momento ho una tastiera americana sotto mano :asd: e posso dire che tutti gli input funzionano bene.
Attenzione attenzione, Berto mi ha riferito su MSN di un possibile bug di livello A: la griglia di destra freeza e le gemme smettono di cadere.
Attenzione attenzione, Berto mi ha riferito su MSN di un possibile bug di livello A: la griglia di destra freeza e le gemme smettono di cadere.
E` riproducibile?
no: come dicevo a Jocchan, anche se sono strasicuro che mi si sia congelata la griglia di destra non sono riuscito a riprodurre la cosa; lui ha insistito per segnalare lo stesso il bug... :O
AnonimoVeneziano
31-01-2008, 00:07
no: come dicevo a Jocchan, anche se sono strasicuro che mi si sia congelata la griglia di destra non sono riuscito a riprodurre la cosa; lui ha insistito per segnalare lo stesso il bug... :O
Speriamo ti si stia solo fottendo la ram ... :asd:
Scusate se mi intrometto, non conosco bene la vostra situazione. :)
Qualcuno di voi non ha pensato di potere utilizzare bugzilla/mylyn come strumento per l'assegnazione di task e/o segnalazione di bug?
ciao ;)
Scusate se mi intrometto, non conosco bene la vostra situazione. :)
Qualcuno di voi non ha pensato di potere utilizzare bugzilla/mylyn come strumento per l'assegnazione di task e/o segnalazione di bug?
ciao ;)
YAGNI. Abbiamo due bug e non ne abbiamo mai avuti piu' di una decina :)
lui ha insistito per segnalare lo stesso il bug... :O
Sì, perchè si tratta di un bug di livello A, e - per quanto raro possa essere - va riprodotto e fatto fuori.
Poi magari era solo dovuto a qualche stato provvisorio della build e magari è già stato sistemato, questo chi lo sa... in ogni caso, finchè non avremo la certezza che è già morto e sepolto, consideriamolo presente ;)
jappilas
31-01-2008, 12:48
Ehm... metterlo sticky?? ;)buona idea ;)
Penso di aver riprodotto il bug di Alberto. In pratica basta creare una Biggem di qualsiasi dimensione sopra ad una sola riga di gemme tutte uguali. Quando si fanno esplodere le gemme su cui si regge la Biggem questa dovrebbe scendere di un gradino e il lato inferiore cozzare contro il bordo della griglia. Quello che succede invece è che la Biggem scende finche il lato superiore non arriva alla prima riga e quello inferiore oltrepassa la griglia. Una volta terminato lo spostamento della Biggem la griglia si blocca.
Bene! Puoi riprodurlo con un test?
Bene! Puoi riprodurlo con un test?
Proprio quello che sto cercando di fare ora. Se rimedio qualcosa committo il test commentato sul server così ci potete guardare voi che purtroppo per la soluzione oggi non ho proprio tempo di guardarci.
dunque non mi si stava fottendo la RAM :D :asd:
AnonimoVeneziano
31-01-2008, 13:04
dunque non mi si stava fottendo la RAM :D :asd:
Peccato :D :sofico:
Ciao
PS= Grande vic ;)
cercando di riprodurre il #2 ho sgamato quest'altro:
http://img230.imageshack.us/img230/15/asdasdbv4.png
imperterrito devo dire :asd:
Proprio quello che sto cercando di fare ora. Se rimedio qualcosa committo il test commentato sul server così ci potete guardare voi che purtroppo per la soluzione oggi non ho proprio tempo di guardarci.
Benissimo, grazie :D
Alberto, massacra il bug del gemmone, cosi' puliamo la bug list e continuamo con i refactoring.
Alberto, massacra il bug del gemmone pare facile :mc:
suggerisco prossimamente di introdurre un nuovo stato delle griglie, un PauseState che serva a congelare una griglia: mi farebbe molto comodo se le gemme dell'altra griglia smettessero di cadere e dare GameOver mentre sto cercando di riprodurre un bug -.-
poi in un futuro più lontano la cosa potrebbe eventualmente servire a mettere il gioco in pausa.
Dunque. Ora che ho 10 min ho cominciato a scrivere il test. Tutto ok, solo che non mi ricordo come cavolo applicare la gravità ad un droppable fino a quando puo scendere? :stordita:
public void testBigGemBorderBug()
{
insertAndUpdate(createGem(DIAMOND), 13,1);
insertAndUpdate(createGem(DIAMOND), 13,2);
insert2x2BlockOfGems(EMERALD, 11,1);
grid.updateBigGems();
insertAndUpdate(createChest(DIAMOND), 13,3);
grid.updateCrushes();
// fai scendere la biggem !!
assertNotNull(grid.getDroppableAt(new Cell(12,1)));
}
altro bug: quando si crea una big gem da 2x2 e si cercano di mettere accanto altre due gemme in modo da formarne una da 2x3 (2 righe, 3 colonne), la big gem e l'ultima gemma inserita scompaiono, resta solo la penultima. nei test che ho fatto il gemmone era sempre appoggiato su una fila inferiore di altre gemme (stavo lavorando sul bug precedente :D).
Aggiornato l'OP: il bug 2 ed il bug 3 sono segnati come distinti, ma ho il forte sospetto che la causa sia una sola per entrambi.
suggerisco prossimamente di introdurre un nuovo stato delle griglie, un PauseState che serva a congelare una griglia: mi farebbe molto comodo se le gemme dell'altra griglia smettessero di cadere e dare GameOver mentre sto cercando di riprodurre un bug -.-
poi in un futuro più lontano la cosa potrebbe eventualmente servire a mettere il gioco in pausa.
Un modo per mettere il gioco in pausa andrà inserito per forza ;)
Allora, i bug delle gemmone li avevo risolti io ai tempi, avevo anche scritto dei test, se mi date tempo fino a domani provo a recuperare tutto e risolvere.
Nel frattempo se qualcuno (71104?) vuole lavorarci sopra (erano stupidatine) qui avevo scritto cosa c'era che non andava:
http://www.hwupgrade.it/forum/showthread.php?t=1324877
(dal post #24 in poi)
no per carità non fate affidamento su di me che tra qualche giorno ho un esame decisamente pesante :cry:
già è stato tanto il contributo dei giorni passati :cry:
faccio una domanda: è normale che i gemmoni non siano animati, cioè che non abbiano il riflesso? perché non ricordo se avevamo implementato quella feature (che in caso sarebbe IMHO decisamente da implementare, anche se più avanti), ma vedo che le PNG hanno anche i riflessi.
no per carità non fate affidamento su di me che tra qualche giorno ho un esame decisamente pesante :cry:
già è stato tanto il contributo dei giorni passati :cry:
Ti spezzo la noce del capocollo a te. Sto lavorando per il GDC e ancora riesco a dare qualche colpo a Diamonds.
faccio una domanda: è normale che i gemmoni non siano animati, cioè che non abbiano il riflesso? perché non ricordo se avevamo implementato quella feature (che in caso sarebbe IMHO decisamente da implementare, anche se più avanti), ma vedo che le PNG hanno anche i riflessi.
Si', ancora non abbiamo implementato l'animazione per i gemmoni.
Se ricordo bene c'erano stati dei problemini nell'animare i gemmoni perche` sono tiled sprite :\
Scusa Baol non e` che riesci a recuperare i test per quei due bug? Saranno mica su Sourceforge?
I test non son riuscito a recuperarli da nessuna parte, sto provando a riscriverli ma non è facile, anche perchè il problema non sembra causato dallo stesso errore dell'altra volta (quel codice è stato tutto rifattorizzato).
Chiedo scusa del ritardo, ma mi han dato problemi nell'ordine Eclipse, la scheda grafica e il codice che è cambiato parecchio dall'ultima volta che l'ho visto.
EDIT: Se qualcuno mi spiega perchè questo test fa quattro chiamate a "controller.update(environment.getTimer().getTime())" (che fra l'altro viene già richiamato in MakeAllGemsFall) ne posso scrivere facilmente uno per il Bug 3:
EDIT2: tra l'altro commentando quelle quattro righe il test passa lo stesso, vuol dire che sono inutili o sbaglio?
public void testBigGemFallingWithGravityToGridBottom()
{
grid = controller.getGrid();
insertAndUpdate(createGem(DIAMOND), 13, 3);
insertAndUpdate(createGem(DIAMOND), 13, 4);
insertAndUpdate(createChest(DIAMOND), 13, 5);
insertAndUpdate(createGem(EMERALD), 12, 3);
insertAndUpdate(createGem(EMERALD), 12, 4);
insertAndUpdate(createGem(EMERALD), 11, 3);
insertAndUpdate(createGem(EMERALD), 11, 4);
grid.updateBigGems();
Droppable bigGem = grid.getDroppableAt(new Cell(11, 3));
float gemY = grid.getRowUpperBound(12);
dropGemsPair();
makeAllGemsFall();
controller.update(environment.getTimer().getTime());
controller.update(environment.getTimer().getTime());
controller.update(environment.getTimer().getTime());
controller.update(environment.getTimer().getTime());
assertEquals("Gem must be moved", gemY,
bigGem.getSprite().getPosition().getY(), 0.001f);
}
Piccolo aggiornamento per il bug numero 1: avevo inteso "ribaltare" come "ruotare". Provando la build (in questi giorni ancora non c'ero riuscito) ho visto che effettivamente si trattava del semplice mirror, e quindi la situazione è mooolto meno grave del previsto.
Quindi, per il momento, il bug è da considerarsi retrocesso al livello D.
AnonimoVeneziano
02-02-2008, 23:19
Sembra che sto bug del gemmone stia dando più problemi di quello che sembra, soprattutto per la riproducibilità .
Vediamo se riesco a dargli na piallata :sofico:
Piccolo aggiornamento per il bug numero 1: avevo inteso "ribaltare" come "ruotare". Provando la build (in questi giorni ancora non c'ero riuscito) ho visto che effettivamente si trattava del semplice mirror, e quindi la situazione è mooolto meno grave del previsto.
Quindi, per il momento, il bug è da considerarsi retrocesso al livello D. io sinceramente avrei detto quantomeno C dal momento che invece nell'altra griglia la coppia si può anche ribaltare... ma addirittura B mi pareva ancora più adatto.
ps. omg, 5 avverbi in una frase e mezza :asd: ultimamente sono troppo contorto.
AnonimoVeneziano
03-02-2008, 01:02
io sinceramente avrei detto quantomeno C
C?? Ma che , scherzi, io direi minimo Java o Python :O
Ok basta, mi ammazzo da solo :mbe: :angel:
C?? Ma che , scherzi, io direi minimo Java o Python :O
[...]
Ok basta, mi ammazzo da solo :mbe: :angel:
Ti meriti come minimo 5 giorni di sospensione per OT molesto. :banned:
AnonimoVeneziano
03-02-2008, 01:23
Ok, ho modificato il test di vic per far cadere effettivamente le gemme :
public void testBigGemBorderBug()
{
insertAndUpdate(createGem(DIAMOND), 13,1);
insertAndUpdate(createGem(DIAMOND), 13,2);
insert2x2BlockOfGems(EMERALD, 11,1);
grid.updateBigGems();
insertAndUpdate(createChest(DIAMOND), 13,3);
grid.updateCrushes();
// fai scendere la biggem !!
grid.setStrongestGravity();
grid.doIteration(new UpdateFallsAction(grid, null));
assertNotNull(grid.getDroppableAt(new Cell(12,1)));
}
C'è un solo problema però ... il test non fallisce :stordita:
Secondo il test infatti le gemme sono nella posizione corretta. La biggem è appoggiata sull'ultimo row e non sconfina da nessuna parte.
Non è che potrebbe essere un bug di disegno?
Ciao
AnonimoVeneziano
03-02-2008, 01:24
Ti meriti come minimo 5 giorni di sospensione per OT molesto. :banned:
:eek: :cry:
Vigile e severo ad ogni ora :asd:
EDIT : Azz, sto post di spam ha fatto una nuova pagina e ha "nascosto" il mio post serio :D Leggere la pagina prima plz
Ciao
AnonimoVeneziano
03-02-2008, 01:58
Ok, non avevo capito bene come funziona il sistema di caduta degli oggetti in Diamonds :D
Ovviamente chiamare una volta doIteration() non è sufficiente per far cadere tutto l'oggetto. Potrebbe essere che il problema risieda nell'algoritmo che decide quando smettere di far cadere un oggetto?
Ciao
Pensiero personale....
... con i test messi nelle condizioni attuali è impossible riuscire a beccare qualsiasi bug!!!
Cosa voglio dire: se per scrivere il test che esercita un bug bisogna prima debuggare il test... vorebbe dire, in TDD, scrivere il test del test.
A questo punto 2 opzioni:
- ciao TDD
- loop infinito.
La vera soluzione è la 3: REFACTORING!!!
Ovvero lasciamo li i bug ( che adesso non fanno male a nessuno) e riscirviamo i test in modo che siano al massimo 4/5 righe.
Siccome il potere è limitato invoco i poteri superiori:
http://www.hwupgrade.it/forum/showpost.php?p=20892591&postcount=186
e
http://www.hwupgrade.it/forum/showpost.php?p=20838974&postcount=2
P.S.: non che io sia il più bello... sta settimana sono risucito a smazzare poco. :cry: :cry:
Concordo in pieno con Bonfo.
Per testare i bug è un disastro, sto cercando da ieri di capire cosa fa la metà dei test, per capire come scrivere quelli che devo fare io.
Esemplare il caso di TestGemFalling e TestGemFallingWithGravity, che a quel che ho capito testano esattamente le stesse cose!
Oppure il fatto che per entrambi i bug aperti CI SIA UN TEST che dovrebbe coprirli (il test postato da Anonimo qui sopra è molto simile ad un test già presente). Ma il test passa comunque.
Nonostante tutto ciò una buona notizia: il bug 4 è risolto.
Basta aggiungere la seguente assert:
assertNotNull("BigGem must exist after extension", grid.getDroppableAt(new Cell(12, 3)));
ai seguenti test in TestBigGemInGrid.java:
- testBigGemExtendsUp
- testBigGemExtendsDown
- testBigGemExtendsRight
- testBigGemExtendsOnLeft
E riscrivere il metodo AddColumn di BigGem come segue:
DroppableList droppableList = new DroppableList();
for(int row = region.getTopRow(); row <= region.getBottomRow(); ++row)
{
droppableList.add(grid.getDroppableAt(new Cell(row, column)));
}
addGem(droppableList);
(In pratica com'era riscritto prima il metodo aggiungeva a "includedGems" la gemma superiore e la BigGem stessa, invece che l'altra gemma, così poi updateBigGems cancellava le cose sbagliate)
"Perchè non lo fai tu?" mi direte? (o anche "Abbiamo un volontario!"...)
Semplicemente non ho ancora un account, se qualcuno avesse fretta qua c'è tutto, altrimenti farò io appena possibile :D
EDIT: per il bug 3 sembra proprio non sia la stessa causa dell'altra volta, quindi sono arrivato anche io alle conclusioni di Anonimo, seppure non abbia capito molto dei vari stati (c'è già stata la proposta di uno schema, vero?).
Fantastico, ma....
Basta aggiungere la seguente assert:
assertNotNull("BigGem must exist after extension", grid.getDroppableAt(new Cell(12, 3)));
ai seguenti test in TestBigGemInGrid.java:
- testBigGemExtendsUp
- testBigGemExtendsDown
- testBigGemExtendsRight
- testBigGemExtendsOnLeft
... no buono.
O meglio, un altro lampante segnale he c'è qualcosa che non va... per mettere a posto una riga di codice basta 1 test, non c'è biosgno di 4 che oltretutto stanno testando un altra cosa.
Tutti in coro: "REFACTORING!!"
P.S.: mi sento un po' Balmer: developer, developer, developer :asd: :asd:
C'è un bug nello script di lancio per Linux.
Nella prima riga ci deve essere #!/bin/bash invece di #!/bin/sh
Inoltre:
$ ./DiamondCrush64
Exception in thread "main" java.lang.UnsatisfiedLinkError: org.lwjgl.DefaultSysImplementation.getJNIVersion()I
at org.lwjgl.DefaultSysImplementation.getJNIVersion(Native Method)
at org.lwjgl.Sys.<clinit>(Sys.java:103)
at org.lwjgl.openal.AL.<clinit>(AL.java:59)
at it.diamonds.engine.audio.OpenALAudio.<init>(Unknown Source)
at it.diamonds.engine.audio.OpenALAudio.create(Unknown Source)
at it.diamonds.engine.Environment$1.create(Unknown Source)
at it.diamonds.engine.Environment.createAudio(Unknown Source)
at it.diamonds.engine.Environment.createAudio(Unknown Source)
at it.diamonds.engine.Environment.createGameLoop(Unknown Source)
at it.diamonds.Game.<init>(Unknown Source)
at it.diamonds.Game.main(Unknown Source)
su Linux a 64 bit.
Ora provo la versione a 32 bit.
C'è un bug nello script di lancio per Linux.
Nella prima riga ci deve essere #!/bin/bash invece di #!/bin/sh
/bin/sh dovrebbe essere un link alla shell predefinità. Su alcuni sistemi bash non è installato mentre sh esiste sempre altrimenti esplode tutto. Meglio tenere così.
Inoltre:
$ ./DiamondCrush64
Exception in thread "main" java.lang.UnsatisfiedLinkError: org.lwjgl.DefaultSysImplementation.getJNIVersion()I
at org.lwjgl.DefaultSysImplementation.getJNIVersion(Native Method)
at org.lwjgl.Sys.<clinit>(Sys.java:103)
at org.lwjgl.openal.AL.<clinit>(AL.java:59)
at it.diamonds.engine.audio.OpenALAudio.<init>(Unknown Source)
at it.diamonds.engine.audio.OpenALAudio.create(Unknown Source)
at it.diamonds.engine.Environment$1.create(Unknown Source)
at it.diamonds.engine.Environment.createAudio(Unknown Source)
at it.diamonds.engine.Environment.createAudio(Unknown Source)
at it.diamonds.engine.Environment.createGameLoop(Unknown Source)
at it.diamonds.Game.<init>(Unknown Source)
at it.diamonds.Game.main(Unknown Source)
su Linux a 64 bit.
Ora provo la versione a 32 bit.
La versione a 64 bit è broken. lib/linux64 va cancellata del tutto perché ora le librerie stanno tutte in lib/linux. Il build.xml modificato per creare una sola versione per linux e lo script di avvio modificato che tanto ci pensa lwjgl a capire quale libreria caircare.
Edit: aggiungo che per la versione a 64bit mancano da compilare le versioni a 64bit di libIL* e lwjgl-devil che purtroppo non erano presenti nel pacchetto dei pre-compilati. Se qualcuno si scarica i sorgenti e ci prova fa un favore a tutti i pinguini. :D
/bin/sh dovrebbe essere un link alla shell predefinità. Su alcuni sistemi bash non è installato mentre sh esiste sempre altrimenti esplode tutto. Meglio tenere così.
Io se metto bash parte, se lascio sh non parte ;)
Con /bin/sh:
$ ./DiamondCrush64
./DiamondCrush64: 6: function: not found
In ogni caso se è broken vedo di provare l'altra.
Esemplare il caso di TestGemFalling e TestGemFallingWithGravity, che a quel che ho capito testano esattamente le stesse cose!
Puoi semplificare questi due test e eliminare quello che non serve?
Nonostante tutto ciò una buona notizia: il bug 4 è risolto.
Basta aggiungere la seguente assert:
assertNotNull("BigGem must exist after extension", grid.getDroppableAt(new Cell(12, 3)));
ai seguenti test in TestBigGemInGrid.java:
- testBigGemExtendsUp
- testBigGemExtendsDown
- testBigGemExtendsRight
- testBigGemExtendsOnLeft
Ottimo! Semplifica questi quattro test, accorpali dove necessario, e aggiungi un nuovo test che esercita solo il bug e nient'altro.
"Perchè non lo fai tu?" mi direte? (o anche "Abbiamo un volontario!"...)
Semplicemente non ho ancora un account, se qualcuno avesse fretta qua c'è tutto, altrimenti farò io appena possibile :D
Faccio subito :)
/bin/sh dovrebbe essere un link alla shell predefinità. Su alcuni sistemi bash non è installato mentre sh esiste sempre altrimenti esplode tutto. Meglio tenere così.
Edit: aggiungo che per la versione a 64bit mancano da compilare le versioni a 64bit di libIL* e lwjgl-devil che purtroppo non erano presenti nel pacchetto dei pre-compilati. Se qualcuno si scarica i sorgenti e ci prova fa un favore a tutti i pinguini. :D
Setup avanti avanti avanti :D
Setup avanti avanti avanti :D
Se un giorno dovessimo incontrarci ti stacco tutte le ditine e ci gioco a shanghai! :D
AnonimoVeneziano
03-02-2008, 09:55
Vabbè, comunque ho risolto il bug della biggem
Adesso sistemo il test e poi committo.
Il problema è che nella caduta viene applicata una StrongestGravity che ha forza 10 (in pratica a ogni iterazione di animazione il biggem scende di 10 pixels) solo che una casella è lunga 32 pixels e 10 non è un multiplo di 32 ...
Nel codice di "Biggem.canMoveDown()" c'è questa linea di codice :
public boolean canMoveDown(Grid grid)
{
if(getSprite().getPosition().getY() != grid.getRowUpperBound(region.getTopRow()))
{
return true;
}
In pratica ritorna sempre true se la posizione Y dello Sprite non raggiunge mai grid.getRowUpperBound(colonna_di_arrivo_biggem) e visto che StrongestGravity non è multiplo di 32 questo non avviene mai mandando in loop infinito la griglia in cui la biggem cade (si blocca totalmente) e causando quindi il BUG.
La soluzione che propongo è di cambiare la costante di moltiplicazione della StrongestGravity da 20 a 16, così che la forza passi ad 8 e sia sottomultiplo di 32.
Adesso finisco di scrivere il test e se vi va bene la soluzione committo.
Ciao
AnonimoVeneziano
03-02-2008, 10:07
Ok, test scritto.
Appena mi dite se la soluzione è OK (o se per qualche ragione la strongest deve rimanere 20 o è necessario metterla più alta di 16 al prossimo multiplo) e appena fek risistema il server committo.
Basta copiare la canMoveButNotWithFullGravity() che c'è in AbstractSingleDroppable, il che mi fa pensare che finisca in AbstractDroppable ;)
In ogni caso da qualche parte ho fatto ( da poco) un test che controllava che la bigGem si fermasse sul fondo nonostane la gravità..aspetta che cerco.
EDIT:
Eccolo qua in it.diamonds.tests.droppable.gems.TestGemFallingWithGravity:
public void testBigGemFallingWithStrongGravityToGridBottom()
{
controller.getGrid().setGravity(Cell.SIZE_IN_PIXELS * 4);
testBigGemFallingWithGravityToGridBottom();
}
Ok, test scritto.
Appena mi dite se la soluzione è OK (o se per qualche ragione la strongest deve rimanere 20 o è necessario metterla più alta di 16 al prossimo multiplo) e appena fek risistema il server committo.
Le cose devono funzionare indipendentemente dai valori, altrimenti il config che ci sta a fare?!? Per me la soluzione di cambiare il valore è sbagliata.
EDIT: infatti cambiando il test da
controller.getGrid().setGravity(Cell.SIZE_IN_PIXELS * 4);
a
controller.getGrid().setGravity(Cell.SIZE_IN_PIXELS * 5);
non va più una mazza.
Fixalo, ma non cambiando il valore ;)
Ora vado veramente a letto !!! :D
Le cose devono funzionare indipendentemente dai valori, altrimenti il config che ci sta a fare?!? Per me la soluzione di cambiare il valore è sbagliata.
EDIT: infatti cambiando il test da
controller.getGrid().setGravity(Cell.SIZE_IN_PIXELS * 4);
a
controller.getGrid().setGravity(Cell.SIZE_IN_PIXELS * 5);
non va più una mazza.
Fixalo, ma non cambiando il valore ;)
Ora vado veramente a letto !!! :D
Concordo. Se domani vogliamo cambiare la larghezza delle celle ci troviamo nuovamente con il bug.
AnonimoVeneziano
03-02-2008, 10:23
Ok, stavo giusto giusto guardando adesso quella cosa. (Difatti non mi spiegavo come mai per le gemme funzionasse e per le biggem no e indagando ...)
Ciao
Il sistema della gravità non è chiarissimo....
... perchè viene sempre applicata 1/2 actualGravity, invece che "intera"? :wtf:
Secondo me rende le cose meno comprensibili. Siccome è un fattore di scala perchè non lo caviamo e basta e dividiamo per due tutti i valori??
Qui però bisogna chiedere a costumer: Jocchan!! :D
AnonimoVeneziano
03-02-2008, 10:36
Guardando bene ho notato che non c'è nessuna canMoveButNotWithFullGravity() in AbstractSingleDroppable.
Questo significa che sia BigGem che Gem e tutti gli altri usano quella di AbstractDroppable che , probabilmente non funziona bene per i Gemmozzi.
Indago ...
AnonimoVeneziano
03-02-2008, 10:37
Il sistema della gravità non è chiarissimo....
... perchè viene sempre applicata 1/2 actualGravity, invece che "intera"? :wtf:
Secondo me rende le cose meno comprensibili. Siccome è un fattore di scala perchè non lo caviamo e basta e dividiamo per due tutti i valori??
Qui però bisogna chiedere a costumer: Jocchan!! :D
Ti sei offerto volontario per scovare tutti i "Gravity / 2" che ci sono nel codice e sostituirli? :asd: :sofico:
Ok, test scritto.
Appena mi dite se la soluzione è OK (o se per qualche ragione la strongest deve rimanere 20 o è necessario metterla più alta di 16 al prossimo multiplo) e appena fek risistema il server committo.
Puoi aspettare Jocchan? A occhio non credo voglia usare solo multipli e l'idea non piace neppure a me perche' significa legare il gameplay alla risoluzione. Forse serve una soluzione alternativa.
Comunque ottimo lavoro :)
Ti sei offerto volontario per scovare tutti i "Gravity / 2" che ci sono nel codice e sostituirli? :asd: :sofico:
Se semplifica le cose lo faccio appena mi sevglio ;)
VICIUS: ma la versione per Linux a 32 bit dovrebbe girare su Linux a 32 bit ? A me non funziona.
$ bash DiamondCrush
Display Adapter: null
List of available display modes:
640 x 400 x 24 @60Hz
1280 x 1024 x 24 @75Hz
320 x 200 x 24 @75Hz
640 x 480 x 24 @72Hz
640 x 480 x 24 @75Hz
1152 x 864 x 24 @75Hz
1280 x 1024 x 24 @70Hz
1152 x 864 x 24 @70Hz
800 x 600 x 24 @60Hz
320 x 240 x 24 @60Hz
800 x 600 x 24 @56Hz
400 x 300 x 24 @60Hz
1024 x 480 x 24 @60Hz
1024 x 768 x 24 @60Hz
512 x 384 x 24 @60Hz
400 x 300 x 24 @75Hz
720 x 480 x 24 @60Hz
1024 x 768 x 24 @70Hz
1024 x 768 x 24 @75Hz
1024 x 768 x 24 @72Hz
640 x 400 x 24 @75Hz
1280 x 1024 x 24 @60Hz
320 x 200 x 24 @60Hz
800 x 600 x 24 @70Hz
640 x 480 x 24 @60Hz
1152 x 864 x 24 @60Hz
800 x 600 x 24 @72Hz
848 x 480 x 24 @60Hz
800 x 600 x 24 @75Hz
320 x 240 x 24 @75Hz
720 x 576 x 24 @60Hz
Best mode: 800 x 600 x 24 @75Hz
#
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00002ba87d61ddf0, pid=11235, tid=1076017488
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.6.0_03-b05 mixed mode)
# Problematic frame:
# C [libc.so.6+0x79df0] memset+0x60
#
# An error report file with more information is saved as hs_err_pid11235.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
DiamondCrush: line 98: 11235 Aborted (core dumped) $JAVA -Djava.library.path=$JNI_PATH -jar $DIAMOND_JAR
Il log dell'errore è allegato.
Non sarebbe meglio distribuire anche liballeg.so.4.1 insieme alle altre librerie ? Ho dovuto fare un link dalla versione 4.2 per farlo partire.
Se semplifica le cose lo faccio appena mi sevglio ;)
Hai fatto i tuoi commit?
Visto. Buona notte :)
(ma dove sei?)
AnonimoVeneziano
03-02-2008, 10:48
Puoi aspettare Jocchan? A occhio non credo voglia usare solo multipli e l'idea non piace neppure a me perche' significa legare il gameplay alla risoluzione. Forse serve una soluzione alternativa.
Comunque ottimo lavoro :)
Thanks :)
Sono già al lavoro per una soluzione alternativa.
Per adesso le strade che vedo possibili sono :
- Cambiare la canMoveButNotWithFullGravity() in AbstractDroppable in modo che tenga conto dell'altezza del droppable
- Fare l'overloading della stessa in BigGem ( o BugGem come sto iniziando a chiamarla :asd:)
Sto cercando di fare la prima :)
La prima mi piace. Considera che voglio semplificare molto Droppable ed estrarre in classi la maggior parte di quelle interfacce. Anche BigGem ne giovera'.
AnonimoVeneziano
03-02-2008, 10:59
VICIUS: ma la versione per Linux a 32 bit dovrebbe girare su Linux a 32 bit ? A me non funziona.
$ bash DiamondCrush
[...]
#
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00002ba87d61ddf0, pid=11235, tid=1076017488
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.6.0_03-b05 mixed mode)
# Problematic frame:
# C [libc.so.6+0x79df0] memset+0x60
#
# An error report file with more information is saved as hs_err_pid11235.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
DiamondCrush: line 98: 11235 Aborted (core dumped) $JAVA -Djava.library.path=$JNI_PATH -jar $DIAMOND_JAR
Il log dell'errore è allegato.
Non sarebbe meglio distribuire anche liballeg.so.4.1 insieme alle altre librerie ? Ho dovuto fare un link dalla versione 4.2 per farlo partire.
Stai cercando di lanciare la versione a 32 con la JVM a 64 qua.
VICIUS: ma la versione per Linux a 32 bit dovrebbe girare su Linux a 32 bit ? A me non funziona.
Ieri andava :D
Dal messaggio di errore sembra che tu stia usando una jvm a 64 bit. L'unica cosa che posso ipotizzare è che il problema sia quello. Io purtroppo ho ancora un vecchio p4 1.5ghz con linux, i 64 bit me li sogno :D
[...]
Non sarebbe meglio distribuire anche liballeg.so.4.1 insieme alle altre librerie ? Ho dovuto fare un link dalla versione 4.2 per farlo partire.
Passano gli anni ma quelli di lwjgl non hanno ancora imparato a compilare linkando a nomi generici di librerie :rolleyes:
Io eviterei di includere librerie che non sono legate direttamente a dc altrimenti finiamo col distribuire un intero sistema linux col gioco. Prima della release ci compiliamo come si deve le librerie così risolviamo tutti questi odiosi contrattempi.
Hai fatto i tuoi commit?
Visto. Buona notte :)
(ma dove sei?)
Se non sbaglio ora bonfo è finito negli states :)
Stai cercando di lanciare la versione a 32 con la JVM a 64 qua.
Dal punto di vista di Java non dovrebbe influire molto...no ?
Ora provo con un JVM a 32 bit.
Io eviterei di includere librerie che non sono legate direttamente a dc altrimenti finiamo col distribuire un intero sistema linux col gioco.
Posso? :D
AnonimoVeneziano
03-02-2008, 11:14
Dal punto di vista di Java non dovrebbe influire molto...no ?
Ora provo con un JVM a 32 bit.
Usa anche chiamate JNI , quindi credo influisca per quello.
Ciao
AnonimoVeneziano
03-02-2008, 12:25
Scusate raga, ho bisogno di un consulto.
Ho corretto il bug , ma la mia correzione fa fallire un altro test :
TestGemFallingWithGravity.testBigGemFallingWithStrongGravityToGridBottom()
La mia soluzione è modificare la prima parte di canMoveButNotWithFullGravity() aggiungendo:
int numberofrowsoverone = region.getBottomRow() - region.getTopRow();
if(getSprite().getPosition().getY() + numberofrowsoverone*Cell.SIZE_IN_PIXELS + ((float)grid.getActualGravity())
/ 2 > gridBottom )
{
return true;
}
In questo modo il metodo tiene conto dell'altezza del droppable nel calcolo facendo riuscire il mio test e fallire l'altro.
Dopo alcune prove sono riuscito a tracciare il motivo di questo fallimento.
La prima riga del test incriminato è : controller.getGrid().setGravity(Cell.SIZE_IN_PIXELS * 4);
comando che setta la gravità a 128 implicando così che alla prossima iterazione la caduta del droppable sarà di ben 2 celle!
Tutto il sistema di movimento dei droppables è però settato in modo che venga effettuato il movimento al massimo di una cella per volta . Col sistema precedente quello che succedeva è che la BigGem si muoveva di 2 gemme come se niente fosse andando a sbordare oltre l'ultima riga (come succedeva anche col bug) , con l'aggiunta che ho fatto io in pratica la biggem non si muove (perchè sennò andrebbe a sbordare oltre l'ultima riga, quindi la canMoveButNotWithFullGravity() ritorna true, perchè GIUSTAMENTE non può essere applicata tutta la gravità, altrimenti si sborda) e il test in questione entra in "loop infinito" (aspetta che la gemma si muova, ma non si muove mai perchè sennò sborderebbe).
Io sono convinto che sia il test ad essere buggato e che bisognerebbe impostare la gravità al MAX ad 1 casella.
Voi che ne dite?
Ciao
Non credo si possa limitare un droppable a muoversi solo di una cella per iterazione. Di nuovo, stai legando il gameplay ad una questione tecnica (iteration rate in questo caso).
Perche' devi imporre questa limitazione?
AnonimoVeneziano
03-02-2008, 12:39
Non credo si possa limitare un droppable a muoversi solo di una cella per iterazione. Di nuovo, stai legando il gameplay ad una questione tecnica (iteration rate in questo caso).
Perche' devi imporre questa limitazione?
Allora c'è da lavorarci di più perchè bisogna modificare più di un solo metodo.
Come minimo due, ma non ho ancora fatto il conto completo .
Non credo si possa limitare un droppable a muoversi solo di una cella per iterazione. Di nuovo, stai legando il gameplay ad una questione tecnica (iteration rate in questo caso).
Perche' devi imporre questa limitazione?
Mi ricordo che dopo la FP avevo fixato questo problema insieme a qualcuno (baol?). Purtroppo non ricordo come feci ed i cambiamenti furono probabilmente persi.. Ora guardo meglio
Allora il metodo incriminato dovrebbe essere questo in AbstractDroppable:
public void moveDown(Grid grid)
{
if(canMoveButNotWithFullGravity(grid))
{
getSprite().getPosition().setY(
grid.getRowUpperBound(getRegion().getTopRow()));
return;
}
getSprite().translate(0, (float)grid.getActualGravity() / 2);
if(getSprite().getPosition().getY() > grid.getRowUpperBound(getRegion().getTopRow()))
{
getRegion().setRow(getRegion().getTopRow() + 1);
}
}
Mi pare che l'if dovesse essere sostituito con un while... Vedi un po' se fixa il test. Se lo fixa aspetta a committare, sarebbe meglio risolvere il bug prima in TDD :)
io sinceramente avrei detto quantomeno C dal momento che invece nell'altra griglia la coppia si può anche ribaltare... ma addirittura B mi pareva ancora più adatto.
ps. omg, 5 avverbi in una frase e mezza :asd: ultimamente sono troppo contorto.
I bug di livello C sono bug grafici che non impattano sul gameplay. Questo impatta sul gameplay e crea una disparità tra i due giocatori... ma perchè allora retrocederlo a livello D? Perchè è una feature minore, ed al momento è meglio concentrarsi su altre priorità.
Lo risolveremo, ma non siamo obbligati a farlo immediatamente.
Il sistema della gravità non è chiarissimo....
... perchè viene sempre applicata 1/2 actualGravity, invece che "intera"? :wtf:
Secondo me rende le cose meno comprensibili. Siccome è un fattore di scala perchè non lo caviamo e basta e dividiamo per due tutti i valori??
Qui però bisogna chiedere a costumer: Jocchan!! :D
A me sta benissimo, quello che conta per il customer è che il comportamento sia aderente a quello desiderato (ovvero quello di ora), indipendentemente dai valori numerici ;)
Per il valore di Strongest da 20 a 16, testo la build (era settabile nel file di config, vero?) e vi dico.
AnonimoVeneziano
03-02-2008, 12:59
Allora il metodo incriminato dovrebbe essere questo in AbstractDroppable:
public void moveDown(Grid grid)
{
if(canMoveButNotWithFullGravity(grid))
{
return;
}
getSprite().translate(0, (float)grid.getActualGravity() / 2);
if(getSprite().getPosition().getY() > grid.getRowUpperBound(getRegion().getTopRow()))
{
getRegion().setRow(getRegion().getTopRow() + 1);
}
}
Mi pare che l'if dovesse essere sostituito con un while... Vedi un po' se fixa il test. Se lo fixa aspetta a committare, sarebbe meglio risolvere il bug prima in TDD :)
Purtroppo non fixa (il test va ancora in loop)
Il problema è questa riga :
getSprite().getPosition().setY(
grid.getRowUpperBound(getRegion().getTopRow()));
In pratica quello che succede è che questa linea si appoggia al fatto che se un droppable si trova anche un pixel sotto al bordo superiore di una riga è considerato non essere più contenuto in quella riga, ma passa automaticamente alla riga sottostante. In pratica fa il ragionamento : "Se il droppable non si può muovere di tutta la gravità allora significa che si trova a meno di una cella dall'ostacolo, questo significa non è più allineato al bordo superiore della sua riga precedente e che quindi è considerato essere contenuto nella riga che lo ospiterà, quindi setto la posizione Y del suo sprite al bordo superiore di quella riga" .
E fin qui tutto bene, almeno fino a che questa riga non viene eseguita nel occasione in cui il droppable ha la posizione dello sprite uguale al bordo superiore della riga in cui è contenuto. In questo caso, la linea di codice non fa altro che risettare lo sprite alla stessa posizione facendo in pratica una NOP.
E' per questo che il test entra in loop, cerca di spostare in basso il droppable , ma ogni volta che viene eseguita la moveDown() non viene fatto niente e quindi continua a ripetere e ripetere ... etc
Ciao
Purtroppo non fixa (il test va ancora in loop)
Il problema è questa riga :
getSprite().getPosition().setY(
grid.getRowUpperBound(getRegion().getTopRow()));
In pratica quello che succede è che questa linea si appoggia al fatto che se un droppable si trova anche un pixel sotto al bordo superiore di una riga è considerato non essere più contenuto in quella riga, ma passa automaticamente alla riga sottostante. In pratica fa il ragionamento : "Se il droppable non si può muovere di tutta la gravità allora significa che si trova a meno di una cella dall'ostacolo, questo significa non è più allineato al bordo superiore della sua riga precedente e che quindi è considerato essere contenuto nella riga che lo ospiterà, quindi setto la posizione Y del suo sprite al bordo superiore di quella riga" .
E fin qui tutto bene, almeno fino a che questa riga non viene eseguita nel occasione in cui il droppable ha la posizione dello sprite uguale al bordo superiore della riga in cui è contenuto. In questo caso, la linea di codice non fa altro che risettare lo sprite alla stessa posizione facendo in pratica una NOP.
E' per questo che il test entra in loop, cerca di spostare in basso il droppable , ma ogni volta che viene eseguita la moveDown() non viene fatto niente e quindi continua a ripetere e ripetere ... etc
Ciao
conosci meglio di me sta parte ehhe. Non ricordo assolutamente :\
Non ho capito niente :D
Puoi mica provare a rispiegarlo in modalita` "appena svegliato la domenica mattina" per favore? :P
Ah forse ho capito.. Mi ero fatto confondere dalla riga di codice da te quotata mentre il problema e` in canMoveButNotWithFullGravity(grid)
AnonimoVeneziano
03-02-2008, 13:38
conosci meglio di me sta parte ehhe. Non ricordo assolutamente :\
Non ho capito niente :D
Puoi mica provare a rispiegarlo in modalita` "appena svegliato la domenica mattina" per favore? :P
D'ho :D
E' che purtroppo con le spiegazioni non sono proprio il massimo :asd:
In pratica un droppable è considerato essere presente in una riga se la Y del suo sprite è minore della Y del bordo superiore stesso della riga.
Nel momento stesso in cui lo sprite sorpassa anche di un solo pixel il bordo superiore della riga ecco che questa linea di codice di AbstractDroppable.moveDown() :
if(getSprite().getPosition().getY() > grid.getRowUpperBound(getRegion().getTopRow()))
{
getRegion().setRow(getRegion().getTopRow() + 1);
}
entra in gioco spostando di fatto quella che è considerata la riga da dove parte il droppable (la riga superiore del droppable, se il droppable si estende su più righe) alla riga successiva.
Sperando di aver spiegato decentemente fino ad ora arriviamo al nostro problema :D
La riga incriminata postata precedentemente nell'altro post fa ragiona pensando che un droppable non possa scorrere più di una cella per volta. Per questo fa l'assunzione che se il droppable non può scendere alla gravità massima allora significa che deve distare meno di una cella dall'ostacolo che lo bloccherà. Se dista meno di una cella dall'ostacolo significa che è considerato parte della riga prima di quella in cui è presente l'ostacolo ( questa è difficile :asd:) . Quindi setta la posizione dello sprite al bordo superiore di quella riga.
Se però lo sprite in realtà non si può muovere di tutta la gravità perchè dovrebbe farsi due celle andando a sovrapporsi con l'ostacolo, ma nel momento in cui è chiamato quel metodo si trova perfettamente allineato col bordo della riga su cui sta prima di cadere allora non verrà spostato affatto perchè verrà invece risettato alla stessa posizione in cui stava.
Spero si capisca meglio, ma dubito :D
Ciao
Il prossimo refactoring sara' esprimere la gravita' in termini di celle (o multipli e sottomultipli) e non in termini di pixel.
Questo ci permettera' a breve di portare fuori Sprite e Animation da Droppable e renderla un'entita' piu' leggera che lavora solo con Grid e non ha alcuna nozione di pixel e animazioni.
Droppable, AbstractDroppable et al stanno facendo troppe cose ed hanno troppe responsabilita'.
Sisi ora ho capito quale e` il problema e ricordo di aver riscritto tutta quella parte :s
Bisogna riscrivere il metodo e tutto cio` che viene chiamato all'interno dello stesso :)
AnonimoVeneziano
03-02-2008, 13:46
Ah forse ho capito.. Mi ero fatto confondere dalla riga di codice da te quotata mentre il problema e` in canMoveButNotWithFullGravity(grid)
Mmm, beh, il problema è in entrambi.
Il bug originario è nella canMoveButNotWithFullGravity() . In pratica questa non tiene conto dell'altezza del biggem (considerandolo alto quanto un droppable singolo, ossia una cella) e così da il benestare per muovere il biggem di due celle , anche se questo significa far sovrapporre il biggem con la fine della griglia.
Io ho corretto quel bug, ma la correzione ha riportato alla luce il bug di quella linea che ho quotato precedentemente , che in pratica ragiona come se i droppables non possano muoversi per più di 1 cella per iterazione. Questo fa fallire il test che ho nominato prima . (più che farlo fallire lo fa cadere in un loop infinito)
Ciao
Ho provato a settare Strongest a 16: le differenze ci sono, non saranno notevoli ma direi che è meglio riparlarne dopo il refactoring.
Si ma non e` un bug limitato alla BigGem.
Il gioco non funziona se abbiamo una gravity abbastanza elevata da permettere alla droppable di muoversi di piu` di una cella a ciclo
AnonimoVeneziano
03-02-2008, 13:54
Il prossimo refactoring sara' esprimere la gravita' in termini di celle (o multipli e sottomultipli) e non in termini di pixel.
Questo ci permettera' a breve di portare fuori Sprite e Animation da Droppable e renderla un'entita' piu' leggera che lavora solo con Grid e non ha alcuna nozione di pixel e animazioni.
Droppable, AbstractDroppable et al stanno facendo troppe cose ed hanno troppe responsabilita'.
Concordo , questo dovrebbe rimuovere, in primis, la necessità di una canMoveButNotWithFullGravity() , ma il bug del movimento maggiore di una cella per volta rimane e necessita di una riscrittura della moveDown() che tenga in considerazione questa possibilità. (o lo spostamento della moveDown() in qualche altra classe esterna al droppable)
EDIT: Come non detto, la canMoveButNotWithFullGravity() ci vuole se vogliamo permettere al sistema di spostare le gemme di più di una cella per volta.
Baol mi daresti i ltuo contatto MSN che ti devo chiedere due cose :P
Baol, avrei bisogno che rifattorizzassi i 4 test che hai modificato, aggiungendo un solo test per esercitare il bug e semplificando i 4 esistenti.
Questo vale per tutti: da ora ogni test nuovo non si aggiunge ai test case esistenti, ma gli si crea un nuovo test case che lo identifichi al meglio. Se e' un test simile ad altri gia' presenti, si portano questi test nel nuovo test case. Lo stesso vale per i singoli test: non aggiungete assert, create un nuovo test. Se ci sono duplicazioni con altri test eliminatele creando nuovi test case e semplificando quegli esistenti.
La regola ora e' di alleggerire i test case esistenti e non appesantirli. La parola d'ordine qui e' fare le cose semplici.
@Ufo: Hai PM ;)
Io intanto sto cercando di rifattorizzare i test in BigGemInGrid, ma è un mezzo casino, per ora sto facendo piccole modifiche, rimozione delle duplicazioni e simili.
EDIT: @fek: ok, lavoro in quella direzione
Una domanda: a cosa serve il GridTestCase?
EDIT: a parte che intendevo il BigGemTestCase, comunque ho capito, tutto a posto.
EDIT2:
Sto creando un testcase TestBigGemExtension e ho incontrato questi test (in TestBigGemInGrid.java) che secondo me non testano assolutamente nulla, se siete d'accordo li elimino:
public void testCantExtendIfOnTheLeftBorder()
{
insert2x2BlockOfGems(EMERALD, 12, 0);
grid.updateBigGems();
assertEquals("BigGem cant extend on the left border", 1,
getNumberOfExtensibleObject());
}
public void testCantExtendIfOnTheRightBorder()
{
insert2x2BlockOfGems(EMERALD, 12, 6);
grid.updateBigGems();
assertEquals("BigGem cant extend on the right border", 1,
getNumberOfExtensibleObject());
}
public void testCantExtendIfOnTheTopBorder()
{
insert2x2BlockOfGems(EMERALD, 12, 4);
insert2x2BlockOfGems(DIAMOND, 10, 4);
insert2x2BlockOfGems(EMERALD, 8, 4);
insert2x2BlockOfGems(DIAMOND, 6, 4);
insert2x2BlockOfGems(EMERALD, 4, 4);
insert2x2BlockOfGems(DIAMOND, 2, 4);
insert2x2BlockOfGems(EMERALD, 0, 4);
grid.updateBigGems();
assertEquals("BigGem cant extend on the right border", 7,
getNumberOfExtensibleObject());
}
I bug di livello C sono bug grafici che non impattano sul gameplay. Questo impatta sul gameplay e crea una disparità tra i due giocatori... ma perchè allora retrocederlo a livello D? Perchè è una feature minore, ed al momento è meglio concentrarsi su altre priorità.
Lo risolveremo, ma non siamo obbligati a farlo immediatamente. e poi chi si ricorda più di riportarlo al livello di gravità corretto quando sarà ora di sistemarlo? gravità del bug e priorità sono due cose diverse, quindi potremmo indicizzarli in base ad ambedue i parametri anziché solo in base alla gravità (è solo un'idea, se non siete d'accordo non fa nulla).
e poi chi si ricorda più di riportarlo al livello di gravità corretto quando sarà ora di sistemarlo? gravità del bug e priorità sono due cose diverse, quindi potremmo indicizzarli in base ad ambedue i parametri anziché solo in base alla gravità (è solo un'idea, se non siete d'accordo non fa nulla).
Alberto, noi abbiamo un 10.000 bug circa e li cataloghiamo tutti in base alla gravita', che ne definisce anche la priorita'. Se funziona li' con 150 persone, direi che puo' funzionare anche per quattro o cinque bug di Diamonds :)
AnonimoVeneziano
03-02-2008, 15:38
raga, sono riuscito a risolvere il bug del gemmone senza toccare la gravità del test maledetto che entrava in loop.
Mi manca però il test per la modifica alla moveDown() che era necessaria.
E' da mettere in TestAbstractDroppable.java o in TestGemFallingWithGravity.java?
La correzione consiste in far diventare la moveDown() questo (le parti cambiate in grassetto) :
public void moveDown(Grid grid)
{
if (canMoveButNotWithFullGravity(grid))
{
while (canMoveDown(grid))
{
if ( getSprite().getPosition().getY() == grid.getRowUpperBound(getRegion().getTopRow()))
{
getRegion().setRow(getRegion().getTopRow() + 1);
}
getSprite().getPosition().setY(
grid.getRowUpperBound(getRegion().getTopRow()));
}
return;
}
getSprite().translate(0, (float)grid.getActualGravity() / 2);
if(getSprite().getPosition().getY() > grid.getRowUpperBound(getRegion().getTopRow()))
{
getRegion().setRow(getRegion().getTopRow() + 1);
}
}
Ditemi se vale la pena di fare il lavoro o è meglio aspettare il refactoring
Ciao
EDIT: Questa dovrebbe essere la versione corretta, prima avevo fatto un errore :fagiano:
se risolve il bug e hai pronto un test chiaro e pulito direi che potresti fare commit... Facci vedere il test prima semmai :D
Dunque, io invece ho creato TestBigGemExtension.java estraendo da TestBigGemInGrid.java tutti i metodi relativi all'estensione delle bigGem. Ho lasciato per ora i metodi riportati nel post precedente, ma se nessuno implora pietà per loro entro qualche giorno penso li farò sparire, o meglio li sostituisco con qualcosa di sensato :D
Ho separato i test, estraendo il codice comune, ora ognuno testa una sola cosa. In particolare quelli che esercitano il bug (dato che poteva accadere sia a destra che a sinistra) sono testBigGemExistsAfterLeftExtension e testBigGemExistsAfterRightExtension.
Credo non sia ancora la soluzione ottimale, si può fare di meglio, ma allo stato attuale c'è da cambiare troppa roba (e io coi test non sono ancora ferratissimo, anche se ci sto prendendo la mano), quindi penso che prima darò un'occhiata ancora a TestBigGemInGrid per semplificare le cose.
AnonimoVeneziano
03-02-2008, 16:39
Ecco il test per il problema della moveDown() :
public void testGemDroppingWithAGravityMoreThanOneCellPerIteration() {
grid = controller.getGrid();
grid.setGravity(Cell.SIZE_IN_PIXELS*4);
Gem gemtodrop = createGem(DIAMOND);
float destination = grid.getRowUpperBound(13);
insertAndUpdate(createGem(EMERALD), 13,1);
insertAndUpdate(gemtodrop, 12,1);
insertAndUpdate(createChest(EMERALD),13,2);
grid.updateCrushes();
grid.doIteration(new UpdateFallsAction(grid, null));
assertTrue(gemtodrop.getSprite().getPosition().getY() == destination);
}
Ammetto di essermi lasciato un po' andare col nome .... :asd:
e poi chi si ricorda più di riportarlo al livello di gravità corretto quando sarà ora di sistemarlo? gravità del bug e priorità sono due cose diverse, quindi potremmo indicizzarli in base ad ambedue i parametri anziché solo in base alla gravità (è solo un'idea, se non siete d'accordo non fa nulla).
Me lo ricordo io, perchè è una cosa collegata ad una delle prossime storie :p
Alla fine secondo me è un pò ridondante usare due parametri per classificarli invece di uno solo (ai bug meno gravi quasi sempre conviene pensarci dopo aver risolto quelli più seri) ;)
AnonimoVeneziano
03-02-2008, 17:59
Allora io committo :asd:
Spero di avere ancora tutte le dita a fine giornata :sofico:
Hai fatto i tuoi commit?
Visto. Buona notte :)
(ma dove sei?)
Sono ad Irvine California fino al 26 Marzo :D :D
In sede a fare un po' di cosine ;)
Allora io committo :asd:
Spero di avere ancora tutte le dita a fine giornata :sofico:
Ma non bastava fare:
if(notFullGravity) {
y = underTopY - droppable.getHeight*Cell.SIZE_INPIXELS
}
:wtf: ??
AnonimoVeneziano
03-02-2008, 21:12
Ma non bastava fare:
if(notFullGravity) {
y = underTopY - droppable.getHeight*Cell.SIZE_INPIXELS
}
:wtf: ??
Voglio provare quello che hai scritto
Cos'è "underTopY"?
Ciao
Voglio provare quello che hai scritto
Cos'è "underTopY"?
Ciao
Il limite contro cui non possono andare, o il gridBottom, o il top della gemma che hanno sotto ;)
AnonimoVeneziano
03-02-2008, 21:22
Il limite contro cui non possono andare, o il gridBottom, o il top della gemma che hanno sotto ;)
Il problema è : come lo pigli quel limite? E' per questo che ho messo il while() per far scendere la gemma di una casella per volta e poi andare a controllare se è arrivata destinazione o meno .
Adesso non mi ricordo tutti i ragionamenti che ho fatto , ma non mi sembrava ci fosse un metodo facile e senza cicli per verificarlo con i dati a disposizione in AbstractDroppable .
Hai un idea di come fare? O forse c'è proprio un metodo che ritorna proprio quello ma che mi è sfuggito :D (Possibilissimo :p)
Ciao
AnonimoVeneziano
03-02-2008, 21:46
vado a letto.
Se si trova un modo migliore siete liberi di rifattorizzare :fagiano:
Ciao e sogni d'oro :D
Il problema è : come lo pigli quel limite? E' per questo che ho messo il while() per far scendere la gemma di una casella per volta e poi andare a controllare se è arrivata destinazione o meno .
Adesso non mi ricordo tutti i ragionamenti che ho fatto , ma non mi sembrava ci fosse un metodo facile e senza cicli per verificarlo con i dati a disposizione in AbstractDroppable .
Hai un idea di come fare? O forse c'è proprio un metodo che ritorna proprio quello ma che mi è sfuggito :D (Possibilissimo :p)
Ciao
Ci guardo... può essere ch tu abbia ragione ;)
Mi sono perso nel mio refactor di TestGrid... e non ci ho ancora guardato :(
In ogni caso ho un bug: non trovato giocando ma guardando nel codice.
Siccome però non so se lo sia o no, lascio giudicare a voi.
public boolean mergeUp(Grid grid)
{
if((getRegion().getTopRow() - 1) < 0)
{
return false;
}
...
}
public boolean mergeRight(Grid grid)
{
...
}
E normale che uno abbia un controllo all'inizio e uno no??
Se non c'è il bug... allora dove cavolo è il controllo che non è qua??
Urge pulizia :D
EDIT:
Alt... al primo che pensa di scrivere un test, si chieda prima se è sicuro che non ci sono altri n-mila test su quesi metodi che hanno bisogno di refactoring!
Alt... al primo che pensa di scrivere un test, si chieda prima se è sicuro che non ci sono altri n-mila test su quesi metodi che hanno bisogno di refactoring!
Ci sono sicuramente ma ce ne occupiamo attraverso il Refactor This.
Mi scrivi un semplice test che eserciti questo bug? Mi sembra molto sospetto. Non abbiate paura di aggiungere nuovi test purche' si rispettino le seguenti regole:
- Il test sia piccolo ed eserciti un solo piccolo aspetto del codice
- Il test sia in un suo test case e non usi test case gia' esistenti.
Dunque, i bug 3 e 4 sono stati annientati, si può aggiornare la lista, notizie sul 2 invece?
Dunque, i bug 3 e 4 sono stati annientati, si può aggiornare la lista, notizie sul 2 invece?
Fatto.
Per piacere, potreste segnalare qui su quali bug state lavorando (o avete lavorato)? Devo tenerne traccia nel primo post, e ricostruirlo solo da post e test - visto che per ora non stiamo trattando i bug come task veri e propri - non è che sia semplicissimo :p
Com'è la situazione per il bug di Bonfo tre post più in alto? E' saltato fuori alla fine?
Propongo una cosa:
quando un bug e` risolto postate la review in cui avete fixato il bug e Jocchan quando segna Fixed segna anche la review
Propongo una cosa:
quando un bug e` risolto postate la review in cui avete fixato il bug e Jocchan quando segna Fixed segna anche la review
Ottima proposta.
Com'è la situazione per il bug di Bonfo tre post più in alto? E' saltato fuori alla fine?
Ehm... non ci ho ancora guardato :cry: :cry:
jappilas
05-02-2008, 19:23
della flashing Gem mi stavo occupando io, e questo test
public void testFlashGemDisappearsAfterDrop()
{
insertAndUpdate(createFlashingGem(), 11, 0);
insertAndDropGemsPair();
makeAllGemsFall();
controller.update(environment.getTimer().getTime());
assertNull(grid.getDroppableAt(new Cell(11, 0)));
assertNull(grid.getDroppableAt(new Cell(13, 0)));
}
passa con una semplice modifica a makeCrush()
public void makeCrush(Grid grid)
{
DroppableList gemList;
Droppable gemToDelete = searchGemToDelete(grid);
if (gemToDelete != null)
{
gemList = grid.getAllGemsSameOf(gemToDelete);
}
else
{
gemList = new DroppableList();
}
gemList.add(this);
grid.crushDroppablesWithoutScore(gemList);
}
EDIT: per me il comportamento delle Flashing Gem sarebbe FIXED (alla rev 2623)
però notavo che le big gem avrebbero ancora qualche idiosincrasia... :confused:
Mi sono imbattuto in un interessante bug di visualizzazione.
http://img139.imageshack.us/img139/4614/incomingstoneswy0.png (http://imageshack.us)
Jocchan come vuoi che risolviamo?
In SP2T il massimo di gemme in caduta era 99.
AnonimoVeneziano
05-02-2008, 19:54
Mi sono imbattuto in un interessante bug di visualizzazione.
http://img139.imageshack.us/img139/4614/incomingstoneswy0.png (http://imageshack.us)
Jocchan come vuoi che risolviamo?
Adesso mi spieghi che combo della scuola delle sacre rote ti sei inventato :asd:
In SP2T il massimo di gemme in caduta era 99.
È la soluzione che preferisco ma volevo sentirla dire dal customer :D
Adesso mi spieghi che combo della scuola delle sacre rote ti sei inventato :asd:
È una delle tecniche segrete della scuola di Hokuto.
BigGem e' talemente tanto diventata BugGem che bisognerebbe smontarla e rifarla.
Il fatto che MergeUp e MergeRight non siano testati e' un ottimo segno :( :(
BigGem e' talemente tanto diventata BugGem che bisognerebbe smontarla e rifarla.
Il fatto che MergeUp e MergeRight non siano testati e' un ottimo segno :( :(
Siamo intervenuti pesantemente su BigGem nel finesettimana. Stasera gli do' un paio di calci volanti roteati appena arrivo a casa.
Nel frattempo mi testi MergeUp e MergeRight?
Siamo intervenuti pesantemente su BigGem nel finesettimana. Stasera gli do' un paio di calci volanti roteati appena arrivo a casa.
Nel frattempo mi testi MergeUp e MergeRight?
Ok ;)
Pero' li testo da 0, come se non ci fosse mai stato scritto un test sopra. Anche perche' mi sa che tutti i test che fanno riferimento a quella parte sono di altissimo livello, ovvero NO BUONO :D :D
EDIT: vedo gia' che sto andando a "duplicare" i test TestBigGemExtension. Ma siccome volgio fare il mulo, ragiono come se dovessi implementare i metodi da 0, poi ci pensiamo dopo al clean-Up.
Pero' segnamocelo, in modo tale che se mi scordo io se lo ricorda qualcun'altro ;)
Anche perche' incomincio ad avere piu' di 2 o 3 fronti sul quale sto lavorando :(
Mi sono imbattuto in un interessante bug di visualizzazione.
http://img139.imageshack.us/img139/4614/incomingstoneswy0.png (http://imageshack.us)
Jocchan come vuoi che risolviamo?
Limite max a 99, che già è abbastanza letale (in verità credevo che ci fosse già :mbe: ).
Ci pensi tu? Lo segno come bug di livello C: in teoria impatterebbe anche sul gameplay, ma tanto anche con 99 stone il tuo avversario è già morto e ancora non lo sa (come insegna la sacra scuola di Hokuto, del resto).
Il bug 4 si presenta ancora?
Il bug assurdo trovato da Jap quando si presenta?
Ehm... sposto in un nuovo thread!
Cose fantastiche!!!!! :muro: :muro: :muro: :muro:
http://www.hwupgrade.it/forum/showthread.php?t=1671635
http://www.hwupgrade.it/forum/showpost.php?p=20943985&postcount=85
è probabilmente un bug introdotto da qualche refactoring, c'è da scrivere il test e risolvere
Il bug 4 è fixato e ha test che lo esercitano.
Invece non ho capito che tipo di bug sia quello postato da theBol :confused:
Il bug 4 è fixato e ha test che lo esercitano.
Invece non ho capito che tipo di bug sia quello postato da theBol :confused:
le stone non completano la trasformazione in gemme
Ho trovato una possibile causa di bug.
canMoveButNotWithFullGravity fa "solo" questo controllo:
Cell cell = new Cell(
getRegion().getBottomRow() + 1,
getRegion().getLeftColumn());
return grid.isDroppableAt(cell);
Cosa succede se è una bigGem e l'ostacolo è in getRegion().getLeftColumn() + 1?
scrivi un test e vedi eheh :D
http://www.hwupgrade.it/forum/showpost.php?p=20943985&postcount=85
è probabilmente un bug introdotto da qualche refactoring, c'è da scrivere il test e risolvere
Il bug è semplicemente grafico ed a tutti gli effetti sono diventate gemme, vero?
Il bug è semplicemente grafico ed a tutti gli effetti sono diventate gemme, vero?
no(mi sono dimenticato di precisarlo).
se ci si poggia sopra un chest dello stesso colore, non vengono crushate :(
no(mi sono dimenticato di precisarlo).
se ci si poggia sopra un chest dello stesso colore, non vengono crushate :(
Allora cambio la priorità. Livello B, decisamente.
Mi aggiornate sulla situazione dei bug 1,2,5,6,7,8 per favore?
Allora cambio la priorità. Livello B, decisamente.
Mi aggiornate sulla situazione dei bug 1,2,5,6,7,8 per favore?
Per il sette ho risolto io poco fa. Sto aspettando la conferma della build machine :)
E la fedele ed efficiente buildmachine ha dato conferma alla faccia di Alberto :D
Per l'8:
Il bug penso di aver capito dov'è.
Prima con frame = 7 riusciva comunque a passare il primo if, ovvero
if(frame < 5 ) {
return;
}
mentre invece adesso ci casca dentro in pieno.
if(frame < 5 || frame >= 7) {
return;
}
Dovrei scrivere il test, ma vorrei mazzare un po' bigGem.
Spostiamo la discussione di questo nel thread dei Bug ;)
http://www.hwupgrade.it/forum/showpost.php?p=20944801&postcount=86
Scrivo test e risolvo ;)
Questo test e' gia' nella code-base:
public void testStoneReplacedAfterSeventhFrame()
{
stone.getAnimatedSprite().setCurrentFrame(7);
timer.advance(100);
grid.doIteration(action);
assertNotSame(grid.getDroppableAt(new Cell(4, 5)), stone);
}
e passa.... e sapete perche'??
grid.insertDroppable(stone, 13, 5);
:rotfl: :muro: :rotfl: :muro:
8 FIXED ;)
Al momento abbiamo un bug di livello A e due di livello B.
Ehm... mi sa che il bug di livello B sulla flashing gem è già stato risolto.
Me lo dice questo test (che non fallsice):
public void testFlashGemDisappearsAfterDrop()
{
insertAndUpdate(createFlashingGem(), 11, 0);
insertAndDropGemsPair();
makeAllGemsFall();
controller.update(environment.getTimer().getTime());
assertNull(grid.getDroppableAt(new Cell(11, 0)));
assertNull(grid.getDroppableAt(new Cell(13, 0)));
}
Ehm... mi sa che il bug di livello B sulla flashing gem è già stato risolto.
Me lo dice questo test (che non fallsice):
Ottimo :)
Chi dobbiamo ringraziare per averlo risolto?
Ehm... mi sa che il bug di livello B sulla flashing gem è già stato risolto.
Me lo dice questo test (che non fallsice):
Si puo` rendere piu` leggibile questo test? Non capisco cosa faccia!
Si puo` rendere piu` leggibile questo test? Non capisco cosa faccia!
Da come l'ho inteso io crea una flashing, la fa cadere, al termine della caduta attende un update e poi due assert controllano che non sia più nè sul fondo nè nella cella in cui era stata inserita.
In realtà forse l'assert sul punto di inserimento è un pò ridondante (se esiste già un test che fa questo controllo), però boh.
Cosa c'entra la gemsPair?
Cosa c'entra la gemsPair?
Tagliandola via il test fallisce? In teoria non dovrebbe, visto che le assert riguardano solo la flashing.
E' necessaria per qualche metodo, tipo makeAllGemsFall() ?
EDIT: Se la taglio fallisce assertNull(grid.getDroppableAt(new Cell(13, 0))); ovvero l'assert più importante dei due.
EDIT 2: http://www.hwupgrade.it/forum/showpost.php?p=20939974&postcount=116
jappilas
19-02-2008, 16:24
descrizione: il gioco parte anche se nel menu si sceglie di quittare
gravità: bassa, non compromette il gameplay ma...
causa: il refactoring di GameLoop / Menu Loop in corso
EDIT: è interessante notare come si sia ripresa un' idea a cui avevo lavorato anch' io l' anno scorso (http://www.hwupgrade.it/forum/showpost.php?p=16292126&postcount=34) e che poi avevo messo da parte proprio per la difficoltà di gestire l' avvicendamento tra questi due oggetti a livello di codice e di test ( soprattutto di integrarlo in TDD nella test base che si aveva all' epoca - uno dei motivi per cui si era iniziata l' atomicizzazione dei test)
EDIT: è interessante notare come si sia ripresa un' idea a cui avevo lavorato anch' io l' anno scorso (http://www.hwupgrade.it/forum/showpost.php?p=16292126&postcount=34) e che poi avevo messo da parte proprio per la difficoltà di gestire l' avvicendamento tra questi due oggetti a livello di codice e di test ( soprattutto di integrarlo in TDD nella test base che si aveva all' epoca - uno dei motivi per cui si era iniziata l' atomicizzazione dei test)
http://i30.tinypic.com/20pc01s.jpg
Aggiunto il bug segnalato da Jappilas.
A che punto siamo col bug 2? E' di livello A, dobbiamo sistemarlo assolutamente.
descrizione: il gioco parte anche se nel menu si sceglie di quittare
gravità: bassa, non compromette il gameplay ma...
causa: il refactoring di GameLoop / Menu Loop in corso
EDIT: è interessante notare come si sia ripresa un' idea a cui avevo lavorato anch' io l' anno scorso (http://www.hwupgrade.it/forum/showpost.php?p=16292126&postcount=34) e che poi avevo messo da parte proprio per la difficoltà di gestire l' avvicendamento tra questi due oggetti a livello di codice e di test ( soprattutto di integrarlo in TDD nella test base che si aveva all' epoca - uno dei motivi per cui si era iniziata l' atomicizzazione dei test)
Colpa mia che ho fatto un commit prima di finire completamente il refactoring di GameLoop. Appena trovo una soluzione che non implichi la costruzione del ponte sullo stretto ci penso io a risolverlo.
Aggiunto il bug segnalato da Jappilas.
A che punto siamo col bug 2? E' di livello A, dobbiamo sistemarlo assolutamente.
Appena fare i test sara' molto piu' semplice li risoviamo tutti in 5 minuti! :D :D
jappilas
19-02-2008, 19:55
http://i30.tinypic.com/20pc01s.jpgCVD :rolleyes:
Appena fare i test sara' molto piu' semplice li risoviamo tutti in 5 minuti! :D :D
:cool:
Nuovo bug di livello B scovato da Jappi :)
http://www.hwupgrade.it/forum/showpost.php?p=21206538&postcount=270
Ciao ragazzi,
come va? Mi piacerebbe ridare la mia disponibilità per il progetto. Qualcuno mi può spiegare lo stato attuale del lavoro? Essenzialmente che obiettivo è attualmente perseguito?
Ciao ragazzi,
come va? Mi piacerebbe ridare la mia disponibilità per il progetto. Qualcuno mi può spiegare lo stato attuale del lavoro? Essenzialmente che obiettivo è attualmente perseguito?
Principalmente si sta facendo refactoring per migliorare il codice che era diventato una discarica. Soprattutto i test hanno bisogno di tanto amore e affetto perché nell'ultimo periodo ci siamo lasciati andare e li abbiamo scritti con i piedi.
Ciao ragazzi,
come va? Mi piacerebbe ridare la mia disponibilità per il progetto. Qualcuno mi può spiegare lo stato attuale del lavoro? Essenzialmente che obiettivo è attualmente perseguito?
Ciao Raffaele. Non manca tanto per avere la codebase in uno stato usabile per tornare in produzione.
Direi un paio di settimane al massimo, non di piu'.
Poi inizieremo con qualche task semplice per riprendere il ritmo e, infine, l'ultimo task complesso: il netcode.
Che meraviglia ritrovarvi tutti qua. Mi fate tornare in mente tempi ormai fuggiti via.
Allora facciamo così. Vi seguo in questi giorni e appena sono pronti i task di produzione mi fate un fischio ;)
Che meraviglia ritrovarvi tutti qua. Mi fate tornare in mente tempi ormai fuggiti via.
Allora facciamo così. Vi seguo in questi giorni e appena sono pronti i task di produzione mi fate un fischio ;)
Facciamo invece cosi': scarichi l'ultima build, cerchi un REFACTOR THIS semplice e lo risolvi :)
ho provato il gioco, se si comporta in maniera strana. La musica parte appena parte il gioco, e non quando si sceglie il 1vs1, e le gemme partono accelerate per la durata in cui si è stati nel menu :muro:
fino a ieri sera non mi dava il problema(ma non facevo update da qualche giorno)
potete verificare se lo fa anche a voi?
trovato il colpevole :sofico:
prima
public final class Game
{
private void start() throws IOException
{
Environment environment = new Environment();
MenuLoop menuLoop = new MenuLoop(environment);
menuLoop.loop();
GameLoop gameLoop = new GameLoop(environment);
gameLoop.loop();
gameLoop.shutDown();
}
dopo
private void start() throws IOException
{
Environment environment = new Environment();
MenuLoop menuLoop = new MenuLoop(environment);
GameLoop gameLoop = new GameLoop(environment);
AbstractLoop currentLoop = menuLoop;
menuLoop.setNextLoop(gameLoop);
gameLoop.setNextLoop(gameLoop);
do
{
currentLoop.loop();
currentLoop = currentLoop.getNextLoop();
}
while(!currentLoop.isFinished());
gameLoop.shutDown();
}
il commento di vicius è
fixed the Game/*Loop bug that I introduced during the refactoring
non so a che bug si riferisca, magari che partisse la musica dal menu era voluto, ma cmq rimane il bug che le gemme partono prima di entrare in game.
ps.Stavo lavorando per testare la classe Game. La mia idea era modificare il metodo start in maniera che accettasse come parametro Environment. Poi lo si può richiamare da un test con il mockEnvironment e provare a testarlo
spiegazione dei 2 bug.
La musica viene fatta partire alla creazione di gameLoop, per cui creandolo subito, lei parte.
Quando il gameLoop viene creato si memorizza un timeStamp con cui poi fai calcoli per il refresh dell'input e dell'update delle griglie dei playField.
:doh: Così imparo a testare il gioco senza audio!
Il fatto delle gemme invece non ci avevo fatto caso. Sicuramente è dovuto al timestamp che viene inizializzato nel costruttore. Dici che aggiungendo una resetTimestamps prima di far partire il loop potrebbe risolvere?
:doh: Così imparo a testare il gioco senza audio!
Il fatto delle gemme invece non ci avevo fatto caso. Sicuramente è dovuto al timestamp che viene inizializzato nel costruttore. Dici che aggiungendo una resetTimestamps prima di far partire il loop potrebbe risolvere?
una domanda. Che bug risolve questa tua modifica?
Prima il gioco partiva anche se si premeva Quit nel menu.
Per risolvere tutti e due i bug per ora ho fatto così:
do
{
currentLoop.beforeLoopStart();
currentLoop.loop();
currentLoop = currentLoop.getNextLoop();
}
while(!currentLoop.isFinished());
la nuova funzione di AbstractLoop se la implementano come gli pare i vari loop. In Menu è vuota, in Game ci sono le due righe con startNewGame e startMusic.
Prima il gioco partiva anche se si premeva Quit nel menu.
Bug che non è stato risolto. Sto storia dei menu mi sta facendo uscire matto. Fra un po' lo tolgo se continua così! :mad:
Prima il gioco partiva anche se si premeva Quit nel menu.
Per risolvere tutti e due i bug per ora ho fatto così:
do
{
currentLoop.beforeLoopStart();
currentLoop.loop();
currentLoop = currentLoop.getNextLoop();
}
while(!currentLoop.isFinished());
la nuova funzione di AbstractLoop se la implementano come gli pare i vari loop. In Menu è vuota, in Game ci sono le due righe con startNewGame e startMusic.
propongo un altra soluzione:
il MenuActionVersusModeinvece di fare
loop.exitLoop();
può fare lei
GameLoop gameLoop = new GameLoop(environment);
loop.setNextLoop(gameLoop);
gameLoop.setNextLoop(gameLoop);
menuLoop.exitLoop();
Il menuActionQuit invece diveneterbbe
loop.setNextLoop(loop);
loop.exitLoop();
Game.start diventerebbe
Environment environment = new Environment();
MenuLoop currentLoop= new MenuLoop(environment);
do
{
currentLoop.loop();
currentLoop = currentLoop.getNextLoop();
}
while(!currentLoop.isFinished());
shutDown();
la shutDown la porterei in Game(e lei che crea l'environment, e giusto che sia lei che lo distrugga).
in queta manierà sarebbero i menuItem a guidare quello che succede
L'unico prob con questo approccio e che i menuItem non hanno accesso all'envirnoment, ma basterebbe passarglielo..
Per far arrivare l'environment alle menuAction, basta salvarselo in MainMenu, che ora nel costruttore prende un Engine, ma gli si può passare un Environment
jappilas
01-03-2008, 13:02
credo sia meglio creare i due Loop (Menu e Game) all' inizio e una tantum, e mi pare che fare il binding del nextLoop a runtime dalle menu action, sia inutile complessità aggiunta :stordita:
il problema è l' avvicendamento del MenuLoop con sè stesso nel caso di uscita dal gioco, per permettere al MenuLoop di rispondere correttamente alla condizione di loop do - while - ma questo potrebbe essere risolto a monte delegando la conoscenza dello stato di esecuzione (normale / "quitting") a un oggetto sterno ai Loop ( *ad esempio*, Environment stesso )
do
{
currentLoop.beforeLoopStart();
currentLoop.loop();
currentLoop = currentLoop.getNextLoop();
}
while(environment.isLoopContinuationEnabled()); // o equivalente
d' altra parte è vero che MenuActionQuit dovrà sia far uscire il MenuLoop dal ciclo (menuLoop.exitLoop()) sia impostare l' uscita dal gioco (con un' eventuale "menuloop.quitGame()", che a sua volta potrebbe chiamare environment.disableLoopContinuation() la quale desetta la flag interna...)
OS: Windows Vista
Version: 6.0
Architecture: x86
VM Vendor: Sun Microsystems Inc.
Version: 1.6.0_03
Class Path: D:\sviluppo software\workspace_diamonds\Diamonds\bin;D:\sviluppo software\workspace_diamonds\Diamonds\lib\junit.jar;D:\sviluppo software\workspace_diamonds\Diamonds\lib\jar\lwjgl.jar;D:\sviluppo software\workspace_diamonds\Diamonds\lib\jar\lwjgl_devil.jar;D:\sviluppo software\workspace_diamonds\Diamonds\lib\jar\lwjgl_util.jar;D:\sviluppo software\workspace_diamonds\Diamonds\lib\jar\jorbis-0.0.15.jar;D:\sviluppo software\workspace_diamonds\Diamonds\lib\jar\trb.jar;D:\sviluppo software\workspace_diamonds\Diamonds\lib\jar\jogg-0.0.7.jar
JNI Library Path: D:\sviluppo software\workspace_diamonds\Diamonds\lib\win32
Exception: class java.util.ConcurrentModificationException
Message: null
Display Adapter Driver: vga 6.0.6000.16386
Stacktrace:
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at it.diamonds.grid.Grid.runIteration(Grid.java:519)
at it.diamonds.grid.state.StoneTurnState.update(StoneTurnState.java:25)
at it.diamonds.grid.GridController.update(GridController.java:142)
at it.diamonds.PlayField.updatePlayField(PlayField.java:232)
at it.diamonds.PlayField.update(PlayField.java:113)
at it.diamonds.GameLoop.updateState(GameLoop.java:175)
at it.diamonds.AbstractLoop.loopStep(AbstractLoop.java:94)
at it.diamonds.AbstractLoop.loop(AbstractLoop.java:84)
at it.diamonds.Game.start(Game.java:23)
at it.diamonds.Game.main(Game.java:37)
per replicarlo premete iniziate a giocare e poi tenete premuto giu e sx.
Quando il gioco sta per andare in gameOver sull'altro playField il gioco va in crash :(
ps:non facilitate il gameOver sull'altro playField facendo scendere le gemme piu velocemente, così il bug sembra non manifestarsi
pps: il bug si manifesta anche in altre situazioni, in cui si fa scendere la pair e la si muove a casaccio su entrambi i playField
ppps:altra cosa, quando il gioco crasha, non esce da solo(la musica continua ad andare)
^TiGeRShArK^
01-03-2008, 15:43
La versione a 64 bit per linux che si scarica dal sito è corrotta..
occupa solo 700 e passa KB...
OS: Windows Vista
Version: 6.0
Architecture: x86
VM Vendor: Sun Microsystems Inc.
Version: 1.6.0_03
Class Path: D:\sviluppo software\workspace_diamonds\Diamonds\bin;D:\sviluppo software\workspace_diamonds\Diamonds\lib\junit.jar;D:\sviluppo software\workspace_diamonds\Diamonds\lib\jar\lwjgl.jar;D:\sviluppo software\workspace_diamonds\Diamonds\lib\jar\lwjgl_devil.jar;D:\sviluppo software\workspace_diamonds\Diamonds\lib\jar\lwjgl_util.jar;D:\sviluppo software\workspace_diamonds\Diamonds\lib\jar\jorbis-0.0.15.jar;D:\sviluppo software\workspace_diamonds\Diamonds\lib\jar\trb.jar;D:\sviluppo software\workspace_diamonds\Diamonds\lib\jar\jogg-0.0.7.jar
JNI Library Path: D:\sviluppo software\workspace_diamonds\Diamonds\lib\win32
Exception: class java.util.ConcurrentModificationException
Message: null
Display Adapter Driver: vga 6.0.6000.16386
Stacktrace:
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at it.diamonds.grid.Grid.runIteration(Grid.java:519)
at it.diamonds.grid.state.StoneTurnState.update(StoneTurnState.java:25)
at it.diamonds.grid.GridController.update(GridController.java:142)
at it.diamonds.PlayField.updatePlayField(PlayField.java:232)
at it.diamonds.PlayField.update(PlayField.java:113)
at it.diamonds.GameLoop.updateState(GameLoop.java:175)
at it.diamonds.AbstractLoop.loopStep(AbstractLoop.java:94)
at it.diamonds.AbstractLoop.loop(AbstractLoop.java:84)
at it.diamonds.Game.start(Game.java:23)
at it.diamonds.Game.main(Game.java:37)
per replicarlo premete iniziate a giocare e poi tenete premuto giu e sx.
Quando il gioco sta per andare in gameOver sull'altro playField il gioco va in crash :(
ps:non facilitate il gameOver sull'altro playField facendo scendere le gemme piu velocemente, così il bug sembra non manifestarsi
pps: il bug si manifesta anche in altre situazioni, in cui si fa scendere la pair e la si muove a casaccio su entrambi i playField
ppps:altra cosa, quando il gioco crasha, non esce da solo(la musica continua ad andare)
C'entra mica con le nuove stone?
si il bug interessa la transformingStone.
infatti per farlo venir fuori basta far venire fuori una stone e aspettare che cerchi di trasformarsi in gemma....
il fatto di aver trovato il bug in maniera "random" me lo faceva pensare come se fosse un bug random :muro:
C'entra mica con le nuove stone?
e il motivo è anche banale...
cercando di togliere una stone dalla griglia e sostituirla con una transforming stone dentro un iterazione sulla griglia fa BOOOOM
il giro del grid.runIteration per me è da rivedere...anche togliere il for each e mettere un banale ciclo for senza iterator, non elimina il problema di trovarsi poi l'array di droppable de sincronizato.
Si potrebbe fare una roba tipo per il garbagecollector delle gemme eliminate, ma piu generalizzato, ma poi mi sembrerebbe di fare delle insert e delete su db e poi chiamare la commit...
Oppure le droppableIteration non modificano la griglia, ma penso risulti troppo limitante..
Si potrebbe fare una roba tipo per il garbagecollector delle gemme eliminate, ma piu generalizzato, ma poi mi sembrerebbe di fare delle insert e delete su db e poi chiamare la commit...
per quanto riguarda questa soluzione, la "commit" potrebbe essere lanciata dal metodo runIterator di Grid. In questa maniera, all'interno di un iterazione le modifiche alla griglia non si vedono, ma all'iterazione successiva si vedranno(si potrebbe gia provare a mettere il garbagecollector in runIterator per vedere se quest'idea funziona, cosi si evita anche di doverlo per forza chiamare dopo un iterazione in cui si cancellano droppable)
jappilas
01-03-2008, 21:42
uhm, e chiamare semplicemente la transform() in Grid.updateStones(), sostituendo direttamente l' oggetto senza passare per rimozioni / inserimenti espliciti) ?
for (Droppable gem : droppableList)
{
gem = gem.transform();
}
sbaglierò ma se si modifica il contenuto dell' elemento corrente della lista e non la lista stessa, non dovrebbe saltare... :stordita:
uhm, e chiamare semplicemente la transform() in Grid.updateStones(), sostituendo direttamente l' oggetto senza passare per rimozioni / inserimenti espliciti) ?
for (Droppable gem : droppableList)
{
gem = gem.transform();
}
sbaglierò ma se si modifica del contenuto dell' elemento corrente della lista e non la lista stessa, non dovrebbe saltare... :stordita:
se la transform modifica l'oggetto si, funziona. Basta non toccare aggiungere/togliere elementi alla collection/array
propongo un altra soluzione:
il MenuActionVersusModeinvece di fare
loop.exitLoop();
può fare lei
GameLoop gameLoop = new GameLoop(environment);
loop.setNextLoop(gameLoop);
gameLoop.setNextLoop(gameLoop);
menuLoop.exitLoop();
Il menuActionQuit invece diveneterbbe
loop.setNextLoop(loop);
loop.exitLoop();
Game.start diventerebbe
Environment environment = new Environment();
MenuLoop currentLoop= new MenuLoop(environment);
do
{
currentLoop.loop();
currentLoop = currentLoop.getNextLoop();
}
while(!currentLoop.isFinished());
shutDown();
la shutDown la porterei in Game(e lei che crea l'environment, e giusto che sia lei che lo distrugga).
in queta manierà sarebbero i menuItem a guidare quello che succede
L'unico prob con questo approccio e che i menuItem non hanno accesso all'envirnoment, ma basterebbe passarglielo..
ho implementato questa soluzione.
Ho trovato però un problema. Inizializando il gameLoop su un evento scatenato da un input(all interno del ciclo InputDevice.notify(Event event) di LWJGLKeyboard) mi dava l'ormai famoso concurrentModificationException, perchè alla creazione del gameLoop vengono settati dei listener sulla LWJGLKeyboard, per cui da eccezione.
Per risolvere il problema ho posticipato il setListener(Listener listener), facendolo settare a una lista temporanea. Questa lista viene poi riversata nella lista dei listener principali quando viene notificato un evento.
La soluzione ora funziona(il quit sul menu funziona, la musica parte quando parte il gioco, e il gioco parte correttamente).
Ditemi voi se merita di stare su svn
Hai scritto i test che esercitano il bug?
Hai scritto i test che esercitano il bug?
game non è ancora testata (avevo in progetto di farlo... ma non è immediato perchè va creato un thread su cui lanciare il game.start, visto che il metodo si inlooppa), per cui no i test non li ho fatti.
Fra l'altro non ho manco testato le modifiche fatte, diciamo che ho fatto uno spike per vedere se tutto stava in piedi (vedi problema sul notify della keyboard).
Prima di committare il tutto cmq rifaccio tutto TDD(eccetto Game)
game non è ancora testata (avevo in progetto di farlo... ma non è immediato perchè va creato un thread su cui lanciare il game.start, visto che il metodo si inlooppa), per cui no i test non li ho fatti.
Fra l'altro non ho manco testato le modifiche fatte, diciamo che ho fatto uno spike per vedere se tutto stava in piedi (vedi problema sul notify della keyboard).
Prima di committare il tutto cmq rifaccio tutto TDD(eccetto Game)
Ok, puoi anche testare Game per favore? Eventualmente usa dei Mock.
Ok, puoi anche testare Game per favore? Eventualmente usa dei Mock.
è uno sporco lavoro...ma qualcuno lo deve pur fare...
public void testShutDown()
{
thread = runAndSleep(getRunnableStart(), 50);
joinAndFailIfNotAlive(thread, 50);
game.shutDown();
joinAndFailIfStillAlive(thread, 50);
}
public void testGameCreatedWithMenuLoop()
{
assertTrue(game.getCurrentLoop() instanceof MenuLoop);
}
public void testMusicNotStartd()
{
thread = runAndSleep(getRunnableStart(), 50);
assertFalse(environment.getAudio().isMusicPlaying());
}
public void testEnterKeySetGameLoop()
{
thread = runAndSleep(getRunnableStart(), 50);
environment.getKeyboard().notify(Event.create(Code.KEY_ENTER, State.RELEASED));
joinAndFailIfNotAlive(thread, 50);
assertTrue(game.getCurrentLoop() instanceof GameLoop);
}
public void testGameNotStartedBeforeEnterKeyPressed()
{
thread = runAndSleep(getRunnableStart(), 50);
assertFalse(mockEngine.isImageCreated(GameLoop.BACKGROUND));
}
l'unica idea che mi è venuta per controllare se gameLoop fosse creato prima di essere selezionato, è di controllare che il backGround di gameLoop comparsse fra le immagini nell'engine. Non è un test stabilissimo....fra l'altro anche testMusicNotStartd fa + o - la stessa cosa...
ps.ho provato a togliere loop da AbstractLoop e a far gestire il loop infinito solo a Game.
do
{
currentLoop.loopStep();
sleepOneMillisecond();
if (currentLoop.isFinished()) {
currentLoop = currentLoop.getNextLoop();
}
}
while (currentLoop != null && !currentLoop.isFinished());
Il tutto continua a funzionare perfettamente (compresi i test) e abbiamo spostato il loop dell'applicazione un astrazione più in alto(bene/male)
Questo potrebbe esserci utile per implmentare un metodo loopStep direttamente in Game e testare principalmente quello, che non essendo un loop infinito e molto più facile da maneggiare.
l'unica idea che mi è venuta per controllare se gameLoop fosse creato prima di essere selezionato, è di controllare che il backGround di gameLoop comparsse fra le immagini nell'engine. Non è un test stabilissimo....fra l'altro anche testMusicNotStartd fa + o - la stessa cosa...
Molto bene per i test. Quest'ultimo test invece non mi piace perche' lo lega ad un'implementazione interna. Prova qualcosa di diverso.
ps.ho provato a togliere loop da AbstractLoop e a far gestire il loop infinito solo a GIl tutto continua a funzionare perfettamente (compresi i test) e abbiamo spostato il loop dell'applicazione un astrazione più in alto(bene/male)
Questo potrebbe esserci utile per implmentare un metodo loopStep direttamente in Game e testare principalmente quello, che non essendo un loop infinito e molto più facile da maneggiare.
Molto bene qui.
Molto bene per i test. Quest'ultimo test invece non mi piace perche' lo lega ad un'implementazione interna. Prova qualcosa di diverso.
Molto bene qui.
forse spostando il loop un livello sopra riesco a tirare fuori qualcosa di meglio.
ps. posso committare che incomincio ad avere un po troppe modifiche in uscita?
pps.posso disabilitare il controllo in checkStyle che fa si che le classi abstract debbano incominciare con Abstract? AbstractInputDevice fa cagare e AbstractKeyboard fanno cagare :(
forse spostando il loop un livello sopra riesco a tirare fuori qualcosa di meglio.
ps. posso committare che incomincio ad avere un po troppe modifiche in uscita?
pps.posso disabilitare il controllo in checkStyle che fa si che le classi abstract debbano incominciare con Abstract? AbstractInputDevice fa cagare e AbstractKeyboard fanno cagare :(
Committa pure e disabilita' quel controllo, lo odio anch'io.
AbstractInputDevice fa cagare e AbstractKeyboard fanno cagare :(
Fanno cagare a spruzzo proprio
Committa pure e disabilita' quel controllo, lo odio anch'io.
io il mio problema l'ho risolto introducendo una classe AbstractKeyboard (senza toccare le interfaccie gia esistenti...)
però dai il controllo lo toglo lo stesso :p (appena riesco a committare, ci sono quasi).
ps. fra l'altro ho introdotto una classe abstractKeyboard, e ho notato che si può tirare fuori un bel po di roba da LWJGLKeyboard nell'abstract per poi poterla testare (ora LWJGLKeyboard nn è testata)
ps ho commitatto. Manca ancora qualche test... vedo di farlo per stasera
Ottimo! Tira fuori quello che puoi.
però dai il controllo lo toglo lo stesso :p
:yeah: :yeah:
faccio notare come ci sia ancora il bug sulle tranforming stone...
Molto bene per i test. Quest'ultimo test invece non mi piace perche' lo lega ad un'implementazione interna. Prova qualcosa di diverso.
questo è il max che sono riuscito a ottenere
public void testGameNotStartedBeforeEnterKeyPressed()
{
game.loopStep();
environment.getTimer().advance(1000);
environment.getKeyboard().notify(Event.create(Code.KEY_ENTER, State.RELEASED));
game.loopStep();
environment.getKeyboard().notify(Event.create(Code.KEY_LEFT, State.PRESSED));
game.loopStep();
GameLoop gameLoop = (GameLoop)game.getCurrentLoop();
assertEquals(gameLoop.getPlayFieldTwo().getGridController().getGemsPair().getPivot().getRegion().getLeftColumn(), 4);
}
praticamente testa che il timer per l'inputRate dei playField del gameLoop
non siano a 0 o cmq creati prima dell'
environment.getTimer().advance(1000);
infatti in questo caso, l'evento generato dal tasto left sarebbe letto e la gemsPari si troverebbe nella colonna 3 e non nella 4.
Ho provato col bug attivato e in effetti il test fallisce:cool:
6) Penso di averlo fixato (forse ;D )
public void testBigGemMoveDownNoFullGravity()
{
grid.setGravity(Cell.SIZE_IN_PIXELS * 3 / 4);
grid.insertDroppable(createGem(DroppableColor.DIAMOND), 13, 4);
insert2x2BigGem(EMERALD, 10, 3);
grid.updateBigGems();
Droppable bigGem = grid.getDroppableAt(Cell.create(10, 3));
bigGem.moveDown(grid);
bigGem.moveDown(grid);
float bigGemTop = bigGem.getAnimatedSprite().getSprite().getPosition().getY();
assertEquals("Gem must stop at 11 row", grid.getRowUpperBound(11), bigGemTop, 0.001f);
}
Ovviamente fallisce ( notare come con grid.insertDroppable(createGem(DroppableColor.DIAMOND), 13, 3); NON fallsice)
Ecco il fix:
protected boolean canMoveButNotWithFullGravity(Grid grid)
{
float nextPositionY = getSprite().getPosition().getY() + grid.getActualGravity();
float limit = grid.getRowUpperBound(grid.getNumberOfRows() - getRegion().getHeight());
if (nextPositionY > limit)
{
return true;
}
float currentRowLimit = grid.getRowUpperBound(getRegion().getTopRow());
if (nextPositionY <= currentRowLimit)
{
return false;
}
Region bottomRegion = getRegion().getAdjacentRegionByDirection(Direction.GO_DOWN);
DroppableList collidingDroppables = grid.getDroppablesInArea(bottomRegion);
return !collidingDroppables.isEmpty();
}
prima era
protected boolean canMoveButNotWithFullGravity(Grid grid)
{
float nextPositionY = getSprite().getPosition().getY() + grid.getActualGravity();
float limit = grid.getRowUpperBound(grid.getNumberOfRows() - getRegion().getHeight());
if (nextPositionY > limit)
{
return true;
}
float currentRowLimit = grid.getRowUpperBound(getRegion().getTopRow());
if (nextPositionY <= currentRowLimit)
{
return false;
}
// TODO: Bug here (see canMoveDown)
Cell cell = Cell.create(getRegion().getBottomRow() + 1, getRegion().getLeftColumn());
return grid.isDroppableAt(cell);
}
ppps:altra cosa, quando il gioco crasha, non esce da solo(la musica continua ad andare)
ho risolto anche questo bug(in caso di eccezione non veniva fatto lo shutdown dell'engine, della keyboard e dell'audio.
per testarlo proverò a lanciare il metodo main di Game, che è quello che contiene il try-catch incriminato...però ho i miei dubbi di riuscire a testarlo.
Si potrebbe estrarre il try-catch in un metodo di istanza di main, ma cmq la creazione di environment avverrebbe nel main, e anche questa potrebbe lanciare eccezione...
se qualcuno ha qualche idea la proponga
Forse non ho capito il problema.
Non basta passargli un MockEngine, forzare una eccezione e controllare che l'engine sia stato shut-downato??
Forse non ho capito il problema.
Non basta passargli un MockEngine, forzare una eccezione e controllare che l'engine sia stato shut-downato??
ora il codice è così
public static void main(String[] args)
{
Environment environment = null;
try
{
environment = new Environment();
Game game = createGame(environment);
game.loop();
}
catch (Exception e)
{
BugReport.showDramaticMessageBox();
BugReport.writeBugReport(e);
if (environment != null)
{
environment.shutDown();
}
}
}
public static Game createGame(Environment environment)
{
if (environment == null)
{
throw new IllegalArgumentException("Cannot create Game with a null environment");
}
return new Game(new MenuLoop(environment), environment);
}
public Game(AbstractLoop absLoop, Environment environment)
{
this.currentLoop = absLoop;
this.environment = environment;
}
si potrebbe fare un costruttore vuoto per Game e un metodo start che accetti un environment, e faccia partire il gioco. Il metodo start può contenere il try-catch e questa parte diverrebbe testata.
Però per far partire il gioco realmente, bisogna instanziare l'Environment reale. E questo va sempre messo sotto try-catch, per cui il try-catch sarebbe doppio, uno che fa il catch delle eccezioni lanciate dalla creazione di environment(non testato) e uno che fa il catch delle eccezioni lanciate dalla creazione ed esecuzione del gioco(questo testato).
Altra nota, il catch usa BugReport per far venir fuori la finestra di errore e scrivere su file. BugReport ha solo metodi statici, sarebbe da trasformare in oggetto, e passarlo alla creazione di Game, cosi da poter passare un mock.
^TiGeRShArK^
05-03-2008, 08:57
faccio notare come ci sia ancora il bug sulle tranforming stone...
...finchè non finiamo il nostro refactoring mi pare difficile che scompaia come per magia :p
Il gioco e` ingiocabile. Praticamente le gemme vanno sempre giu` con stronmg gravity.
Il gioco e` ingiocabile. Praticamente le gemme vanno sempre giu` con stronmg gravity.
Ouch. Questo bug va fissato immediatamente.
Il gioco e` ingiocabile. Praticamente le gemme vanno sempre giu` con stronmg gravity.
ops
ho paura di aver capito il perchè :muro:
ps.revertato. Sul thread dei refactorthis, la spiegazione, e una possibile soluzione
Test che evidenzia il bug sulle stone:
public void testNoCuncurrentModificationOnStoneTransformation()
{
try
{
Droppable anotherStone = createStone(DIAMOND);
stone.getAnimatedSprite().setCurrentFrame(5);
anotherStone.getAnimatedSprite().setCurrentFrame(5);
grid.insertDroppable(anotherStone, 5, 0);
grid.insertDroppable(stone, 5, 2);
grid.runIteration(iteration);
}
catch (ConcurrentModificationException e)
{
fail();
}
}
per quanto riguarda questa soluzione, la "commit" potrebbe essere lanciata dal metodo runIterator di Grid. In questa maniera, all'interno di un iterazione le modifiche alla griglia non si vedono, ma all'iterazione successiva si vedranno(si potrebbe gia provare a mettere il garbagecollector in runIterator per vedere se quest'idea funziona, cosi si evita anche di doverlo per forza chiamare dopo un iterazione in cui si cancellano droppable)
Per risolvere il bug avevo pensato di seguire il suggerimento di thebol, in particolare astrarre una nuova classe che rende trasparente le operazioni di rimozione o inserimento all'interno di grid, o meglio le fa in modo sincrono se ciò è possibile, altrimenti le fa in modo asincrono appena ciò è possibile.
Considerando che oltre ad essere un bugfix è anche un refactoring, aspetto del feedback prima di procedere
Test che evidenzia il bug sulle stone:
public void testNoCuncurrentModificationOnStoneTransformation()
{
try
{
Droppable anotherStone = createStone(DIAMOND);
stone.getAnimatedSprite().setCurrentFrame(5);
anotherStone.getAnimatedSprite().setCurrentFrame(5);
grid.insertDroppable(anotherStone, 5, 0);
grid.insertDroppable(stone, 5, 2);
grid.runIteration(iteration);
}
catch (ConcurrentModificationException e)
{
fail();
}
}
Per risolvere il bug avevo pensato di seguire il suggerimento di thebol, in particolare astrarre una nuova classe che rende trasparente le operazioni di rimozione o inserimento all'interno di grid, o meglio le fa in modo sincrono se ciò è possibile, altrimenti le fa in modo asincrono appena ciò è possibile.
Considerando che oltre ad essere un bugfix è anche un refactoring, aspetto del feedback prima di procedere
cè anche qualche test da scommentare quando questo bug sarà risolto.
Cmq io ho risolto un problema simile in AbstractKeyboard
^TiGeRShArK^
08-03-2008, 17:35
Test che evidenzia il bug sulle stone:
public void testNoCuncurrentModificationOnStoneTransformation()
{
try
{
Droppable anotherStone = createStone(DIAMOND);
stone.getAnimatedSprite().setCurrentFrame(5);
anotherStone.getAnimatedSprite().setCurrentFrame(5);
grid.insertDroppable(anotherStone, 5, 0);
grid.insertDroppable(stone, 5, 2);
grid.runIteration(iteration);
}
catch (ConcurrentModificationException e)
{
fail();
}
}
Per risolvere il bug avevo pensato di seguire il suggerimento di thebol, in particolare astrarre una nuova classe che rende trasparente le operazioni di rimozione o inserimento all'interno di grid, o meglio le fa in modo sincrono se ciò è possibile, altrimenti le fa in modo asincrono appena ciò è possibile.
Considerando che oltre ad essere un bugfix è anche un refactoring, aspetto del feedback prima di procedere
mmm...
ma prima della transforming iteration come funzionava che non mi ricordo proprio?
mmm...
ma prima della transforming iteration come funzionava che non mi ricordo proprio?
c'era una action che faceva il lavoro..solo che non ricordo benissimo come lo facesse:stordita:
c'era una action che faceva il lavoro..solo che non ricordo benissimo come lo facesse:stordita:
faceva lo stesso lavoro di adesso, solo che invece di sostituire la gemma, ne cambiava solo il tipo. Per cui non c'erano problemi con l'iterator
faceva lo stesso lavoro di adesso, solo che invece di sostituire la gemma, ne cambiava solo il tipo. Per cui non c'erano problemi con l'iterator
no vabbè...ad un certo punto la sostituiva..toglieva la Stone e metteva la Gem al suo posto...
La gravità è ancora troppo forte (dopo aver cambiato i moltiplicatori della gravità qualcuno ha cambiato i valori nel config per lasciare inalterato il comportamento?). Inoltre l'ultima build ha crashato mentre giocavo, lasciando questo bug report:
OS: Windows XP
Version: 5.1
Architecture: x86
VM Vendor: Sun Microsystems Inc.
Version: 1.6.0_02
Class Path: DiamondCrush.exe
JNI Library Path: lib/win32
Exception: class java.util.ConcurrentModificationException
Message: null
Display Adapter Driver: ati2dvag 6.14.10.6606
Stacktrace:
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
at java.util.AbstractList$Itr.next(Unknown Source)
at it.diamonds.grid.Grid.runIteration(Unknown Source)
at it.diamonds.grid.state.StoneTurnState.update(Unknown Source)
at it.diamonds.grid.state.GemsPairOnControlState.update(Unknown Source)
at it.diamonds.GameTurn.update(Unknown Source)
at it.diamonds.grid.GridController.update(Unknown Source)
at it.diamonds.PlayField.updatePlayField(Unknown Source)
at it.diamonds.PlayField.update(Unknown Source)
at it.diamonds.GameLoop.updateState(Unknown Source)
at it.diamonds.AbstractLoop.loopStep(Unknown Source)
at it.diamonds.Game.loopStep(Unknown Source)
at it.diamonds.Game.loop(Unknown Source)
at it.diamonds.Game.main(Unknown Source)
ooops!!
Io dopo il mio refactoring che ha eliminato il "/2" mi sono scordato di cambiare i valori nel config.
Perdono? :flower:
^TiGeRShArK^
09-03-2008, 02:09
ooops!!
Io dopo il mio refactoring che ha eliminato il "/2" mi sono scordato di cambiare i valori nel config.
Perdono? :flower:
E' dipeso tutto dal mio cambiamento della gravity nei test immagino..
quindi dividiamoci la fustigazione a metà... :cry:
penitenziagite! :mbe:
La punizione per entrambi e' scrivere i test che controllino questa condizione. Grazie :)
S'odono lontani rumori di ginocchia sbucciate (non chiedetemi che razza di suono facciano :asd:) :D
:flower:
La punizione per entrambi e' scrivere i test che controllino questa condizione. Grazie :)
Ehm... la condizione quale?? I valori del config vanno testati??
Ehm... la condizione quale?? I valori del config vanno testati??
Joc, vuoi che vengano testati i valori della config come la gravita' o no?
Joc, vuoi che vengano testati i valori della config come la gravita' o no?
Intendi testare che i valori restino quelli attuali, o che il comportamento che deriva da quei valori rimanga lo stesso?
Io sarei per la seconda, in quanto consentirebbe refactoring come quello dell'eliminazione/modifica di qualche costante moltiplicativa ma garantirebbe una costanza del comportamento finale.
La gravità è ancora troppo forte (dopo aver cambiato i moltiplicatori della gravità qualcuno ha cambiato i valori nel config per lasciare inalterato il comportamento?). Inoltre l'ultima build ha crashato mentre giocavo, lasciando questo bug report:
OS: Windows XP
Version: 5.1
Architecture: x86
VM Vendor: Sun Microsystems Inc.
Version: 1.6.0_02
Class Path: DiamondCrush.exe
JNI Library Path: lib/win32
Exception: class java.util.ConcurrentModificationException
Message: null
Display Adapter Driver: ati2dvag 6.14.10.6606
Stacktrace:
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
at java.util.AbstractList$Itr.next(Unknown Source)
at it.diamonds.grid.Grid.runIteration(Unknown Source)
at it.diamonds.grid.state.StoneTurnState.update(Unknown Source)
at it.diamonds.grid.state.GemsPairOnControlState.update(Unknown Source)
at it.diamonds.GameTurn.update(Unknown Source)
at it.diamonds.grid.GridController.update(Unknown Source)
at it.diamonds.PlayField.updatePlayField(Unknown Source)
at it.diamonds.PlayField.update(Unknown Source)
at it.diamonds.GameLoop.updateState(Unknown Source)
at it.diamonds.AbstractLoop.loopStep(Unknown Source)
at it.diamonds.Game.loopStep(Unknown Source)
at it.diamonds.Game.loop(Unknown Source)
at it.diamonds.Game.main(Unknown Source)
:old:
non funziona la trasformazione stone->gem
io per testare il crushBox le ho dovute disattivare...
^TiGeRShArK^
10-03-2008, 09:01
Intendi testare che i valori restino quelli attuali, o che il comportamento che deriva da quei valori rimanga lo stesso?
Io sarei per la seconda, in quanto consentirebbe refactoring come quello dell'eliminazione/modifica di qualche costante moltiplicativa ma garantirebbe una costanza del comportamento finale.
ehmm...
Ma questi mi sa che sono test funzionali, non unit-testing.. :stordita:
Intendi testare che i valori restino quelli attuali, o che il comportamento che deriva da quei valori rimanga lo stesso?
Io sarei per la seconda, in quanto consentirebbe refactoring come quello dell'eliminazione/modifica di qualche costante moltiplicativa ma garantirebbe una costanza del comportamento finale.
Intendo il comportamento che ne deriva rimanga almeno coerente e giocabile.
ehmm...
Ma questi mi sa che sono test funzionali, non unit-testing.. :stordita:
Functional testing va benissimo, non siamo contro :)
Intendo il comportamento che ne deriva rimanga almeno coerente e giocabile.
Perfetto, per me va più che bene allora :)
:old:
non funziona la trasformazione stone->gem
io per testare il crushBox le ho dovute disattivare...
E' una cosa che va sistemata al più presto, visto che fa crashare il gioco in OGNI partita.
La gravità è ancora troppo forte... Bonfo, in che modo vanno sistemati i valori nel config per tornare al comportamento di prima?
Mi aggiornate sulla situazione dei bug per favore?
Ce ne sono di risolti in quelli elencati? Ce ne sono altri non risolti da elencare? Il bug numero 2, quello di livello A, che fine ha fatto? Quello doveva essere a priorità massima.
X Jocchan
il bug 10 è fixed
Oggi stavo facendo una partitina e ho notato che ogni tanto le gemspair scompaiono se vengono spostate lateralmente. Sono ancora presenti nella griglia perché dopo un po' collidono con il fondo e riappaiono. Riappaiono anche spostando a destra e a sinistra.
Inoltre sono l'unico a cui sembra che le gemspair scendano molto più velocemente del solito?
PS: Il bug 10 è stato risolto in uno dei precedenti refactoring di griglia e biggem non ricordo da chi. :)
altro possibile bug
io ho un casino sul mio workspace attualmente, ma non penso dipenda da quello.
Comunque, facendo una crush con una flashingGem, viene fuori il crushBox.
E' corretto?
X Jocchan
il bug 10 è fixed
Bene, aggiorno :)
Oggi stavo facendo una partitina e ho notato che ogni tanto le gemspair scompaiono se vengono spostate lateralmente. Sono ancora presenti nella griglia perché dopo un po' collidono con il fondo e riappaiono. Riappaiono anche spostando a destra e a sinistra.
Inoltre sono l'unico a cui sembra che le gemspair scendano molto più velocemente del solito?
PS: Il bug 10 è stato risolto in uno dei precedenti refactoring di griglia e biggem non ricordo da chi. :)
Aggiungo il bug delle gemme che spariscono (livello B).
Per la velocità aumentata bisogna fixare dei valori in config (ma dovrei sapere esattamente quali costanti moltiplicative sono cambiate nel codice per poterlo fare).
altro possibile bug
io ho un casino sul mio workspace attualmente, ma non penso dipenda da quello.
Comunque, facendo una crush con una flashingGem, viene fuori il crushBox.
E' corretto?
Intendi se la crush è innescata dalle gemme cancellate dalla flashing, ma prosegue autonomamente?
Esattamente il gioco come si comporta in quanto a punteggio e stone da mandare all'avversario in questo caso?
La gravità è ancora troppo forte... Bonfo, in che modo vanno sistemati i valori nel config per tornare al comportamento di prima?
E' un config: scegli tu quelli che ti piacciono di piu'. e' stato fatto apposta per poter modifcare il comportamento del gioco senza toccare codice.
In ogni caso penso che basti dividere per due la normalGravity.
Intendi se la crush è innescata dalle gemme cancellate dalla flashing, ma prosegue autonomamente?
Esattamente il gioco come si comporta in quanto a punteggio e stone da mandare all'avversario in questo caso?
io intendo per ora solo il crushBox, non ho testato il punteggio.
Cmq se una flashingGem cancella delle gemme, e poi dalla successiva caduta avviene una crush da chest, viene fuori nel crushBox "Nice 2x Combo".
Immagino, ma non ne sono sicuro, che anche il punteggio sia sbagliato.
E' un config: scegli tu quelli che ti piacciono di piu'. e' stato fatto apposta per poter modifcare il comportamento del gioco senza toccare codice.
In ogni caso penso che basti dividere per due la normalGravity.
Certo che serve a quello ;)
Mi serviva sapere esattamente cosa era stato modificato per non doverci arrivare a tentativi (o non arrivare affatto allo stesso valore). Grazie comunque :)
io intendo per ora solo il crushBox, non ho testato il punteggio.
Cmq se una flashingGem cancella delle gemme, e poi dalla successiva caduta avviene una crush da chest, viene fuori nel crushBox "Nice 2x Combo".
Immagino, ma non ne sono sicuro, che anche il punteggio sia sbagliato.
Quindi la cancellazione della flashing viene considerata parte della crush? Se è così allora è sbagliato, non va considerata.
Quindi la cancellazione della flashing viene considerata parte della crush? Se è così allora è sbagliato, non va considerata.
segnalo come bug
Oggi stavo facendo una partitina e ho notato che ogni tanto le gemspair scompaiono se vengono spostate lateralmente. Sono ancora presenti nella griglia perché dopo un po' collidono con il fondo e riappaiono. Riappaiono anche spostando a destra e a sinistra.
Sto cercando di trovare un modo per riprodurlo ma sembra comparire a caso. Su una ventina dipartite è capitato solo una volta e non ho idea di quale sia la causa scatenante.
Idee?
Sto cercando di trovare un modo per riprodurlo ma sembra comparire a caso. Su una ventina dipartite è capitato solo una volta e non ho idea di quale sia la causa scatenante.
Idee?
e me capita sempre, spostandole sulla priam colonna del player 2(quello che si muove con le freccette).
e me capita sempre, spostandole sulla priam colonna del player 2(quello che si muove con le freccette).
Cavolo hai ragione. In entrambe le griglie la prima colonna da sinistra fa scomparire le gemme che ci sono dentro. Quindi questo test in TestGridDrawing dovrebbe andare invece fallisce per via del bug.
public void testDrawGemsInFirstColumn()
{
grid.insertDroppable(gem, 0, 1);
gridRenderer.draw(engine);
assertEquals(2, engine.getNumberOfQuadsDrawn());
}
Una getRegion con riga e colonna 1,1! :)
Tutte le gemme che si trovavano nella prima riga e nella prima colonna non venivano passate al for per essere disegnate. Siamo dei veri pirla :p
Cosa ne pensate di usare un naming standard per i test che evidenziano i bug? Il problema e` che dopo 2 mesi uno si trova un test: testDrawGemsInFirstColumn e si chiede "perche`?"
segnalo come bug
Aggiunto al primo post.
Una getRegion con riga e colonna 1,1! :)
Tutte le gemme che si trovavano nella prima riga e nella prima colonna non venivano passate al for per essere disegnate. Siamo dei veri pirla :p
Segnato come fixed.
Cosa ne pensate di usare un naming standard per i test che evidenziano i bug? Il problema e` che dopo 2 mesi uno si trova un test: testDrawGemsInFirstColumn e si chiede "perche`?"
Hmmm. A me l'idea non piace. Al massimo si possono mettere i test dei bug in TestCase separati e dare un nome a quel TestCase che descriva il bug.
Cosa ne pensate di usare un naming standard per i test che evidenziano i bug? Il problema e` che dopo 2 mesi uno si trova un test: testDrawGemsInFirstColumn e si chiede "perche`?"
Secondo me bisogna fidarsi. Se un test c'e' ci deve essere un motivo.
Ora il punti sono 2:
- il test fa quello che dice?
- non e' il duplicato di un altro test?
Se entrambe le risposte sono si non ci sono problemi ;)
12 e 14 sono storia :cool:
Visto che Jocchan non è online ci ho pensato io a modificare il primo messaggio aggiornando la lista.
Ho sistemato il 9 Semplicemente cambiando updateState in questo modo
if (!gameOver)
{
playFieldOne.update(loopTimestamp);
checkAndShowGameOverMessage(playFieldOne, playFieldTwo);
playFieldTwo.update(loopTimestamp);
checkAndShowGameOverMessage(playFieldTwo, playFieldOne);
}
Ora il controllo avviene dopo ogni update. Ho aggiunto anche un secondo argomento a checkAndShowGameOverMessage altrimenti era impossibile mostrare il messaggio di game over su entrambe le griglie.
Il Bug numero 1 sembra essere stato risolto. Ho provato e il tasto trattino viene visto e la gemma ribaltata verticalmente. Lo segno come fixato.
Il test VIC? :P
Non sono due cose già testate? Non dovrebbe esserci bisogno di altri test :confused:
Ho sistemato il 9 Semplicemente cambiando updateState in questo modo
if (!gameOver)
{
playFieldOne.update(loopTimestamp);
checkAndShowGameOverMessage(playFieldOne, playFieldTwo);
playFieldTwo.update(loopTimestamp);
checkAndShowGameOverMessage(playFieldTwo, playFieldOne);
}
Ora il controllo avviene dopo ogni update. Ho aggiunto anche un secondo argomento a checkAndShowGameOverMessage altrimenti era impossibile mostrare il messaggio di game over su entrambe le griglie.
Il Bug numero 1 sembra essere stato risolto. Ho provato e il tasto trattino viene visto e la gemma ribaltata verticalmente. Lo segno come fixato.
se la playFieldTwo fallisce, la playFieldOne fa un passo in più.
Ripeto, secondo me non è un bug, ma un comportamento fisiologico del fatto di avere 2 playField
Non sono due cose già testate? Non dovrebbe esserci bisogno di altri test :confused:
Sono io a non capire scusa. Ho visto il tuo submit nella history e includeva solo GameLoop. Il mio ragionamento quando vedo un submit che non coinvolge alcun test e`:
1) E` stato fatto un refactoring.
2) La build era rossa ed ora e` verde.
3) E` stato fatto un commit di codice non TDD.
La mia deduzione e` stata la (3) perche` nel commento c'e` scritto FIX
Sono io a non capire scusa. Ho visto il tuo submit nella history e includeva solo GameLoop. Il mio ragionamento quando vedo un submit che non coinvolge alcun test e`:
1) E` stato fatto un refactoring.
2) La build era rossa ed ora e` verde.
3) E` stato fatto un commit di codice non TDD.
La mia deduzione e` stata la (3) perche` nel commento c'e` scritto FIX
Il codice fa quello che faceva prima. Ho solo cambiato l'ordine con cui lo faceva, che era errato, correggendo il bug. Test che controllano se la griglia rileva il gameover e mostra il messaggio ce ne sono già a bizzeffe quindi secondo me non ne servono altri.
se la playFieldTwo fallisce, la playFieldOne fa un passo in più.
Ripeto, secondo me non è un bug, ma un comportamento fisiologico del fatto di avere 2 playField
Infatti non era propriamente un bug, ma una situazione "particolare" che gestiremo correttamente quando introdurremo i pareggi.
Era segnato come bug di livello D, quindi da ignorare per il momento (ovvero: è un bug noto, quindi se salta fuori niente panico, ma NON ce ne occupiamo). Ho sistemato la definizione, così è più chiaro ;)
In generale, comunque, la priorità dei bug va rispettata SEMPRE, indipendentemente dalla complessità dei loro fix. Se ci sono bug di livello A, quelli di livello B (a meno che non spariscano per dei refactoring o per conseguenza di altre modifiche... o eventuali casi particolari) non vanno toccati, e lo stesso vale per quelli di livello C e D. La distinzione serve per questo, in fondo :)
Il codice fa quello che faceva prima. Ho solo cambiato l'ordine con cui lo faceva, che era errato, correggendo il bug. Test che controllano se la griglia rileva il gameover e mostra il messaggio ce ne sono già a bizzeffe quindi secondo me non ne servono altri.
Se c'era un bug ed hai cambiato il codice per fissarlo, ci dev'essere anche un test da qualche parte che prima falliva e dopo il tuo fix passa. Puoi scriverlo per cortesia?
Infatti non era propriamente un bug, ma una situazione "particolare" che gestiremo correttamente quando introdurremo i pareggi.
Era segnato come bug di livello D, quindi da ignorare per il momento (ovvero: è un bug noto, quindi se salta fuori niente panico, ma NON ce ne occupiamo). Ho sistemato la definizione, così è più chiaro ;)
In generale, comunque, la priorità dei bug va rispettata SEMPRE, indipendentemente dalla complessità dei loro fix. Se ci sono bug di livello A, quelli di livello B (a meno che non spariscano per dei refactoring o per conseguenza di altre modifiche... o eventuali casi particolari) non vanno toccati, e lo stesso vale per quelli di livello C e D. La distinzione serve per questo, in fondo :)
Per rinforzare meglio il concetto, questa e' la procedure per fissare bug:
- Si fissano SEMPRE i bug di priorita' A appena ne esce uno e prima di ogni refactoring, feature.
- Quando non ci sono piu' bug di priorita A, si fissano quelli di priorita' B compatibilmente con i refactoring e i task.
- Stessa cosa per i bug di livello C
- I bug di livello D si ignorano a meno che il fix non sia assolutamente banale e Jocchan sia d'accordo.
In tutti i casi si scrive un test che esercita il bug. In nessuna occasione e' permesso fissare un bug e fare il commit senza il test relativo.
Se non e' chiaro:
In nessuna occasione e' permesso fissare un bug e fare il commit senza il test relativo
O volano ditine spezzate come fossimo a Shangai :)
Se c'era un bug ed hai cambiato il codice per fissarlo, ci dev'essere anche un test da qualche parte che prima falliva e dopo il tuo fix passa. Puoi scriverlo per cortesia?
Fino a domenica sera non ho tempo di mettere mano a DC. Per ora reverto il commit e mi tengo il file modificato in locale. Quando finisco il test poi lo rimetto sul server.
In mia opinione sarebbe da mockare i due playfield per evitare di andare a testare troppo in profondita`.
Tentando di rifattorizzare il GameOverState mi sono accorto di quanto confusionali e profondi siano i test (non parlo solo di GameOver)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.