View Full Version : First Playable Lock Venerdì 21 Aprile - CHECKLIST + BUG LIST
Con il ciclo attuale, il quattordicesimo, chiuderemo finalmente la First Playable Version. E' il nostro primo traguardo, a circa metà dello sviluppo, perchè è anche la prima versione che distribuiremo.
Per questa occasione, definiremo un particolare calendario da osservare rigorosamente, ed una checklist contenente TUTTI gli obiettivi da raggiungere. La checklist è la nostra priorità, ed è assolutamente necessario riuscire a completarla in tempo.
Domenica 16 aprile 2006:
Conclusione del ciclo 14. Inizio di un periodo di 5 giorni dedicato all'impacchettamento della First Playable.
Venerdì 21 aprile 2006, ore 22:00 CET:
La First Playable viene chiusa, e ne viene preso il tag. Tutti i punti della checklist devono essere completati, e tutti i bug fixati, con tanto di test.
Sabato 22 e domenica 23 aprile 2006:
Play test. Se c'e' qualche fix fondamentale da fare, si fa e si prende un'altra tag, ma ogni singolo commit dev'essere vagliato e autorizzato.
Lunedì 24 aprile 2006:
Rilascio della First Playable Version al pubblico, con tanto di news.
P.S.: Fek spezzerà personalmente le manine al primo che proverà a fare un commit da venerdi a lunedi' :p
FIRST PLAYABLE CHECKLIST ALL GREEN
• Droppables - COMPLETE
Tipologie di gemme - PASSED
Agglomerati di gemme - PASSED
Flashing Gems - PASSED
Bauli - PASSED
Stones - PASSED
• Elementi di gameplay- COMPLETE
Griglie 8x14 - PASSED
Multiplayer offline - PASSED
Coppie di droppables - PASSED
Gravità normale - PASSED
Gravità accelerata - PASSED
Gestione tastiera - PASSED
Movimento coppie - PASSED
Rotazioni coppie - PASSED
Mirroring coppie - PASSED
Rilascio coppie - PASSED
Cancellazione gemme e bauli - PASSED
Caduta dopo una cancellazione - PASSED
Caduta degli agglomerati - PASSED
Gestione punteggio - PASSED
Crush - PASSED
Pattern Stones- PASSED
Caduta Stones- PASSED
Cancellazione Stones- PASSED
Gestione Counter Attacks- PASSED
Game over - PASSED
• Elementi di servizio - COMPLETE
Temporizzazione eventi - PASSED
GameTurn - PASSED
Sistema di logging - PASSED
Gestione delle eccezioni - PASSED
• Indicatori- COMPLETE
Box Next - PASSED
Punteggio - PASSED
Box Warning - PASSED
Incoming Stones - PASSED
Indicatori Crush - PASSED
Counter Attacks- PASSED
Game over - PASSED
• Effetti- COMPLETE
Pulsing gemme - PASSED
Animazione riflessi gemme - PASSED
Animazione riflessi bauli - PASSED
Animazione Flashing Gems - PASSED
Fade in indicatori Crush- PASSED
Fade out indicatori Crush- PASSED
• Audio- COMPLETE
Suono collisione col fondo - PASSED
Tema di Rock in loop- PASSED
Ormai ci siamo. I task da completare sono pochi quindi go go go!!! :D
Spero solo di poter tornare attivo prima dell'annuncio.
ciao ;)
BUG DA FIXARE
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 e' un piccolo problema di visualizzazione e non compromette il gameplay
D - questo bug puo' essere totalmente ignorato e la sua soluzione fa parte della wish list
FIXED - bug fixato
Bug list:
25 - Coverbug2, si veda http://www.hwupgrade.it/forum/showpost.php?p=12109257&postcount=437 A
Bug fixati per la FP v0.1a:
17 - GameOver bug: viene mostrata la scritta GameOver prima di controllare eventuali crush A FIXED(cisc)
Bug fixati per la FP v0.1:
1 - Problema con OpenAL che crasha il gioco A - FIXED (fek)
2 - Un frame di troppo prima della trasformazione in gemma B - FIXED (cionci)
3 - Talvolta le pietre non cadono a velocità accelerata, e sono controllabili B - FIXED (cionci)
4 - Talvolta il pattern non viene rispettato B FIXED (Bonfo)
5 - Il frame iniziale delle stone non viene settato in base alla profondità B FIXED (Bonfo)
6 - Quando uno dei due giocatori fa Game Over il gioco deve fermarsi 2 secondi, e resettarsi automaticamente B FIXED (TheBol)
7 - Quando le pietre si trasformano in gemme eventuali cancellazioni non avvengono subito, ma solo dopo qualche secondo C FIXED (Bonfo)
10 - Talvolta WarningBox e CounterBox si sovrappongono C FIXED (Ufo13)
11 - La WarningBox, se mostrata appena prima di un drop, sparisce subito e le Stone cadono il turno dopo. Deve invece sparire solo quando queste vengono fatte cadere C FIXED (Cisc)
13 - Le pietre trasformate in gemme non vengono considerate per la creazione di BigGem B FIXED (Bonfo)
14 - Quando una stone viene fatta cadere in una colonna piena, le gemspair smettono di cadere A FIXED (Bonfo)
15 - Le stone da inviare dopo due (o più) cancellazioni o crush immediatamente successive non vengono sommate B FIXED (Bonfo)
16 - La caduta di una BigGem BLOCCA l'area di gioco: non vengono inserite nuove gemspair ed inoltre l'eventuale CrushBox che appare non scompare più A FIXED (Bonfo)
18 - Estensioni delle bigGem: se sono presenti 2 bigGem e se ne fa una 3° che può essere inglobata in entrambe formando così una unica bigGem, vengono unite solo 2 BigGem su 3 B FIXED (cisc)
19 - Le CrushBox sono disegnate alle coordinate sbagliate C FIXED (Cover)
20 - la png Counter va mostrata anche quando la contromossa non è completa, e si riesce solo a limitare i danni, riducendo il numero di stone in arrivo C FIXED (Bonfo)
21 - Talvolta il numero da mostrare sulla stone non viene assegnato correttamente in base alla profondità B FIXED (Bonfo)
22 - A volte Diamonds si chiude più velocemente del thread che suona la musica: occorre fare un wait sull'altro thread alla fine del gameloop C FIXED (Ufo13)
23 - Dopo 20/25 minuti di gioco il gioco crasha quando va a prelevare una texture by file A FIXED (fek+cdimauro+cionci)
99 - Ridefinire i comandi nel seguente modo:
Player 1 - movimento con W,A,S,D, rotazioni in senso antiorario, orario e mirroring rispettivamente con R,T,Y.
Player 2 - movimento con i tasti direzionali, rotazioni in senso antiorario, orario e mirroring rispettivamente con Ins, Home, PgUp.
B FIXED (Cover)
Bug eliminabili dopo la First Playable:
8 - Bisogna limitare il numero massimo di pietre da inviare a 99 D
9 - Separata la gemsPair, se il tasto down è premuto, la gemma che continua a cadere sobbalza, soprattutto con strongestGravity=1 D
12 - Quando si cerca di far passare una coppia sotto una BigGem con dello spazio libero al di sotto di essa, la slave talvolta si sovrappone ad una delle caselle della BigGem. Questo può capitare anche quando la colonna centrale è piena, a Game Over avvenuto D
24 - Lasciare a lungo il gioco ridotto a icona può creare alcuni problemi di visualizzazione con alcune png D
Segnalate tutti i bug e li aggiungerò alla lista.
- Talvolta il pattern non viene rispettato B
Il problema è in CrushState:
return new StoneFallState(config, new Pattern()).update(timer, gridController);
quel new Pattern() genera ogni volta un Pattern diverso. :sofico:
Ora bisogna decidere chi ha il pattern, se gameLoop che poi lo passa oppure se i 2 PlayField ne hanno 2 diversi.
Comunque è su qeullo che bisogna lavorare ;)
Jocchan, per stasera di quei bug non ce n'è più manco uno :|
vuoi vedere...? :asd:
forza col primo...
Ho lavorato su StoneFallState e sono soddisfatto del risultato ottenuto.
Però mi è riusltato evidente un bug :(
Supponimao la prima colonna piena fino in cima. L'avversario riesce a generare anche 1 sola incoming stone...come si deve comportare il gioco??
Per ora la stone viene semplicemente non inserita.
Il test relativo a questo caso è in TestStoneFallSate: testNoStoneInsertion()
- Un frame di troppo prima della trasformazione in gemma B
Siete sicuri ?? :wtf:
Mentre giocavo non mi sembrava ;)
- Il frame iniziale delle stone non viene settato in base alla profondità B
L'ultima volta scrivo...almeno finchè non ho risolto qualche bug :asd: :asd:
Ricordo che c'è già il metodo in grid insertStoneIntoColumn() che fa già tutto...è pure testato.
Manca solo l'integrazione :D
Ma qualcuno ha risolto il primo bug ? A me non si presenta più...
Sto lavorando al terzo...ho già trovato come elimnarlo, ora devo scrivere il test...
Lo ha risolto Fek.
http://www.hwupgrade.it/forum/showpost.php?p=11992004&postcount=7
cdimauro
13-04-2006, 08:29
Si possono aggiornare la check list e la bug list?
E' possibile avere un elenco di persone e su quale fronte sono impegnate? Il codice cambia velocemente in questo periodo e vorrei avere, se possibile, un'idea di chi sta lavorando a cosa.
Mi sono permesso di aggiornare e mi sono segnato per un altro bug...ispeziono il codice e vi faccio sapere...
Si possono aggiornare la check list e la bug list?
E' possibile avere un elenco di persone e su quale fronte sono impegnate? Il codice cambia velocemente in questo periodo e vorrei avere, se possibile, un'idea di chi sta lavorando a cosa.
Ok, allora numeriamo i bug e teniamo traccia di chi ci sta lavorando. Se dovesse diventare troppo oneroso, Vicius suggeriva qualche sistema automatico come Bugzilla. Lo valutero' dopo la FP.
Chi si sta occupando degli ultimi due bug?
Abbiamo un altro baco, per fortuna più piccolo: ovvero, non esiste un numero massimo di pietre da inviare, e quindi sarebbe da C. Dato però che un valore sopra il 99 è praticamente impossibile da raggiungere durante una partita, ma solo dopo che l'avversario ha fatto game over (visto che, attualmente, il giocatore continua ad avere il controllo della sua area di gioco... e NON E' UN BUG, è una cosa voluta per consentirci di proseguire nel testing anche se l'avversario "perde"), lo segno come tipo D.
Lo correggeremo, ma non siamo costretti a farlo prima della first playable.
Siete sicuri ?? :wtf:
Mentre giocavo non mi sembrava ;)
Il frame di troppo è quello in cui si vede la pietra parzialmente sgretolata, senza numeri. Quei frame li inseriremo quando animeremo le pietre, e utilizzarli ora come se fossero un altro turno da attendere non fa altro che aumentare il tempo prima della loro trasformazione in gemme, e quindi incide sul gameplay.
Allo stato attuale, bisogna invece passare direttamente dal frame col numero 1 alla gemma corrispondente. Alle animazioni ci penseremo poi ;)
Jocchan: guarda se ti va bene
Jocchan: guarda se ti va bene
Hai sistemato il secondo bug? Scarico subito l'ultima build.
Cionci, per favore, potresti prenotarti tu per l'ultimo task della storia 2?
Per i bug abbiamo ancora 7 giorni, ma per i task prima chiudiamo e meglio è.
Mi dispaice...devo andare a studiare ;)
Abbiamo un altro bacherozzo da C, per eventuali cancellazioni che devono avvenire dopo la trasformazione in gemme delle stones: al momento, queste non avvengono subito, mentre il controllo va fatto subito dopo la loro trasformazione.
Inoltre, ho parlato con Fek e, per la versione da rilasciare, ci conviene fare in modo che il game over di uno dei due fermi la partita, e la faccia resettare.
Quindi, lo aggiungo come bug di livello B.
Abbiamo un altro bacherozzo da C, per eventuali cancellazioni che devono avvenire dopo la trasformazione in gemme delle stones: al momento, queste non avvengono subito, mentre il controllo va fatto subito dopo la loro trasformazione.
Inoltre, ho parlato con Fek e, per la versione da rilasciare, ci conviene fare in modo che il game over di uno dei due fermi la partita, e la faccia resettare.
Quindi, lo aggiungo come bug di livello B.
oggi giochicchiando con il gravity ho notatao un bug.
provate mettere strongestGravity a 1.
fate separare la gemsPair.
Premendo down, quella che continua a cadere, ha dei "sobbalzi"...
ha velocita accelerata il bug nn si vede, ma cmq cè(cmq da risolvere dopo la FP)
La situazione che descrivi si verifica solo smanettando in Config, giusto?
In tal caso, possiamo risolverla tranquillamente dopo la FP. Se invece si tratta di un evento realizzabile in una partita "normale", allora dobbiamo vedere di sistemare il bug prima.
La situazione che descrivi si verifica solo smanettando in Config, giusto?
In tal caso, possiamo risolverla tranquillamente dopo la FP. Se invece si tratta di un evento realizzabile in una partita "normale", allora dobbiamo vedere di sistemare il bug prima.
probabilmente si verifica anche in una partita normale, ma non è "umanamente" visibile :) visto la velocita di caduta.
probabilmente si verifica anche in una partita normale, ma non è "umanamente" visibile :) visto la velocita di caduta.
Bene, allora lo segnalo come D.
Altro Bug interessante. :doh:
Se si fa un crush>=2 quando la gemsPair avversaria è quasi dropped, ma mooolto quasi dropped, la WarningBox si vede per pochissimi istanti finchè la gemsPair non è dropped, ma poi le stone non sono inserite subito, ma dopo la seguente GemsPair. :mbe:
Probabilmente gli state del playField non fanno in tempo ad arrivare allo stoneFallState mentre vienen inserita la nuova gemspair, che però cancella WarningBox.
Quindi bisognerà far sì che la scomparsa di WarningBox dipenda dall'inserimento delle stone e non più dall'inserimento di una nuova gemsPair.
Io non ne voglio trovare più di bug :cry: :cry:
oggi giochicchiando con il gravity ho notatao un bug.
provate mettere strongestGravity a 1.
fate separare la gemsPair.
Premendo down, quella che continua a cadere, ha dei "sobbalzi"...
ha velocita accelerata il bug nn si vede, ma cmq cè(cmq da risolvere dopo la FP)
Sto fixando questo bug, mentre faccio un refactoring...
Ulteriore bug... :cry:
...WarningBox e CounterBox capita che si sovrappongano.
Penso che sia dovuto sempre al bug di cancellazione di WarningBox...che è "asincrona" rispetto agli state.
Sto fixando questo bug, mentre faccio un refactoring...
Cionci, il bug è a posto?
Ulteriore bug... :cry:
...WarningBox e CounterBox capita che si sovrappongano.
Penso che sia dovuto sempre al bug di cancellazione di WarningBox...che è "asincrona" rispetto agli state.
Aggiungo come C.
Altro Bug interessante. :doh:
Se si fa un crush>=2 quando la gemsPair avversaria è quasi dropped, ma mooolto quasi dropped, la WarningBox si vede per pochissimi istanti finchè la gemsPair non è dropped, ma poi le stone non sono inserite subito, ma dopo la seguente GemsPair. :mbe:
Probabilmente gli state del playField non fanno in tempo ad arrivare allo stoneFallState mentre vienen inserita la nuova gemspair, che però cancella WarningBox.
Quindi bisognerà far sì che la scomparsa di WarningBox dipenda dall'inserimento delle stone e non più dall'inserimento di una nuova gemsPair.
Io non ne voglio trovare più di bug :cry: :cry:
Jocchan forse questo è più importante...e anche più grave :cry:
Cionci, il bug è a posto?
Sì... In pratica durante GemFallState le gemme erano sensibili alla variazione della gravità...
Altro Bug interessante. :doh:
Se si fa un crush>=2 quando la gemsPair avversaria è quasi dropped, ma mooolto quasi dropped, la WarningBox si vede per pochissimi istanti finchè la gemsPair non è dropped, ma poi le stone non sono inserite subito, ma dopo la seguente GemsPair. :mbe:
Probabilmente gli state del playField non fanno in tempo ad arrivare allo stoneFallState mentre vienen inserita la nuova gemspair, che però cancella WarningBox.
Quindi bisognerà far sì che la scomparsa di WarningBox dipenda dall'inserimento delle stone e non più dall'inserimento di una nuova gemsPair.
Io non ne voglio trovare più di bug :cry: :cry:
Io invece ne voglio trovare il piu' possibile adesso e chiuderli a questa velocita', cosi' usciamo con una bella First Playable stabile :)
TEST
private void makeAllGemsFall(PlayField playField)
{
while(playField.getGridController().getGrid().droppedGemCanMoveDown())
{
update(playField);
}
update(playField);
}
public void testPatternDoNotChange()
{
for(int i = 0; i < 2; i++)
{
insertAndUpdateInPalyField(opponentPlayField,createGem(DIAMOND),13,1);
insertAndUpdateInPalyField(opponentPlayField,createGem(DIAMOND),12,1);
insertAndUpdateInPalyField(opponentPlayField,createChest(DIAMOND),11,1);
if(opponentPlayField.getGridController().getGrid().droppedGemCanMoveDown())
{
makeAllGemsFall(opponentPlayField);
update(playField);
makeAllGemsFall(playField);
}
else
{
update(opponentPlayField);
update(playField);
}
makeAllGemsFall(playField);
update(opponentPlayField);
}
for(int column = 0; column < 2; column++)
{
Droppable stone1 = playField.getGridController().getGrid().getGemAt(13, column);
Droppable stone2 = playField.getGridController().getGrid().getGemAt(12, column);
assertEquals("The Pattern in two insertion must be equals",
stone1.getColor(), stone2.getColor());
}
SOLUZIONE
private static Pattern pattern = new Pattern();
[....]
return new StoneFallState(config, pattern).update(timer, gridController);
BUG del PATTERN ->RISOLTO :sofico: :sofico:
Come al solito ci ho messo un sacco di tempo perchè non so mai quanti update ci vogliono per fare una qualsiasi cosa e cosa producano :muro: :muro:
Praticamente ho impiegato 4h per fare reverse engineering e capire cosa capitava all'interno delle grid....e circa 10 sec per risolvere il problema.
E alla fine nn ho ancora mica capito cosa fa il test...però alla fine fa quello che voglio io :Prrr: :Prrr:ù
EDIT: la cosa funziona...ma ovviamente l'associazione valore->colore del pattern è uguale per entrambi i playField
Puoi cercare un modo di sciogliere il garbuglio degli update e semplificare Grid? Non voglio vederti perdere ogni volta 4h per risolvere un bug, meglio perdere un paio d'ore una volta e rifattorizzare il codice. Qualche idea da cui partire?
Bonfo, esattamente quale bug hai risolto?
Quello della WarningBox lo aggiungo subito
4 - Talvolta il pattern non viene rispettato
Questo ;)
Ecco un altro bug relativo alla trasformazione delle stones in gemme.
Le BigGem non vengono formate :(
Inoltre la BigGem non viene estesa nemmeno dopo :doh:
Quelle cerchiate erano stones.
Aggiunto. Per il bug risolto, domani testo e poi aggiorno.
Risolto anche questo !!!
5 - Il frame iniziale delle stone non viene settato in base alla profondità B
...o meglio QUASI :(
Come si può vedere dall'immagine la prima fila di stones è Ok, ma la seconda piazza tutti 1....
...il problema è che il metodo di Grid getHeightOfColumn() conta anche le gemme che stanno cadendo, no solo quelle dropped.
Domani metto a posto pure questo ;)
Come non detto....l'ho fatto adesso :asd: :asd: :Prrr:
Quindi bug 5 risolto :yeah:
BlueDragon
15-04-2006, 11:22
Giocando in due ho notato un altro bug:
ogni tanto uno dei due avversari non riceve più la GemsPair successiva...questo accade quando una delle colonne (es: quella tutta a sinistra) è piena fino in cima e ti vengono mandate delle stones.
Il giocatore rimane quindi in attesa perenne, senza la scritta gameover...e l'avversario non può nemmeno mandargli delle pietre (il warning sotto assume il valore delle varie combo, senza sommarle, ma le pietre non vengono mai mandate)
Al momento non ho tempo per il debug (visto che devo finire il task), quindi ve lo lascio da aggiungere alla buglist ;)
BlueDragon
15-04-2006, 11:30
Approposito, altro bug...
Le stones da inviare non vengono sommate correttamente. Mi spiego: se si effettua un'unica combo, vengono sommate. Ma se si fa prima una piccola combo, e poi, prima ancora che l'avversario abbia posato la sua gemspair, se ne fa un'altra.... nella warning box appare il numero della seconda combo e non la somma prima + seconda. Anche il numero di pietre inviato subito dopo è pari alla sola seconda combo.
Per effettuare meglio questo test consiglio di diminuire la velocità di caduta normale e di aumentare il moltiplicatore di gravità, in questo modo avete più tempo per fare due combo con due gemspair separate mentre l'avversario lascia cadere molto lentamente la sua gemspair.
ATTENZIONE, il primo dei due bug segnalati da BD è di livello A, perchè impedisce di proseguire nel gioco. Risolverlo è la nostra massima priorità attuale, così come inserire il sistema di bilanciamento che faccia cadere le stone PRIMA nelle colonne a maggiore profondità, rispettando sempre il pattern.
Chi se ne occupa? E' FONDAMENTALE.
P.S.: Aggiunto anche l'altro bug trovato da BD.
BlueDragon
15-04-2006, 11:40
Mi sono accorto di una mia imprecisione nei termini: per combo intendevo semplicemente distruzione di gemme, non necessariamente una vera combo, ciò una distruzione a catena :)
Come non detto....l'ho fatto adesso :asd: :asd: :Prrr:
Quindi bug 5 risolto :yeah:
Bug 4 e 5 risolti, grazie Bonfo.
14 - Quando una stone viene fatta cadere in una colonna piena, le gemspair smettono di cadere A
Ma come si risolve??
Si manda il gioco in GameOver oppure non si sinserisce la stone e basta??
BlueDragon
15-04-2006, 13:26
14 - Quando una stone viene fatta cadere in una colonna piena, le gemspair smettono di cadere A
Ma come si risolve??
Si manda il gioco in GameOver oppure non si sinserisce la stone e basta??
Quoto da Jocchan:
"Risolverlo è la nostra massima priorità attuale, così come inserire il sistema di bilanciamento che faccia cadere le stone PRIMA nelle colonne a maggiore profondità"
La stone non va inserita nella colonna piena ma nelle altre colonne libere (quelle più basse per prime). Quindi il gioco prosegue e non va in gameover :)
15 - Le stone da inviare dopo due (o più) cancellazioni o crush immediatamente successive non vengono sommate B
Fatto anche questo :sofico: :sofico:
Quoto da Jocchan:
"Risolverlo è la nostra massima priorità attuale, così come inserire il sistema di bilanciamento che faccia cadere le stone PRIMA nelle colonne a maggiore profondità"
La stone non va inserita nella colonna piena ma nelle altre colonne libere (quelle più basse per prime). Quindi il gioco prosegue e non va in gameover :)
Esatto ;)
Per il bug 15, verifico e aggiorno.
Non è bello !!! :cry: :cry:
Quella gemsPair cerchiata sta cadendo !!!
Praticamente anche se la colonna di mezzo è piena capita, tenendo premuto il tasto laterale, di riuscire a far cadere comunque la coppia. Ma comunque la scritta GameOver appare lo stesso.
A volte sono riuscito anche a far cadere una gemma singola !!!
Penso che sia riconducibile al bug 12
Edit: ho scordato lo screenshoot :fagiano:
Non è bello !!! :cry: :cry:
Quella gemsPair cerchiata sta cadendo !!!
Praticamente anche se la colonna di mezzo è piena capita, tenendo premuto il tasto laterale, di riuscire a far cadere comunque la coppia. Ma comunque la scritta GameOver appare lo stesso.
A volte sono riuscito anche a far cadere una gemma singola !!!
Penso che sia riconducibile al bug 12
Edit: ho scordato lo screenshoot :fagiano:
Penso anche io, modifico di conseguenza la definizione del bug 12.
Ecco una cosa che non avevo considerato....
..vedo di metterla a posto ;)
Risolto il bug appena descritto.
Jocchan...nondevi fare nenanche la fatica di scriverlo :Prrr: :Prrr:
Il gioco non parte più...
Risolto il bug appena descritto.
Jocchan...nondevi fare nenanche la fatica di scriverlo :Prrr: :Prrr:
La build è rotta... Hai lanciato ANT prima di committare? :)
Qualcuno per caso ha toccato il bug da A? Ci sta lavorando Ufo sopra, e non gli si verifica.
La build è rotta... Hai lanciato ANT prima di committare? :)
Certo che ho lanciato ANT. :D
Comunque anch'io ci sto lavorando sopra...
..mancano solo i test perchè ormai l'ho risolto.
Infatti il bug di prima l'ho notato proprio perchè stavo lavorando su quello...anche la sua soluzione l'avevo già mezza pronta perchè molto codice l'avevo già fatto per il bug A
Ufo..ti chiamo su MSN
Bug 14 RISOLTO. :yeah:
Come penso sia logico è giusto che se la colonna è piena la stone non venga inserita.
La soluzione al bug, come detto, era o il game over oppure un inserimento basato sulla profondità.
Detto fatto. :sofico:
Ho aggiunto un metodo privato a StoneFallState: getLessFullColumn().
NOTA BENE.
Nel correggere i test perchè seguissero un comportamento corretto, questo test mi ha fatto impazzire.
Non lo capisco.
public void testStoneFrameInThirdSegment()
{
insertStoneRows(4);
//TODO: strano comportamento.
insertAndGetSingolStone();
Droppable stone = insertAndGetSingolStone();
assertEquals("Stone must be using the third frame", 2,
stone.getCurrentFrame());
}
Quel insert lì non dovrebbe servire !!!! :muro: :muro: :muro: :muro: :muro:
GLi altri 4 test uguali funziano...lui no!! :muro: :muro: :muro:
Cancellazione Stones- FAILED
Ma c'è qualcuno che lo sta facendo ??
Ma c'è qualcuno che lo sta facendo ??
Mi sembra sia il task di Ufo, che al momento e' impegnato sul bug A. Ti metti d'accordo con lui magari per aiutarlo? Io aiuto redcloud col suo task.
Dopo l'ultimo update è sorto un nuovo bug. Sembra causato dalla caduta di una biggem. Una volta arrivate infondo le gemspair non vengono più create.
Questo è il log della griglia in cui si è verificato il problema.
seed 1145121648410223000
1
pair rubygems rubygems
22
it.diamonds.handlers.RotateClockwiseCommandHandler 1
24
it.diamonds.handlers.DropCommandHandler 1
27
it.diamonds.handlers.DropCommandHandler 1
29
it.diamonds.handlers.DropCommandHandler 1
31
it.diamonds.handlers.DropCommandHandler 1
33
it.diamonds.handlers.DropCommandHandler 1
35
it.diamonds.handlers.DropCommandHandler 1
37
it.diamonds.handlers.DropCommandHandler 1
38
it.diamonds.handlers.DropCommandHandler 0
43
pair sapphireboxes sapphiregems
45
it.diamonds.handlers.MoveRightCommandHandler 1
48
it.diamonds.handlers.RotateClockwiseCommandHandler 1
it.diamonds.handlers.MoveRightCommandHandler 1
57
it.diamonds.handlers.DropCommandHandler 1
60
it.diamonds.handlers.DropCommandHandler 1
62
it.diamonds.handlers.DropCommandHandler 1
64
it.diamonds.handlers.DropCommandHandler 1
66
it.diamonds.handlers.DropCommandHandler 1
68
it.diamonds.handlers.DropCommandHandler 1
70
it.diamonds.handlers.DropCommandHandler 1
71
it.diamonds.handlers.DropCommandHandler 0
77
pair rubyboxes rubygems
82
it.diamonds.handlers.RotateClockwiseCommandHandler 1
87
it.diamonds.handlers.DropCommandHandler 1
91
it.diamonds.handlers.DropCommandHandler 1
93
it.diamonds.handlers.DropCommandHandler 1
95
it.diamonds.handlers.DropCommandHandler 1
97
it.diamonds.handlers.DropCommandHandler 1
99
it.diamonds.handlers.DropCommandHandler 1
101
it.diamonds.handlers.DropCommandHandler 1
103
it.diamonds.handlers.DropCommandHandler 0
106
pair emeraldgems emeraldgems
110
it.diamonds.handlers.RotateClockwiseCommandHandler 1
118
it.diamonds.handlers.DropCommandHandler 1
122
it.diamonds.handlers.DropCommandHandler 1
124
it.diamonds.handlers.DropCommandHandler 1
126
it.diamonds.handlers.DropCommandHandler 1
128
it.diamonds.handlers.DropCommandHandler 1
130
it.diamonds.handlers.DropCommandHandler 1
132
it.diamonds.handlers.DropCommandHandler 1
133
it.diamonds.handlers.DropCommandHandler 0
136
pair emeraldgems emeraldgems
144
it.diamonds.handlers.RotateClockwiseCommandHandler 1
147
it.diamonds.handlers.DropCommandHandler 1
151
it.diamonds.handlers.DropCommandHandler 1
153
it.diamonds.handlers.DropCommandHandler 1
155
it.diamonds.handlers.DropCommandHandler 1
157
it.diamonds.handlers.DropCommandHandler 1
159
it.diamonds.handlers.DropCommandHandler 1
161
it.diamonds.handlers.DropCommandHandler 1
162
it.diamonds.handlers.DropCommandHandler 0
164
pair rubygems rubygems
167
it.diamonds.handlers.MoveRightCommandHandler 1
170
it.diamonds.handlers.MoveRightCommandHandler 1
171
it.diamonds.handlers.RotateClockwiseCommandHandler 1
178
it.diamonds.handlers.MoveLeftCommandHandler 1
180
it.diamonds.handlers.DropCommandHandler 1
183
it.diamonds.handlers.DropCommandHandler 1
185
it.diamonds.handlers.DropCommandHandler 1
187
it.diamonds.handlers.DropCommandHandler 1
189
it.diamonds.handlers.DropCommandHandler 1
191
it.diamonds.handlers.DropCommandHandler 1
193
it.diamonds.handlers.DropCommandHandler 0
196
pair rubygems rubygems
208
it.diamonds.handlers.RotateClockwiseCommandHandler 1
216
it.diamonds.handlers.DropCommandHandler 1
219
it.diamonds.handlers.DropCommandHandler 1
221
it.diamonds.handlers.DropCommandHandler 1
223
it.diamonds.handlers.DropCommandHandler 1
225
it.diamonds.handlers.DropCommandHandler 1
226
it.diamonds.handlers.DropCommandHandler 0
230
pair diamondgems diamondgems
252
it.diamonds.handlers.MoveRightCommandHandler 1
263
it.diamonds.handlers.DropCommandHandler 1
266
it.diamonds.handlers.DropCommandHandler 1
268
it.diamonds.handlers.DropCommandHandler 1
269
it.diamonds.handlers.DropCommandHandler 0
273
pair rubygems rubygems
279
it.diamonds.handlers.DropCommandHandler 1
282
it.diamonds.handlers.DropCommandHandler 1
284
it.diamonds.handlers.DropCommandHandler 1
286
it.diamonds.handlers.DropCommandHandler 1
288
it.diamonds.handlers.DropCommandHandler 1
290
it.diamonds.handlers.DropCommandHandler 1
292
it.diamonds.handlers.DropCommandHandler 1
294
it.diamonds.handlers.DropCommandHandler 0
296
pair sapphiregems sapphireboxes
297
it.diamonds.handlers.MoveLeftCommandHandler 1
301
it.diamonds.handlers.DropCommandHandler 1
304
it.diamonds.handlers.DropCommandHandler 1
305
it.diamonds.handlers.RotateClockwiseCommandHandler 1
306
it.diamonds.handlers.DropCommandHandler 1
308
it.diamonds.handlers.RotateClockwiseCommandHandler 1
it.diamonds.handlers.DropCommandHandler 1
310
it.diamonds.handlers.DropCommandHandler 1
312
it.diamonds.handlers.DropCommandHandler 1
314
it.diamonds.handlers.DropCommandHandler 1
316
it.diamonds.handlers.DropCommandHandler 1
317
it.diamonds.handlers.DropCommandHandler 0
ciao ;)
Dopo l'ultimo update è sorto un nuovo bug. Sembra causato dalla caduta di una biggem. Una volta arrivate infondo le gemspair non vengono più create.
Aspetta che ho fatto un refactoring io di BigGem oggi, forse quella condizione non e' testata. Vuoi provare a fare il revert e vedere se si verifica di nuovo?
Abbiamo un modo per fare il playback di log>?
Mi sembra sia il task di Ufo, che al momento e' impegnato sul bug A. Ti metti d'accordo con lui magari per aiutarlo? Io aiuto redcloud col suo task.
Il bug A l'ho già fixato io :Prrr:
Comunque era solo per sapere perchè mi ero persol'assegnamento.
In ogni caso il tempo che ho concesso a Diamonds ha di gran lunga superato quello che potevo concedergli...ma mi sono diverito come un pazzo :asd: :asd: :asd:
In ogni caso quando e se troverò 5 secondi liberi mi buttero sui bug ;)
DIAMOCI SOTTO RAGAZZI !!!
Abbiamo un modo per fare il playback di log>?
Attualemnte no... Infatti mi domandavo come mai non venisse inserito in una storia...
Il playback dei log è pianificato per dopo la first playable.
Bonfo, quindi ora le stones riempiono prima le colonne più in profondità?
Il playback dei log è pianificato per dopo la first playable.
Bonfo, quindi ora le stones riempiono prima le colonne più in profondità?
CERTAMENTE !!!
Devo dire però che mi sono scordato un test.
Lo faccio adesso ;)
Penso sia una cosa provvisoria, visto che il task di RedCloud è incompleto, ma le CrushBox ora hanno coordinate sballate, ed il box Warning sinistro non viene più mostrato.
Bonfo, ottimo lavoro per i bug ;)
Penso sia una cosa provvisoria, visto che il task di RedCloud è incompleto, ma le CrushBox ora hanno coordinate sballate, ed il box Warning sinistro non viene più mostrato.
Bonfo, ottimo lavoro per i bug ;)
Appena finisco di rifattorizzare il giardino, aiuto redcloud a finire il task. Manca poco.
"Green Refactoring: Improving the structure of an existing garden"
Sottolineo la presenza del bug segnalato da Vic.
La caduta di una BigGem BLOCCA il gioco. Non vengono inserite nuove gemspair ed inoltre l'eventulae CrushBox che appare non scompare più.
Propongo una bella A
Mi era sfuggito (non chiedetemi come, visto che il chilometrico log postato da Vicius non dovrebbe passare facilmente inosservato). Lo aggiungo subito.
EDIT: Fatto. Massima priorità al bug di livello A.
Appena finisco di rifattorizzare il giardino, aiuto redcloud a finire il task. Manca poco.
"Green Refactoring: Improving the structure of an existing garden"
Dalle mie parti il giardino è YAGNI :eek:
fek, mi raccomando i test per il giardino... :Prrr:
provando un pò dopo tanto tempo....questo non vi piacerà...
http://img211.imageshack.us/img211/3093/x0ph.th.jpg (http://img211.imageshack.us/my.php?image=x0ph.jpg)
Davvero...non ho fatto apposta, non è colpa mia :cry:
Fatto partire dal .bat, intanto che andava passo al desktop, apro una cartella, faccio partire media player, torno in diamonds ed è successo...è colpa di windows, è colpa di bill...fek, sculaccialo da parte di tutti.... :Prrr: :Prrr:
A parte gli scherzi, però non sò se una cosa simile sia possibile gestirla, dato che succede solo quando si continua a mostrare/nascondere il desktop...dovrei provare sotto gentoo...a proposito, come postato nell'altro thread (problemi), ho finito l'altro pc (g400), installato la jre5, fatto partire e stesso errore...oggi dovrei finire di aggiornare quello principale mettendo anche gli ultimi nvidia e provo...
Dalle mie parti il giardino è YAGNI :eek:
:rotfl: :rotfl: :rotfl: :rotfl: :rotfl:
Però forse fek alle sue ditine ci tiene....perchè mi sa che qualcuno potrebbe spezzargliele. :asd: :asd:
Non penso aiuti coi BUG, ma penso sia comunque fondamentale dirlo:
bisogna rifattorizzare il codice in modo che molte funzionalità sparse vadano a finire dentro gli state.
Ad esempio grid.updateAlsoDroppedGem(gem) non penso sia compito di grid, ma molto più di GemFallState o di UpdateFallsAction.
Inoltre UpdateFallsAction fa alcune cose che fa già BigGem.moveDown().
A questo punto è anche evidente come bisogna mettere chiarezza tra gli State e le Action...anche lì si sovrapponngono le responsabilità creando confusione.
Dopo la FP bisognerà mettersi a tavolino e decidere quali sono gli state e quali sono le action e chi fa che cosa.
Così facendo si dovrebbe riuscire a togliere a grid qualsiasi compito di "gioco".
EDIT: ma perchè public boolean moveDown(Grid grid) ritorna un boolean ??? :eekk:
Questo refactoring s'ha da fare, ma dopo la FP.
Non dimentichiamocelo.
Cercando di capire il bug di livello A ho scoperto ce in realtà la caduta delle gemme è tutto tranne che comprensibile...dopo un paio di pasaggi ci si è già persi dentro il codice e si sono guardate 10 almeno 5 o 6 calssi che fanno più o meno cose simili :( :(
ragazzi, sto indagando per il bug numero 16; si tratta di un problema legato ad un altro che ha indivudato Antares e che vi mostro in questo suo screenshot allegato.
in altre parole: la nuova gems pair non cade perché il gioco attende che quel pezzo di big gem finisca di cadere, solo che non cade.
per il resto il gioco continua a funzionare (le animazioni delle gemme ci sono ancora).
fek, mi raccomando i test per il giardino... :Prrr:
provando un pò dopo tanto tempo....questo non vi piacerà...
http://img211.imageshack.us/img211/3093/x0ph.th.jpg (http://img211.imageshack.us/my.php?image=x0ph.jpg)
Davvero...non ho fatto apposta, non è colpa mia :cry:
Fatto partire dal .bat, intanto che andava passo al desktop, apro una cartella, faccio partire media player, torno in diamonds ed è successo...è colpa di windows, è colpa di bill...fek, sculaccialo da parte di tutti.... :Prrr: :Prrr:
A parte gli scherzi, però non sò se una cosa simile sia possibile gestirla, dato che succede solo quando si continua a mostrare/nascondere il desktop...dovrei provare sotto gentoo...a proposito, come postato nell'altro thread (problemi), ho finito l'altro pc (g400), installato la jre5, fatto partire e stesso errore...oggi dovrei finire di aggiornare quello principale mettendo anche gli ultimi nvidia e provo...
A me, minimizzando il gioco addirittura mi si chiude
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_INT_DIVIDE_BY_ZERO (0xc0000094) at pc=0x691e1c06, pid=2264, tid=3960
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode)
# Problematic frame:
# C [atioglxx.dll+0x1e1c06]
#
BUG 16.....TROVATO!!!! :sofico:
Ora manca solo di schiacciarlo :D
In Grid
private float getRowHeight(final int row)
{
return row * getYStep() + bounds.top();
}
se tolgo quel bounds.top() funzia tutto perfettamente.
E i test passano ancora tutti ;)
Ora gioco un po' per vedere se è tutto ok
EDIT:
Se qualcuno ha voglia di fare il test lo ringrazio ;)
Confermo...basta eliminare quello che tutto va alla perfezione :D :D
Eliminarlo cosa comporta?
BUG 16.....TROVATO!!!! :sofico:
Ora manca solo di schiacciarlo :D
In Grid
private float getRowHeight(final int row)
{
return row * getYStep() + bounds.top();
}
se tolgo quel bounds.top() funzia tutto perfettamente.
E i test passano ancora tutti ;)
Ora gioco un po' per vedere se è tutto ok
EDIT:
Se qualcuno ha voglia di fare il test lo ringrazio ;)
sono molto a digiuno di codice diamonds, e adesso non c'ho il portatile per poter fare qualcosa, cmq controlla dove viene usato quel metodo, può essere che il metodo venga interpretato diversamente da qualche altra parte, in questo caso bisogna vedere quale strategia è stata adottata nel resto del codice, se si è preferito usare delle coordinate relative o assolute diciamo....
Altra cosa: due big gem, non sono state inglobate subito, ma all'update seguente (quando anche quella coppia è caduta)
http://img396.imageshack.us/img396/8634/x1yd.th.jpg (http://img396.imageshack.us/my.php?image=x1yd.jpg)
Altra cosa: due big gem, non sono state inglobate subito, ma all'update seguente (quando anche quella coppia è caduta)
http://img396.imageshack.us/img396/8634/x1yd.th.jpg (http://img396.imageshack.us/my.php?image=x1yd.jpg)
Sii più specifico: la biggem in alto è caduta su quella in basso dopo una cancellazione? O c'erano stone in mezzo, poi trasformate in gemme?
Nessuna stone (sto testando solo in single, non ancora con due giocatori ^^ ) e non è caduto niente da nessuna parte, la big gem l'ho "formata" a pezzi sopra l'altra...solo che adesso sto riprovando e non lo fà più...non sò cos'ho combinato per quella situazione...ora riprovo ancora un pò...
Comunque prima creo la big gem "base" e poi costruisco sopra l'altra per vedere l'inglobazione... ^^
edit: ma come ho fatto? non ci riesco più O_o
redcloud
16-04-2006, 22:52
Altro bugghettino :(
Quando una gemsPair sta cadendo in una colonna e non può spostarsi lateralmente perchè le colonne adiacenti sono occupate (ma non dai bordi), premere il tasto 'c' per switchare la posizione (solo verticale quindi) non sortisce alcun effetto ma non sistematicamente! Appena mi capita faccio screenshot.
BUG 16.....TROVATO!!!! :sofico:
Ora manca solo di schiacciarlo :D
In Grid
private float getRowHeight(final int row)
{
return row * getYStep() + bounds.top();
}
se tolgo quel bounds.top() funzia tutto perfettamente.
E i test passano ancora tutti ;)
Ora gioco un po' per vedere se è tutto ok
EDIT:
Se qualcuno ha voglia di fare il test lo ringrazio ;)
Ho introdotto io il bug con il mio refactoring di BigGem e Grid. Puoi scrivere il test che esercita il bug che lo faccio passare io? Grazie.
Sistemate coordinate della CrushBox
Olè...ho trovato (dopo non sò quante prove) come avevo fatto, questo è il momento prima
http://img100.imageshack.us/img100/3608/x8vt.th.jpg (http://img100.imageshack.us/my.php?image=x8vt.jpg)
Ho numerato l'ordine con cui ho creato le biggem, con la pair che arriva mettendola per crearne una unica vengono fuse solo la 2 e la 3 lasciandone 2 che si fondono all'update sucessivo. Il problema quindi penso sia dato dal fatto che crea solo una biggem per update, oppure ho detto una ca**ata? :stordita:
Il problema quindi penso sia dato dal fatto che crea solo una biggem per update, oppure ho detto una ca**ata? :stordita:
Mi sa proprio di sì :D
Come direbbe fek...fai un bel test ;)
BUG 16 RISOLTO.
Ne sono praticamente certo ;)
Evvai...2 bug di livello A :yeah: :yeah:
:Prrr: :Prrr:
Altro bug (penso con parecchia priorità, joc? ):
http://img465.imageshack.us/img465/8991/x5an.th.jpg (http://img465.imageshack.us/my.php?image=x5an.jpg)
Giocando "tranquillamente" (da solo sul portatile riempire con una mano tutta la prima griglia e intanto "cercare la situazione adatta" nella seconda non è poi così tranquillo.....perchè poi riempire la prima griglia..mah...sarà l'ora tarda che inizia a mostrare i primi sintomi di pazzia :Prrr: ) nella seconda griglia c'era tutta la colonna centrale piena, all'arrivo della prossima pair ci sarebbe stato game over...ma stasera si vede che sono fortunato e mi arriva esattamente nella posizione inferiore la pietra che fa eliminare tutti quelli di un colore (come si chiama ? :doh: ) e come per magia mi elimina tutti i diamanti salvandomi (no, non avrei perso lo stesso...disfando la tastiera sul tasto sinistro mi sarei salvato :D ), che culo....ma...cos'è successo...game over... l'ha contato lo stesso anche se l'ha eliminato :cry:
Controlla prima il game over che le eventuali crush?
edit: riguardando l'immagine ho visto una cosa nella prima griglia, tutti quei topazi nelle due colonne se non ricordo male sono dati anche da parecchie stone, quindi niente di allarmante (era già stato segnalato)
redcloud
17-04-2006, 00:23
Sistemate coordinate della CrushBox
Io lo vedo così su windows, prima lo vedevo esattamente al centro del playfield di sinistra. Ora vado a provare su linux.
http://img293.imageshack.us/img293/4210/senzatitolo26cc.jpg (http://imageshack.us)
Ho introdotto io il bug con il mio refactoring di BigGem e Grid. Puoi scrivere il test che esercita il bug che lo faccio passare io? Grazie.
Ooooppppsss.... :doh:
...ho riletto adesso.
Ho fatto test e fatto passare....ho perso le mie ditine per sempre???
Anche io vedo come red, sia nella prima che nella seconda griglia
Anche io vedo come red, sia nella prima che nella seconda griglia
Ufo ci sta guardando....ha richiesto a Joc le coordinate esatte...e con quelle cordinate quello è quello che succede.
Probabilmente è cambiato qualcosa nel rectangle...
...comunque anche quando cesare aveva finito il suo task la posizione della CrushBox era quella...lo avevo già segnalato....ma non sembra così ovvio da risolvere :( :(
Altro bug (penso con parecchia priorità, joc? ):
Ma perchè ogni volta che eliminiamo il bug di livello A ne appare subito un altro... :muro: :muro: :muro:
12 - Quando si cerca di far passare una coppia sotto una BigGem con dello spazio libero al di sotto di essa, la slave talvolta si sovrappone ad una delle caselle della BigGem. Questo può capitare anche quando la colonna centrale è piena, a Game Over avvenuto C
Forse era anche già stato inglobato qui...ma direi che ora va proprio diviso in 2 bug diversi.
Ma perchè ogni volta che eliminiamo il bug di livello A ne appare subito un altro... :muro: :muro: :muro:
:(
Uhm...direi di sì per la divisione (sempre se era intesa la stessa cosa), anche perchè questo penso sia un pò più urgente ^^
Sto crushbox è na fonte di guai. E pensare che le avevo sistemate due commit prima :mad: Ora le ho rimesse come erano.
ciao ;)
Altro bug (penso con parecchia priorità, joc? ):
http://img465.imageshack.us/img465/8991/x5an.th.jpg (http://img465.imageshack.us/my.php?image=x5an.jpg)
Giocando "tranquillamente" (da solo sul portatile riempire con una mano tutta la prima griglia e intanto "cercare la situazione adatta" nella seconda non è poi così tranquillo.....perchè poi riempire la prima griglia..mah...sarà l'ora tarda che inizia a mostrare i primi sintomi di pazzia :Prrr: ) nella seconda griglia c'era tutta la colonna centrale piena, all'arrivo della prossima pair ci sarebbe stato game over...ma stasera si vede che sono fortunato e mi arriva esattamente nella posizione inferiore la pietra che fa eliminare tutti quelli di un colore (come si chiama ? :doh: ) e come per magia mi elimina tutti i diamanti salvandomi (no, non avrei perso lo stesso...disfando la tastiera sul tasto sinistro mi sarei salvato :D ), che culo....ma...cos'è successo...game over... l'ha contato lo stesso anche se l'ha eliminato :cry:
Controlla prima il game over che le eventuali crush?
edit: riguardando l'immagine ho visto una cosa nella prima griglia, tutti quei topazi nelle due colonne se non ricordo male sono dati anche da parecchie stone, quindi niente di allarmante (era già stato segnalato)
Massima priorità al CoverBug (non ho idea di come segnalarlo nella prima pagina, si accettano suggerimenti).
In definitiva, quali sono i bug fixati dall'ultimo aggiornamento? E quali altri vanno aggiunti all'elenco?
Allora...io ho risolto il 16.
Poi c'è questo maledetto crushBox che non si capisce dove va.
Mi sa che Vic e Ufo stanno facendo commit su commit e si fanno e si disfano il lavoro.
Poi si sono aggiunti 2 bugs
- GameOver bug: viene mostrata la scritta GameOver prima di controllare eventuali crush
- Estensioni delle bigGem: se sono presenti 2 bigGem e se ne fa una 3° che può essere inglobata in entrambe formando così una unica bigGem, vengono unite solo 2 BigGem su 3
Sto crushbox è na fonte di guai. E pensare che le avevo sistemate due commit prima :mad: Ora le ho rimesse come erano.
ciao ;)
Ora però fallisce un test.......Vic :nonsifa: :nonsifa:
Ecco la conferma del GameOverBug....
...la condizione di GameOver non attende eventuali Crush.
Ecco la conferma del GameOverBug....
...la condizione di GameOver non attende eventuali Crush.
Fixarlo dovrebbe essere facile, vero?
Ora però fallisce un test.......Vic :nonsifa: :nonsifa:
Perché testa le coordinate sbagliate. :)
Provate a vedere se quelle che ho messo sono giuste. Poi correggetelo voi che io no ho voglia :p
ciao ;)
Massima priorità al CoverBug (non ho idea di come segnalarlo nella prima pagina, si accettano suggerimenti).
In definitiva, quali sono i bug fixati dall'ultimo aggiornamento? E quali altri vanno aggiunti all'elenco?
Che bello...sono un bug :sofico: :sofico:
Bonfo è stato più tattico però... ^^
Joc, per l'altro cosa dici? quello delle tre big gem che non vengono inglobate in una volta sola...
Che bello...sono un bug :sofico: :sofico:
Bonfo è stato più tattico però... ^^
Joc, per l'altro cosa dici? quello delle tre big gem che non vengono inglobate in una volta sola...
L'altro bug è già in elenco, e va sistemato :)
Chi cambia il test che fallisce con le coordinate giuste?
Le coordinate delle crushbox sono ancora sbagliate.
Le png dovrebbero essere ai lati dello schermo, ed una piccola parte del bordino rosso deve uscire fuori (il bordino ha le "punte" sia a destra che a sinistra solo ed esclusivamente per poter usare la stessa png per entrambi i giocatori).
Immagine di esempio (fatta "a genitali di canide"):
http://img222.imageshack.us/my.php?image=provola1xi.jpg
redcloud
17-04-2006, 01:58
http://img294.imageshack.us/img294/7324/senzatitolo10eg.th.jpg (http://img294.imageshack.us/my.php?image=senzatitolo10eg.jpg)
Prima
http://img297.imageshack.us/img297/5739/senzatitolo24zg.th.jpg (http://img297.imageshack.us/my.php?image=senzatitolo24zg.jpg)
Dopo
In medio stat virtus...
http://img294.imageshack.us/img294/7324/senzatitolo10eg.th.jpg (http://img294.imageshack.us/my.php?image=senzatitolo10eg.jpg)
Prima
http://img297.imageshack.us/img297/5739/senzatitolo24zg.th.jpg (http://img297.imageshack.us/my.php?image=senzatitolo24zg.jpg)
Dopo
In medio stat virtus...
Più che in medio, una decina (abbondante) di pixel più a destra della prima figura :D
Più che in medio, una decina (abbondante) di pixel più a destra della prima figura :D
Ma non dovrebbe stare al centro ? :confused:
Ma non dovrebbe stare al centro ? :confused:
No :stordita:
La png era progettata come gli indicatori per le combo di un qualsiasi picchiaduro.
In Puzzle Fighter, se non sbaglio, compariva una scritta (con il normale font del gioco) in basso al centro, ma sinceramente trovo che ci stesse malissimo, e - sempre se la memoria non mi inganna - che addirittura coprisse l'area di gioco più del nostro approccio.
Fatto per la prima: http://img234.imageshack.us/my.php?image=x3co.jpg
Passo alla seconda e faccio commit ^^
edit: confermate da joc e fatto commit ;) che bello...ogni tanto riesco a fare qualcosa.... :cry:
Ottimo, questione CrushBox archiviata. Complimenti a tutti :)
Ora la nostra priorità massima è il bug 17, e ho aggiunto un ventesimo (di importanza minore).
No :stordita:
La png era progettata come gli indicatori per le combo di un qualsiasi picchiaduro.
In Puzzle Fighter, se non sbaglio, compariva una scritta (con il normale font del gioco) in basso al centro, ma sinceramente trovo che ci stesse malissimo, e - sempre se la memoria non mi inganna - che addirittura coprisse l'area di gioco più del nostro approccio.
"We in the game industry are lucky enough to be able to create our visions" :)
"We in the game industry are lucky enough to be able to create our visions" :)
Parole sante.
Antares88
17-04-2006, 11:31
Dato che ho finito di montare Spartacus e che per stamattina mi sono ampiamente stufato di fare esercizi di matematica, ho fatto una partitella a diamonds, e credo di aver trovato un bug:
Dopo aver fatto saltare delle gemme gialle che stavano in basso, sotto alla gemmona verde e alla fila di gemme di tutti i colori, il gioco si è bloccato e non da segni di vita.
http://img20.imageshack.us/img20/6089/bugblocco1qr.jpg (http://imageshack.us)
La configurazione è:
P4 2400mhz (northwood)
1,5gb di ram DDR 333mhz Kingston (non ecc)
Radeon 9700pro
Windows 2000pro con service pack 4
C'è altro che è utile sapere ? il gioco sta girando a 800x600x32@75hz
edit: noto ora che il riflesso delle gemme continua a comparire e scomparire, quindi nn sembra un blocco totale
La nuova build non parte: mi dà un'exception che non riesco a catturare.
Dato che ho finito di montare Spartacus e che per stamattina mi sono ampiamente stufato di fare esercizi di matematica, ho fatto una partitella a diamonds, e credo di aver trovato un bug:
Dopo aver fatto saltare delle gemme gialle che stavano in basso, sotto alla gemmona verde e alla fila di gemme di tutti i colori, il gioco si è bloccato e non da segni di vita.
http://img20.imageshack.us/img20/6089/bugblocco1qr.jpg (http://imageshack.us)
La configurazione è:
P4 2400mhz (northwood)
1,5gb di ram DDR 333mhz Kingston (non ecc)
Radeon 9700pro
Windows 2000pro con service pack 4
C'è altro che è utile sapere ? il gioco sta girando a 800x600x32@75hz
edit: noto ora che il riflesso delle gemme continua a comparire e scomparire, quindi nn sembra un blocco totale
Era un BUG....il 16
Dovrebbe essere già stato risolto :confused: ...hai fatto clean del progetto?? :confused:
La nuova build non parte: mi dà un'exception che non riesco a catturare.
Nessuno ha modificato i file .bat e .sh perchè facciano partire il gioco con le nuove librerie :muro:
Provo a guardarci...ma non assicuro nulla :mc:
FATTO !!!!
modificati i file .bat e .sh.
Qualcuno può controllare sotto linux??
ARGH, ancora exception.
http://lnx.rc6.it/diamonds/varie/error02.jpg
sul portatile con Xp va, gli altri 2 pc con gentoo no... nè da exlipse nè da .sh :cry:
Azz...con il mio winXP, partendpo dal .bat va sicuramente.
Il .sh l'ho fatto per deduzione :(
Bug 20 risolto :yeah:
Comunque Joc incominci a perdere dei colpi....
...nel task 14.1.4 non era mica specificato :Prrr: :Prrr:
Azz...con il mio winXP, partendpo dal .bat va sicuramente.
Il .sh l'ho fatto per deduzione :(
Magari l'.sh va, il fatto è che non va nemmeno da eclipse, anche prima :(
Bug 20 risolto :yeah:
Comunque Joc incominci a perdere dei colpi....
...nel task 14.1.4 non era mica specificato :Prrr: :Prrr:
Infatti non lo era, ma ragionandoci bene anche limitare i danni è un contrattacco, anche se parziale, e quindi va evidenziato ;)
Il problema quindi è nell'exe, visto che io eseguo le build scaricate da cruise control.
Ho testato con un .bat passatomi da BD (fantastico l'mp3 in sottofondo) e ho settato dei valori di default per il singolo pulsing delle crushbox, ma dobbiamo comunque sistemare l'exe.
Per il bug 17 come siamo messi?
redcloud
17-04-2006, 15:52
Ho notato che la CrushBox quando appare e arriva al massimo della pulsazione, esce di poco dal bordo della finestra. Si devono tarare posizione e ingrandimento in modo che tutte le CrushBox non soffrano di questo piccolo bug.
Ho notato che la CrushBox quando appare e arriva al massimo della pulsazione, esce di poco dal bordo della finestra. Si devono tarare posizione e ingrandimento in modo che tutte le CrushBox non soffrano di questo piccolo bug.
In realtà non è un bug, dato che cambiando le coordinate sarebbe troppo al centro. Visto che l'ingrandimento è ben evidente, è inevitabile che sia così ;)
Manaccia... :sob:
http://img365.imageshack.us/img365/2194/bug7kl.th.jpg (http://img365.imageshack.us/my.php?image=bug7kl.jpg)
Stavamo giocando in 2...ridendo come pazzi...e la griglia a sinistra si è piantata :cry: :cry:
Giocare con la ragazza è fantastico...sta tirando furoi tutti gli insettini!!!
Eccone un'altro.
http://img475.imageshack.us/img475/1313/stonesbug4zr.th.jpg (http://img475.imageshack.us/my.php?image=stonesbug4zr.jpg)
E' evidente come nella prima colonna sia stata conteggiata male l'altezza.
:muro: :muro:
BlueDragon
17-04-2006, 19:24
Manaccia... :sob:
http://img365.imageshack.us/img365/2194/bug7kl.th.jpg (http://img365.imageshack.us/my.php?image=bug7kl.jpg)
Stavamo giocando in 2...ridendo come pazzi...e la griglia a sinistra si è piantata :cry: :cry:
A guardarlo assomiglia al bug 14...:)
14 - Quando una stone viene fatta cadere in una colonna piena, le gemspair smettono di cadere A FIXED (Bonfo)
A guardarlo assomiglia al bug 14...:)
Quindi il 14 non è del tutto FIXED.
Lo rimetto come da correggere, e aggiungo il 21 (livello B).
Per il bug 14....vi assicuro che c'è pure il test!!!
testStoneInsertionIfStonesPresent() in TestStoneFallState.
Non è il bug 14...è un bug relativo all'inserimento delle gemsPair....non un problema di stone che rimane in attesa di essere inserita!!!
Del bug 14 non ne voglio più sentir parlare !! :D :D :D
Per ciò che riguarda l'altro bug sembra che il calcolo avvenga male quando le stone si trasformano in gem....probabilmente per un istante, quando avviene il cambio, la grid non le rileva presenti. :mad: :mad:
Quindi come lo indico?
Ho aggiunto un ulteriore bug, numerato a 99 per distinguerlo dato che non è esattamente un bug.
La configurazione attuale dei tasti, per due giocatori, è da crampi alle dita.
Per la FP, dobbiamo modificarli ad una struttura meno "pericolosa".
ALT...confermo...è il 14 :flower:
Mi vergogno un po' ma è quello....
...secondo me però dipende fortemente dal fatto che ogni tanto l'inserimento in base alla profondità fallisca. :(
Quindi è strettamente collegato al bug 21.
A questo sono inoltre collegati tutti i bug relativi alla trasformazione delle stone in gem, ovvero il loro crush e la creazione di bigGem.
Ora provo a guardarci un attimo ;)
ALT...confermo...è il 14 :flower:
Mi vergogno un po' ma è quello....
...secondo me però dipende fortemente dal fatto che ogni tanto l'inserimento in base alla profondità fallisca. :(
Quindi è strettamente collegato al bug 21.
A questo sono inoltre collegati tutti i bug relativi alla trasformazione delle stone in gem, ovvero il loro crush e la creazione di bigGem.
Ora provo a guardarci un attimo ;)
Grazie, Bonfo :)
Non ho ancora concluso niente....tranne che l'updateStone() di grid può andare quasi ovuque e i test passano tutti lo stesso
:muro: :muro: :muro: :muro:
Forse ho trovato come risolvere un buon insieme di Bug relativo alla trasformazione di stone in gem...
...mancano solo i test :sofico: :sofico:
SPero per stanotte di committare la soluzione ;)
Forse ho trovato come risolvere un buon insieme di Bug relativo alla trasformazione di stone in gem...
...mancano solo i test :sofico: :sofico:
SPero per stanotte di committare la soluzione ;)
Esattamente a quali bug ti riferisci?
Ecco i bug che con 3 test dovrei essere riuscito a risolvere:
7 - Quando le pietre si trasformano in gemme eventuali cancellazioni non avvengono subito, ma solo dopo qualche secondo C
13 - Le pietre trasformate in gemme non vengono considerate per la creazione di BigGem B
14 - Quando una stone viene fatta cadere in una colonna piena, le gemspair smettono di cadere A (Bonfo)
21 - Talvolta il numero da mostrare sulla stone non viene assegnato correttamente in base alla profondità B
Del 14 non ne sono sicuro :(
Il problema era che le gemme inserite al posto delle stone non erano dropped.
Inoltre l'update veniva chiamato nel punto sbagliato. Ora è stato messo in GemsPairOnControllState.
99 fatto, tasti cambiati...però c'è un problema:
2002-11-24 20:35 elias_naur
* src/java/org/lwjgl/input/Keyboard.java: Removed PRINTSCREEN,
PAGEUP and PAGEDOWN again - need to remap instead
Dal changelog di lwjgl, a quanto pare non sono stati più rimessi, quindi al posto di pageup mi son permesso di mettere delete, joc, va bene lo stesso? Al massimo si cambia, pageup/down non ci sono :( E imho mettere quelli del numpad risulterebbe solo un suicidio per chi gioca da portatile
cdimauro
18-04-2006, 09:00
ARGH, ancora exception.
http://lnx.rc6.it/diamonds/varie/error02.jpg
Identico problema da Eclipse. Invece con Ant tutto OK, la build è verde.
Tra l'altro ho effettuato un checkout completo del progetto (cancellando prima TUTTA la cartella Diamonds), ma nonostante ciò dentro la cartella lib/jar Eclipse NON visualizza i jar che sono stati aggiunti che, però, risultano presenti nella cartella.
Tutte a me capitano!!! :cry: :muro:
BlueDragon
18-04-2006, 09:56
Hai seguito i passi descritti nell'altro thread di passaggio da OpenAL a Javasound?
Non sembra essere troppo pertinente al tuo caso, ma ho notato che non tutti i jar appaiono nella lib/jar, quelli aggiunti al buildpath Eclipse non li fa vedere lì, ma li mostra in un altro punto del progetto (non so perché).
Infatti se controlli quelli di lwjgl sono tutti nel build path, si trovano in lib/jar ma non si vedono lì da Eclipse :)
99 fatto, tasti cambiati...però c'è un problema:
2002-11-24 20:35 elias_naur
* src/java/org/lwjgl/input/Keyboard.java: Removed PRINTSCREEN,
PAGEUP and PAGEDOWN again - need to remap instead
Dal changelog di lwjgl, a quanto pare non sono stati più rimessi, quindi al posto di pageup mi son permesso di mettere delete, joc, va bene lo stesso? Al massimo si cambia, pageup/down non ci sono :( E imho mettere quelli del numpad risulterebbe solo un suicidio per chi gioca da portatile
... i tasti sono invertiti !!! :eekk:
Sonon stati assegnati i tasti del player1 al player2 e viceversa.
Inoltre i 3 tasti per le rotazioni accoppiati con le freccie direzionali non sono molto comodi ad L
Chi si sta occupando dei seguenti bug?
17 - GameOver bug: viene mostrata la scritta GameOver prima di controllare eventuali crush A
18 - Estensioni delle bigGem: se sono presenti 2 bigGem e se ne fa una 3° che può essere inglobata in entrambe formando così una unica bigGem, vengono unite solo 2 BigGem su 3 B
21 - Talvolta il numero da mostrare sulla stone non viene assegnato correttamente in base alla profondità B
Ragazzi prenotatevi che mancano solo 4 giorni e poi si chiude tutto.
Chi si sta occupando dei seguenti bug?
17 - GameOver bug: viene mostrata la scritta GameOver prima di controllare eventuali crush A
18 - Estensioni delle bigGem: se sono presenti 2 bigGem e se ne fa una 3° che può essere inglobata in entrambe formando così una unica bigGem, vengono unite solo 2 BigGem su 3 B
21 - Talvolta il numero da mostrare sulla stone non viene assegnato correttamente in base alla profondità B
Ragazzi prenotatevi che mancano solo 4 giorni e poi si chiude tutto.
il 21 è fatto :D
Io ora proprionon posso...ma bisognerebbe controllare che il 14 sia definitivamente risolto.
Importante: per ogni bug ci DEVE essere il relativo test. Non voglio fissare lo stesso bug dieci volte :)
Il fatto è che per il bug 14 il test c'è !!!!
Lo fatto addirittura io quando stavo facendo refactoring di StoneFallState.
testStoneInsertionIfStonesPresent
Ora l'inserimento si basa sulla profondità...quindi prima di bloccareil gioco si dovrebbe arrivare al gameOver.
Ora però sto riguardando il test NoStoneInsertion...che controlla che la stone non venga inserita se la colonna è piena....però ora il test non è proprio perfetto.
Controllo.
testNoStoneInsertion ora è corretto.
public void testNoStoneInsertion()
{
int rows = controller.getGrid().getNumberOfRows();
insertStoneRows(rows);
controller.setIncomingStones(1);
try
{
state.update(timer, controller);
}
catch(Exception e)
{
fail("The stone must not be insert");
}
}
Quindi il bug è risolto ora?
Aspetta....che Pirla.
Ecco forse ho scoperto cosa non ho testato ;)
10 min e arrivo ;)
cdimauro
18-04-2006, 11:35
Hai seguito i passi descritti nell'altro thread di passaggio da OpenAL a Javasound?
Mi sono fermato al punto 1, a causa dell'impossibilità di metterlo in atto:
1) Aggiungere BasicPlaye2.3.jar al build path.
Tasto destro su basicplayer2.3.jar -> Build Path -> Add to Build Path.
Non sembra essere troppo pertinente al tuo caso, ma ho notato che non tutti i jar appaiono nella lib/jar, quelli aggiunti al buildpath Eclipse non li fa vedere lì, ma li mostra in un altro punto del progetto (non so perché).
Infatti se controlli quelli di lwjgl sono tutti nel build path, si trovano in lib/jar ma non si vedono lì da Eclipse :)
Appunto, ma se non si devono non posso nemmeno andare avanti col punto 1. :(
Da command line comunque funziona, e con Ant non ci sono problemi: per adesso vado avanti così.
cdimauro
18-04-2006, 11:36
Controllo il bug 17.
cdimauro
18-04-2006, 11:41
In TestGameOverBox c'è un test vuoto:
public void testISShowingOnGameOver()
{
}
Chi ne sa qualcosa?
... i tasti sono invertiti !!! :eekk:
Sonon stati assegnati i tasti del player1 al player2 e viceversa.
Inoltre i 3 tasti per le rotazioni accoppiati con le freccie direzionali non sono molto comodi ad L
Cover, per favore, potresti sistemare questa inversione?
Usare Del va bene, tanto la rotazione a 180° non è un comando di importanza primaria.
public void testMoreThanEightStoneInsertionIfStonesPresent()
{
insertStoneRows(12);
controller.setIncomingStones(9);
state.update(timer, controller);
while(grid.droppedGemCanMoveDown())
{
state.update(timer, controller);
}
state.update(timer, controller);
Droppable stone = grid.getGemAt(0,0);
assertEquals("The number of stones in the grid must be equals",
8 * 12 + 9, grid.getNumberOfGems());
assertNotNull("The stone must be inserted", stone);
}
E direi che con questo il bug 14 va definitivamente in cantina ;)
Another one bites the dust! Bravo! :D
Con i nuovi tasti non riesco a testare il bug 14 in game :cry:
Identico problema da Eclipse. Invece con Ant tutto OK, la build è verde.
Tra l'altro ho effettuato un checkout completo del progetto (cancellando prima TUTTA la cartella Diamonds), ma nonostante ciò dentro la cartella lib/jar Eclipse NON visualizza i jar che sono stati aggiunti che, però, risultano presenti nella cartella.
Tutte a me capitano!!! :cry: :muro:
anche io avevo lo stesso problema su eclipse, ho risolto aggiungendo nel build path il jar commons-logging-api.jar, ho committato il file .classpath
Da vecchio giocatore di fps propongo la seguente configurazione per i tasti:
Player 1:
W,A,S,D per le direzioni. e C,V,B.
Player 2:
Freccine per le direzioni e 0,.,Invio Sul tastierino.
ciao ;)
Da vecchio giocatore di fps propongo la seguente configurazione per i tasti:
Player 1:
W,A,S,D per le direzioni. e C,V,B.
Player 2:
Freccine per le direzioni e 0,.,Invio Sul tastierino.
ciao ;)
quoto, sono d'accordo
quoto, sono d'accordo
:mano: :mano:
... i tasti sono invertiti !!! :eekk:
Sonon stati assegnati i tasti del player1 al player2 e viceversa.
Inoltre i 3 tasti per le rotazioni accoppiati con le freccie direzionali non sono molto comodi ad L
caxx, mea culpa...avevo letto male... :( ahi....le dita no...nemmeno le ginocchia...sigh :(
Sistemo subito
Da vecchio giocatore di fps propongo la seguente configurazione per i tasti:
Player 1:
W,A,S,D per le direzioni. e C,V,B.
Player 2:
Freccine per le direzioni e 0,.,Invio Sul tastierino.
ciao ;)
Io non sono molto d'accordo per il player2 "0 . invio", risultano sicuramente più comodi su pc normale, ma su portatileè ingiocabile (bisogna premere anche un'altro tasto per il tastierino...parecchio scomodo giocare così), mettere invece ", . -" ?
Io non sono molto d'accordo per il player2 "0 . invio", risultano sicuramente più comodi su pc normale, ma su portatileè ingiocabile (bisogna premere anche un'altro tasto per il tastierino...parecchio scomodo giocare così), mettere invece ", . -" ?
Perchè no ;)
caxx, mea culpa...avevo letto male... :( ahi....le dita no...nemmeno le ginocchia...sigh :(
Sistemo subito
Io non sono molto d'accordo per il player2 "0 . invio", risultano sicuramente più comodi su pc normale, ma su portatileè ingiocabile (bisogna premere anche un'altro tasto per il tastierino...parecchio scomodo giocare così), mettere invece ", . -" ?
Facciamo una prova.
Ho solo il dubbio che questa configurazione possa essere scomoda in due, perchè ci si urta con i tasti, ma provare non costa (quasi) nulla.
P.S.: ma per chi usa tastiere con layout differenti dal nostro "QWERTY", come ad esempio quelle USA o quelle francesi, cambierebbe la disposizione dei tasti, o la mappatura rimarrebbe uguale?
redcloud
18-04-2006, 14:19
Io non sono molto d'accordo per il player2 "0 . invio", risultano sicuramente più comodi su pc normale, ma su portatileè ingiocabile (bisogna premere anche un'altro tasto per il tastierino...parecchio scomodo giocare così), mettere invece ", . -" ?
Vada per il Player 1 ma per il Player 2 preferisco le frecce e 3 tasti tra Home' PagUp' PagDn' End' ,' .' e -' ma niente tastierino numerico che sui portatili nun se po!
cdimauro
18-04-2006, 14:27
Facciamo una prova.
Ho solo il dubbio che questa configurazione possa essere scomoda in due, perchè ci si urta con i tasti, ma provare non costa (quasi) nulla.
P.S.: ma per chi usa tastiere con layout differenti dal nostro "QWERTY", come ad esempio quelle USA o quelle francesi, cambierebbe la disposizione dei tasti, o la mappatura rimarrebbe uguale?
Penso proprio che cambierebbe: i tasti dovrebbero arrivare già "cucinati" (cookied :D) dal s.o.. Non credo che le librerie che stiamo usando permettano la ricezione del codice raw associato a quel tasto della tastiera.
cdimauro
18-04-2006, 14:28
anche io avevo lo stesso problema su eclipse, ho risolto aggiungendo nel build path il jar commons-logging-api.jar, ho committato il file .classpath
Adesso funziona tutto anche da Eclipse! :D
Grazie!!! :)
Facciamo una prova.
Ho solo il dubbio che questa configurazione possa essere scomoda in due, perchè ci si urta con i tasti, ma provare non costa (quasi) nulla.
P.S.: ma per chi usa tastiere con layout differenti dal nostro "QWERTY", come ad esempio quelle USA o quelle francesi, cambierebbe la disposizione dei tasti, o la mappatura rimarrebbe uguale?
Cambiati...per impostarli ha preso il layout americano (infatti il - l'ho dovuto mettere come /)
Sarebbe da trovare qualcuno che non ha tastiera qwerty e fargli provare...
Dopo si metterà la possibilità di impostare i tasti, o no?
cdimauro
18-04-2006, 15:45
Per quanto riguarda il bug n°17, sono giunto a due ipotesi.
La prima è che sia dovuto a un problema di asincronia fra l'update e il controllo di game over. Ciò a causa del seguente codice (GameLoop.java):
private void updateFields()
{
playFieldOne.update();
playFieldTwo.update();
checkAndShowGameOverMessage(playFieldOne);
checkAndShowGameOverMessage(playFieldTwo);
}
PlayField.java:
public void update()
{
if(lastUpdateTimeStamp + updateRate <= timer.getTime())
{
updatePlayField();
lastUpdateTimeStamp += updateRate;
score.setValue(getGridController().getGrid().computeTotalScore());
updateWarningBox();
updateCrushBox();
updateCounterBox();
}
}
L'update() di un playfield viene eseguito soltanto se è passato un certo lasso di tempo, mentre checkAndShowGameOverMessage() viene richiamato sempre.
Quindi se è possibile che l'update() produca l'inserimento di una GemsPair senza propagarne gli effetti, playfield.getGridController().isGameOver() tornerebbe (giustamente) true anziché false.
In tal caso basterebbe che anche il checkAndShowGameOverMessage(playFieldOne) venga eseguito alle stesse condizioni dell'update del playfield per risolvere il bug.
Se questa ipotesi non va bene, allora (GridController.java)
public boolean isGameOver()
{
if(!grid.isColumnFull(4))
{
return false;
}
return grid.getGemAt(0, 4).isNotFalling();
}
non deve basarsi esclusivamente sul fatto che la colonna è piena e che la prima gemma (quella più in alto) non sta cadendo, ma si dovrebbe controllare anche se la prime 2 gemme (la GemsPair) provocherebbero un crash che, quindi, libererebbe qualche posizione nella colonna.
Che ne pensate?
Cesare...io proverei la prima strada!!! ;)
Facciamo una prova.
Ho solo il dubbio che questa configurazione possa essere scomoda in due, perchè ci si urta con i tasti, ma provare non costa (quasi) nulla.
Io ho provato e in due non ci si da fastidio con la configurazione che ho proposto. I tasti sono lontani e non ci si da urta neanche che con le braccia.
Certo giocare cosi sul portatile è impossibile.
Che ne dite di mettere in qualche modo i tasti nel file di configurazione cosi da poterli rimappare senza ricompilare il gioco? Potremmo fare persino dei profili diversi per le tastiere normali e quelle dei portatili.
ciao ;)
Mi confermate la morte del 14?
Cover, è possibile inserire i comandi in GameConfig, magari in fondo e lasciando una riga vuota per distinguerli dal resto?
cdimauro
18-04-2006, 16:54
Cesare...io proverei la prima strada!!! ;)
OK, grazie per il consiglio.
L'impresa qui non sarà tanto quella di fixare il bug, se è questa la causa, ma di scrivere un test che lo evidenzi. :p
Io ho provato e in due non ci si da fastidio con la configurazione che ho proposto. I tasti sono lontani e non ci si da urta neanche che con le braccia.
Certo giocare cosi sul portatile è impossibile.
Che ne dite di mettere in qualche modo i tasti nel file di configurazione cosi da poterli rimappare senza ricompilare il gioco? Potremmo fare persino dei profili diversi per le tastiere normali e quelle dei portatili.
ciao ;)
Dopo la FP! Ora abbiamo una montagna di bug da fissare :)
Non l'ho chiarito con un topic, ma in questo momento siamo totalmente 'feature lock', gli unici commit autorizzati sono quelli che fissano un bug. Solo BD e Ufo sono autorizzati ancora per oggi a lavorare sui loro due task (Musica e Stones). Se entro domani non sono chiusi, vengono tagliati per la FP.
Per tutti gli altri si tratta solo di fissare bug e di toccare il codice il meno possibile per non rischiare di introdurne di nuovi. Siamo a quattro giorni dal lock della First Playable. Poi si impacchetta e si rilascia.
Mi confermate la morte del 14?
Cover, è possibile inserire i comandi in GameConfig, magari in fondo e lasciando una riga vuota per distinguerli dal resto?
No Joc, tenete le mani lontano dalla build fino a lunedi' :D
No Joc, tenete le mani lontano dalla build fino a lunedi' :D
Ok, giù le mani o ci ritroveremo le ditine magicamente spezzate.
Bonfo, come siamo messi con il 14?
Cesare si sta occupando del 17, chi pensa agli altri?
io sto riprendendo confidenza col codice...e provo a vedere se riesco a risolvere il 18
Bonfo, come siamo messi con il 14?
Risolto alle ore 12:15 come da post. :D
Non sono riuscito a testarlo in game...e ora non posso.
Ma sto giro è garantito ;)
...speriamo di salvare ditine e ginocchia :D :D
EDIT: ops...postato 2 volte ;)
...speriamo di salvare ditine e ginocchia :D :D
Ma vi sto proprio terrorizzando :D
Bene... bene...
A parte gli scherzi, durante i periodi in cui c'era una deliverable come questa il clima in ufficio era da legge marziale, repository lockato fisicamente, per effettuare un commit bisognava giustificarlo, mostrare il bug e il fix, farlo testare a due tester, poi farsi fare una review del codice, farsi dare il permesso per il commit, recitare il rosario e poi, forse, si riceveva l'autorizzazione. Appena effettuato il commit scattavano i sensi di colpa e le paure, e se va storto? Gente inferocita che girava con gl'occhi inniettati di sangue per l'ufficio a caccia dell'autore dell'ultimo commit, i tester che assumevano potere di vita e di morte ed il mitico mostro mitologico che rispondeva al nome di EA QA LA (pronunciatelo all'inglese) sempre in agguato.
Quello che state subendo voi e' niente in confronto a quello che ho subito io, mi ritorgo solo contro di voi :P
allora, bug 18, ecco il test che non passa:
public void testMergeThreeBigGem()
{
insertBigGem(EMERALD,11,3,12,6);
grid.updateBigGems();
insertBigGem(EMERALD,8,5,10,6);
grid.updateBigGems();
insertBigGem(EMERALD,8,3,10,4);
grid.updateBigGems();
assertSame("there isn't only one bigGem", grid.getBigGemAt(11, 3), grid.getBigGemAt(8, 3));
assertSame("there isn't only one bigGem", grid.getBigGemAt(11, 3), grid.getBigGemAt(8, 5));
}
adesso cerco di farlo passare...
Bene, chi si occupa del 6?
nel far passare il test, mi sono accorto della presenza di un'altra situazione potenziale di bug, evidenziata dal seguente test:
public void testMergeThreeBigGemRight()
{
insertBigGem(EMERALD,8,3,12,4);
grid.updateBigGems();
insertBigGem(EMERALD,10,5,12,6);
grid.updateBigGems();
insertBigGem(EMERALD,8,5,9,6);
grid.updateBigGems();
assertSame("there isn't only one bigGem", grid.getBigGemAt(8, 3), grid.getBigGemAt(10, 5));
assertSame("there isn't only one bigGem", grid.getBigGemAt(8, 3), grid.getBigGemAt(8, 5));
}
Quello che state subendo voi e' niente in confronto a quello che ho subito io, mi ritorgo solo contro di voi :P
Tranquillo fek...prima o poi scopriremo dove abiti precisamente, e te le faremo pagare tutte....
Ahi...le dita no, nooooo :Prrr:
nel far passare il test, mi sono accorto della presenza di un'altra situazione potenziale di bug, evidenziata dal seguente test:
public void testMergeThreeBigGemRight()
{
insertBigGem(EMERALD,8,3,12,4);
grid.updateBigGems();
insertBigGem(EMERALD,10,5,12,6);
grid.updateBigGems();
insertBigGem(EMERALD,8,5,9,6);
grid.updateBigGems();
assertSame("there isn't only one bigGem", grid.getBigGemAt(8, 3), grid.getBigGemAt(10, 5));
assertSame("there isn't only one bigGem", grid.getBigGemAt(8, 3), grid.getBigGemAt(8, 5));
}
Di che bug si tratta?
Jocchan, la stessa situazione che si è presentata a cover, ma ribaltata di 90° a destra....
ho committato le modifiche relative al fix del bug 18 e 18 bis diciamo
Dopo la FP! Ora abbiamo una montagna di bug da fissare :)
OK. :)
Visto che ci siamo dobbiamo anche modificare gli script per fare degli zip decenti. Quello di ora ha il codice compilato in tre parti diverse. in gfx e data ci sono anche file che usiamo per i test. In lib poi distribuiamo sia librerie di sviluppo come junit, roxes che quelle di tutti e tre sistemi operativi.
Mi piacerebbe avere tre zip del tipo: diamond-crush_linux.zip diamond-crush_win32.zip diamond-crush_osx.zip.
Oltra cosa importante è fare il revert del task di Blue Dragon che per ora crea solo problemi.
ciao ;)
Quindi decisione finale? Si fa il revert del task di BD?
Vic, te ne occupi tu?
Personalmente preferirei avere un unico zip con tutto dentro, ma se pensi che avere zip differenti per i differenti SO sia meglio, facciamo cosi'. E' ok. Ci penso io nel finesettimana.
Quindi decisione finale? Si fa il revert del task di BD?
Vic, te ne occupi tu?
Personalmente preferirei avere un unico zip con tutto dentro, ma se pensi che avere zip differenti per i differenti SO sia meglio, facciamo cosi'. E' ok. Ci penso io nel finesettimana.
Posso pensare ad entrambi io che in questi giorni ho molto tempo libero.
ciao ;)
BlueDragon
18-04-2006, 21:47
Revertate, revertate...così posso committare la versione .ogg :p
Forse riesco a finirla entro stasera....che è il limite massimo, dico bene? :)
allora, ho in mente una soluzione per il bug 6 e chè legata anche a quello che penso stia facendo cdimauro con l bug 17 (ma sto numero non si poteva saltare nella numerazione dei bugs!?!), allora, in GameLoop:
private void updateFields()
{
playFieldOne.update();
playFieldTwo.update();
checkAndShowGameOverMessage(playFieldOne);
checkAndShowGameOverMessage(playFieldTwo);
}
private void checkAndShowGameOverMessage(PlayField field)
{
if (!field.getGridController().isGameOver())
{
return;
}
field.showGameOverMessage();
}
checkAndShowGameOverMessage mi sembra un metodo che si possa spostare tranquillamente in PlayField, da eseguire nell'update (così si dovrebbe risolvere il bug 17..), a questo punto il metodo si potrebbe modificare in checkGameOver, che appunto si occupa di attendere 2 sec (da settare in Config??) e resettare i playField (non c'è null'altro da resettare giusto?)....cosa ne pensate?
Resettando i playField cambia anche il seed del generatore random?
Chiedo questo perchè dobbiamo farlo cambiare :)
beh, ho parlato di resettare il PlayField, ma non esiste un metodo reset in PlayField, quindi ancoraè tutto da vedere, ancora non mi sbilancio perchè solo oggi ho cominciato a riprendere confidenza con il codice....cmq, più che un bug questo mi pare più un piccolo task...
beh, ho parlato di resettare il PlayField, ma non esiste un metodo reset in PlayField, quindi ancoraè tutto da vedere, ancora non mi sbilancio perchè solo oggi ho cominciato a riprendere confidenza con il codice....cmq, più che un bug questo mi pare più un piccolo task...
E' vero, in questo caso la differenza è molto labile, ma avere il reset è importante per la versione da distribuire.
Dopo il commit sulle librerie audio il .bat non va più :(
Qualcuno mette a posto l'uso delle librerie sia da eclipse che dal .bat e .sh ???
Io non posso... :cry:
BlueDragon
19-04-2006, 01:44
Dopo il commit sulle librerie audio il .bat non va più :(
Qualcuno mette a posto l'uso delle librerie sia da eclipse che dal .bat e .sh ???
Io non posso... :cry:
Ho committato ora il bat e l'sh aggiungendo le 3 nuove librerie al loro classpath :)
Chiedo perdono, non me li ero proprio ricordati :)
Implementata la cancellazione delle stone :)
cdimauro
19-04-2006, 09:27
allora, ho in mente una soluzione per il bug 6 e chè legata anche a quello che penso stia facendo cdimauro con l bug 17 (ma sto numero non si poteva saltare nella numerazione dei bugs!?!), allora, in GameLoop:
private void updateFields()
{
playFieldOne.update();
playFieldTwo.update();
checkAndShowGameOverMessage(playFieldOne);
checkAndShowGameOverMessage(playFieldTwo);
}
private void checkAndShowGameOverMessage(PlayField field)
{
if (!field.getGridController().isGameOver())
{
return;
}
field.showGameOverMessage();
}
checkAndShowGameOverMessage mi sembra un metodo che si possa spostare tranquillamente in PlayField, da eseguire nell'update (così si dovrebbe risolvere il bug 17..), a questo punto il metodo si potrebbe modificare in checkGameOver, che appunto si occupa di attendere 2 sec (da settare in Config??) e resettare i playField (non c'è null'altro da resettare giusto?)....cosa ne pensate?
Penso che questo metodo sarebbe già dovuto stare in PlayField, visto che opera interamente con quest'oggetto. ;)
E anch'io penso che, se richiamato all'interno di PlayField.update, alla fine delle altre operazioni che in esso vengono eseguite, DOVREBBE risolvere il bug 17.
Dico dovrebbe perché, in ogni caso, prima dovrei scrivere il test che evidenzi questo bug, che attualmente è più complicato del fix. :p
Vediamo se per la pausa pranzo riesco a tirare fuori qualcosa, magari frugando ancora fra i sorgenti.
Comunque come soluzione andrebbe bene se l'update di un playfield non comporti modifiche all'altro. Questo perché attualmente vengono prima aggiornati i due playfield, e poi richiamati i rispettivi checkAndShowGameOverMessage.
In realtà il punto ideale per il controllo del GameOver è nello state prima di inserire la nova GemsPair.
Lì si è sicuri che il playField è "stabile" :D
Mi aggiornate sui seguenti bug?
6 - Quando uno dei due giocatori fa Game Over il gioco deve fermarsi 2 secondi, e resettarsi automaticamente B
17 - GameOver bug: viene mostrata la scritta GameOver prima di controllare eventuali crush A
18 - Estensioni delle bigGem: se sono presenti 2 bigGem e se ne fa una 3° che può essere inglobata in entrambe formando così una unica bigGem, vengono unite solo 2 BigGem su 3 B
6, 17 e 18. Sul 17 c'e' Cesare. Sul 18 c'e' cover. Sul 6?
il 18 l'ho fixato, adesso mi stavo guardando il codice per il 6....
Ho fatto il commit del nuovo build.xml. Sembra tutto perfetto tranne un piccolo particolare. Il file .exe di Windows non funziona. Purtroppo la finestra del cmd.exe si apre e si chiude troppo velocemente per riuscire a capire qualcosa quindi non riesco a capire che cavolo succede. Qualcuno sa come impedire a questo magnifico sistema operativo di fare i cavoli suoi ?
I test prima della dist li rimetto appena sistemo questo problema. Giuro :D
ciao ;)
Altre due piccole cose che mi sono venute in mente mentre guardavo il build.
1. C'è la possibilità di specificare una icona da dare al eseguibile .exe. Qualche artista ci fa un .ico ?
2. Ora che abbiamo il supporto per gli ogg che funziona (:ave: BlueDragon) dovremmo convertire diamong.wav che piglia mezzo mega da solo in ogg.
ciao ;)
Ho fatto il commit del nuovo build.xml. Sembra tutto perfetto tranne un piccolo particolare. Il file .exe di Windows non funziona. Purtroppo la finestra del cmd.exe si apre e si chiude troppo velocemente per riuscire a capire qualcosa quindi non riesco a capire che cavolo succede. Qualcuno sa come impedire a questo magnifico sistema operativo di fare i cavoli suoi ?
I test prima della dist li rimetto appena sistemo questo problema. Giuro :D
ciao ;)
Hai provato a lanciare l'exe dal command prompt (la shell, per voi che siete ancora all'eta' della pietra :P).
Altre due piccole cose che mi sono venute in mente mentre guardavo il build.
1. C'è la possibilità di specificare una icona da dare al eseguibile .exe. Qualche artista ci fa un .ico ?
2. Ora che abbiamo il supporto per gli ogg che funziona (:ave: BlueDragon) dovremmo convertire diamong.wav che piglia mezzo mega da solo in ogg.
ciao ;)
Immagino che sia possibile, stasera devo guardare le opzioni. Se non e' possibile, possiamo sempre scriverci noi un piccolo launcher in C++ e appiccicargli l'icona.
L'icona vedrò insieme a XAndE di prepararla oggi.
Per l'exe, suppongo che l'exception sia quella che capitava a me:
http://lnx.rc6.it/diamonds/varie/error03.jpg
Dovrebbe bastare cambiare qualche impostazione di Cruise Control per fargli riconoscere le librerie per essere a posto.
cdimauro
19-04-2006, 14:18
In realtà il punto ideale per il controllo del GameOver è nello state prima di inserire la nova GemsPair.
Lì si è sicuri che il playField è "stabile" :D
Mi potresti dare qualche dritta? A quale parte del codice ti riferisci?
Io preferirei effettuare il controllo del GameOver DOPO che gli input siano stati processati ed eventuali azioni siano state eseguite; quindi dopo l'update dei playfield.
I playfield dovrebbero comunque risultare stabili anche dopo queste operazioni, o sbaglio?
Ti chiedo questo perché sto cercando di chiarirmi le idee per capire quale soluzione eventualmente adottare per questo bug.
Grazie. :)
EDIT: fran ha anticipato la mia risposta a Vicius. :D
Hai provato a lanciare l'exe dal command prompt (la shell, per voi che siete ancora all'eta' della pietra :P).
Ti sarei grato se non paragonassi quel cesso di cmd.exe a bash. :p
Lanciando l'exe dal prompt se ne apre un'altro e poi si richiude. Idea geniale.
Immagino che sia possibile, stasera devo guardare le opzioni. Se non e' possibile, possiamo sempre scriverci noi un piccolo launcher in C++ e appiccicargli l'icona.
Basta specificare il file nel jstub. Manca solo l'icona :)
ciao ;)
Penso che questo metodo sarebbe già dovuto stare in PlayField, visto che opera interamente con quest'oggetto. ;)
E anch'io penso che, se richiamato all'interno di PlayField.update, alla fine delle altre operazioni che in esso vengono eseguite, DOVREBBE risolvere il bug 17.
Dico dovrebbe perché, in ogni caso, prima dovrei scrivere il test che evidenzi questo bug, che attualmente è più complicato del fix. :p
Vediamo se per la pausa pranzo riesco a tirare fuori qualcosa, magari frugando ancora fra i sorgenti.
Comunque come soluzione andrebbe bene se l'update di un playfield non comporti modifiche all'altro. Questo perché attualmente vengono prima aggiornati i due playfield, e poi richiamati i rispettivi checkAndShowGameOverMessage.
vabbè, il checkGameOver di cui parlavo prima io si potrebbe richiamare prima degli update, in questo caso si avrebbe un controllo di 1 ms in ritardo....non penso sia questo il problema....
http://lnx.rc6.it/diamonds/varie/error03.jpg
Questo è l'errore che ti da lanciando l'exe dopo il mio commit ?
ciao ;)
cdimauro
19-04-2006, 14:21
Ti sarei grato se non paragonassi quel cesso di cmd.exe a bash. :p
bash la uso anche con Windows. ;)
Lanciando l'exe dal prompt se ne apre un'altro e poi si richiude. Idea geniale.
Già. Sun rulez. :asd:
cdimauro
19-04-2006, 14:24
vabbè, il checkGameOver di cui parlavo prima io si potrebbe richiamare prima degli update, in questo caso si avrebbe un controllo di 1 ms in ritardo....non penso sia questo il problema....
Come ho scritto a Bonfo, mi piacerebbe effettuare questo controllo "finale" quando tutti gli input sono stati processati e lo stato dei playfield aggiornato. Mi sembra il momento migliore per poterlo fare, e lo stato dovrebbe essere "stabile".
In questo modo non dovrebbe esserci nessun ritardo.
Questo è l'errore che ti da lanciando l'exe dopo il mio commit ?
ciao ;)
No, è l'errore che mi dava stanotte la build dopo l'aggiunta dell'audio in ogg.
Ora non so se è lo stesso, provo a scaricare l'ultima build.
Come ho scritto a Banfo, mi piacerebbe effettuare questo controllo "finale" quando tutti gli input sono stati processati e lo stato dei playfield aggiornato. Mi sembra il momento migliore per poterlo fare, e lo stato dovrebbe essere "stabile".
In questo modo non dovrebbe esserci nessun ritardo.
Un millisecondo di ritardo nel check non e' un problema. Al momento mi interessa solo la soluzione piu' semplice da implementare.
allora, se non ho capito male, Bonfo suggerisce di effettuare il controllo nel GameOverState, a me non sembra il luogo adatto, sono d'accordo con cdimauro, alla fine se effettuiamo il controllo prima, non facciamo altro che controllare 1 ms dopo quello che è successo nel ciclo precedente.....
Mi potresti dare qualche dritta? A quale parte del codice ti riferisci?
Lavorando con le stone mi sono reso conto che molto azioni di playfield dipendono da gridController...o meglio dai suoi stati.
Infatti per il counter mi sono inventato una metodo che praticamente setta una vairabile e playfield se la va a leggere per capire coasa fare.
(Secondo me quando faremo il refactoring della action e degli state bisogn aggiungere gli eventi!!)
Detto questo, lo satato WaitStateBeforeNewGemsPair è quello che gestisce l'istante prima di una nuova gemsPair.
Direi che lì si è per forza in uno stato stabile.
Io lì farei tutti i controlli del caso...e se c'è da fare gameover lo si fa ;)
ASP....ma c'è già pure il GameOverState in WaitStateBeforeNewGemsPair....
....cosa voglio di più dalla vita...un lucano :D :D
Come ho scritto a Bonfo, mi piacerebbe effettuare questo controllo "finale" quando tutti gli input sono stati processati e lo stato dei playfield aggiornato. Mi sembra il momento migliore per poterlo fare, e lo stato dovrebbe essere "stabile".
Non è detto ....perchè l'update di palyfield fa avanzare di uno stato gridController.E mmolti stati ritornano loro stessi in alcuni casi...quyindi c'è il rischio di fare il controllo quando alcuni crush non sono ancora finiti.
cdimauro
19-04-2006, 14:35
Un millisecondo di ritardo nel check non e' un problema. Al momento mi interessa solo la soluzione piu' semplice da implementare.
OK
allora, se non ho capito male, Bonfo suggerisce di effettuare il controllo nel GameOverState, a me non sembra il luogo adatto, sono d'accordo con cdimauro, alla fine se effettuiamo il controllo prima, non facciamo altro che controllare 1 ms dopo quello che è successo nel ciclo precedente.....
Se finisco in quello stato vuol dire che sono in GameOver.
Quale posto migliore per dire a plyfield di mostrare la png?!?!
cdimauro
19-04-2006, 14:38
Non è detto ....perchè l'update di palyfield fa avanzare di uno stato gridController.E mmolti stati ritornano loro stessi in alcuni casi...quyindi c'è il rischio di fare il controllo quando alcuni crush non sono ancora finiti.
Mumble. Leggendo questo e il tuo precedente post mi sto chiarendo le idee, grazie. :)
A questo punto la domanda sorge spontanea: mi vuoi dire che ogni chiamata all'update fa avanzare di un passo alla volta lo stato del playfield / gridcontroller?
Quindi se, ad esempio, una gemspair scatena un crash, e questo un altro ancora, il risultato finale (lo stato "stabile") di playfield si avrà soltanto dopo i 3 update?
piccola domanda, ma adesso qual'è il ruolo del GameOverState? cioè, non mi sembra che vada ad influire sulla scelta di mostrare o meno il GameOver message
mumble mumble....
....direi di sì.
Questo è gridController.
public void update(TimerInterface timer)
{
gemsPair.update(timer);
currentState = currentState.update(timer, this);
grid.updateGemAnimations(timer);
}
Questo è in CrushSate
return new GemFallState(config);
in gemFallState cìè questo
if (grid.droppedGemCanMoveDown())
{
return this;
}
else
{
grid.setNormalGravity();
return getWaitNextCrushState(timer, gridController);
}
....e poteri andare avanti a lungo.
Praticamente ogni volta che si fa gridController.update() arrivano in ordine:
crushSTate.update()
gemsFallSTate.update() * n
WaitNextCrushState.update()*n
CrushState().update
Quindi mi sa che ce ne vogliono più di 3 di playfield.update :( :(
cdimauro
19-04-2006, 14:45
x cisc
Infatti i test di TestGridController:
public void testGridNotGameOver()
{
assertFalse(grid.isColumnFull(4));
}
public void testGridGameOver()
{
fillColumn(4);
assertTrue(grid.isColumnFull(4));
}
public void testIsNotGameOver()
{
assertFalse(controller.isGameOver());
}
public void testIsGameOver()
{
fillColumn(4);
assertTrue(controller.isGameOver());
}
public void testIsNotGameOverWithFallingGem()
{
grid.insertGem(13, 4, gem);
gemsPair.setPivotGem(gem);
assertFalse(controller.isGameOver());
}
public void testControllerGameOver()
{
try
{
fillColumn(4);
controller.update(timer);
timer.advance(300);
controller.update(timer);
}
catch(Exception e)
{
fail("GridController can't manage \"game over\" conditions");
}
}
cozzano col codice di GridController:
public boolean isGameOver()
{
if(!grid.isColumnFull(4))
{
return false;
}
return grid.getGemAt(0, 4).isNotFalling();
}
e di Grid:
public boolean isColumnFull(int column)
{
if(isGemAt(0, column))
{
return getGemAt(0, column).isNotFalling();
}
return false;
}
ragazzi, secondo me il problema si risolverebbe cambiando isGameOver di GridController così:
public boolean isGameOver()
{
return currentState.isCurrentState("GameOver");
}
e poi effettuando il controllo nel GameLoop su entrambi i playField...
cdimauro
19-04-2006, 14:51
mumble mumble....
....direi di sì.
Questo è gridController.
public void update(TimerInterface timer)
{
gemsPair.update(timer);
currentState = currentState.update(timer, this);
grid.updateGemAnimations(timer);
}
Questo è in CrushSate
return new GemFallState(config);
in gemFallState cìè questo
if (grid.droppedGemCanMoveDown())
{
return this;
}
else
{
grid.setNormalGravity();
return getWaitNextCrushState(timer, gridController);
}
....e poteri andare avanti a lungo.
Praticamente ogni volta che si fa gridController.update() arrivano in ordine:
crushSTate.update()
gemsFallSTate.update() * n
WaitNextCrushState.update()*n
CrushState().update
Quindi mi sa che ce ne vogliono più di 3 di playfield.update :( :(
OK, direi che ci siamo. Allora sono i metodi e i test che ho postato sopra che sono sbagliati e vanno corretti "agganciandoli" a GameOverState.
ragazzi, secondo me il problema si risolverebbe cambiando isGameOver di GridController così:
public boolean isGameOver()
{
return currentState.isCurrentState("GameOver");
}
e poi effettuando il controllo nel GameLoop su entrambi i playField...
Mi piace :D :D
cdimauro
19-04-2006, 14:52
ragazzi, secondo me il problema si risolverebbe cambiando isGameOver di GridController così:
public boolean isGameOver()
{
return currentState.isCurrentState("GameOver");
}
e poi effettuando il controllo nel GameLoop su entrambi i playField...
Bingo! Mi hai tolto le parole di bocca. :p
cdimauro
19-04-2006, 14:55
Mi piace :D :D
Idem. :) Questo però va bene per il codice: speriamo che i test che usano isGameOver passino (ho più di qualche dubbio. :( )
Idem. :) Questo però va bene per il codice: speriamo che i test che usano isGameOver passino (ho più di qualche dubbio. :( )
ho anche io qualche dubbio.....
cdimauro
19-04-2006, 14:58
Provo subito la modifica al codice che hai suggerito e vediamo come va a finire. :p
Fra un esame e l'altro sto facendo il tifo...mi dispiace di non poter partecipare attivamente... Venerdì ho un altro esame...
PS: 30 stamattina !!!
Fra un esame e l'altro sto facendo il tifo...mi dispiace di non poter partecipare attivamente... Venerdì ho un altro esame...
PS: 30 stamattina !!!
complimenti!!! falli neri anche venerdì;)
tornando al gameOver, ho applicato la modifica è c'ho 3 tests che non passano +:
testGameOversAreDisplayingCorrectly in TestGameLoop
testIsGameOver in TestGridController
testControllerGameOver in TestGridController
prima di mettere mano a questi test vorrei il parere degli altri (e di chi magari li ha fatti...)
Domanda: cesare sei riuscito a fare un test chemotri il bug??
Sarebbe da fare prima di una qualsiasi modifica. :O
cdimauro
19-04-2006, 15:24
complimenti!!! falli neri anche venerdì;)
Complimenti anche da parte mia. :)
tornando al gameOver, ho applicato la modifica è c'ho 3 tests che non passano +:
testGameOversAreDisplayingCorrectly in TestGameLoop
testIsGameOver in TestGridController
testControllerGameOver in TestGridController
prima di mettere mano a questi test vorrei il parere degli altri (e di chi magari li ha fatti...)
Idem. Ed era prevedibile.
cdimauro
19-04-2006, 15:28
Domanda: cesare sei riuscito a fare un test chemotri il bug??
Sarebbe da fare prima di una qualsiasi modifica. :O
Diciamo prima di effettuare il commit. ;)
Comunque no, ancora non l'ho potuto fare. Non ho potuto effettuare nemmeno la modifica di cisc perché Eclipse s'è impallato: non riesce a risolvere nemmeno i riferimenti alle classi che abbiamo costruito. Ho effettuato il checkout, ma stesso problema.
Il bello è che se faccio la build con ant dopo il checkout va tutto bene. Ma appena mi azzardo anche soltanto salvare (anche senza aver fatto modifiche al codice), Eclipse sclera.
Tutte a me capitano!!! :(
Sto rieseguendo nuovamente il checkout: vediamo se riesce a riprendersi. :muro:
allora, un problema è in WaitStateBeforeNewGemsPair, infatti nell'update:
if(gridController.isGameOver())
{
return new GameOverState();
}
in pratica in questo modo non andiamo mai in gameOver....al momento la prima idea che mi viene in mente è aggiungere un metodo con visibilità di package che va a rifare il controllo che si faceva prima in isGameOver
Prima il test, poi la modifica, poi il commit :P
Buon lavoro ragazzi.. In questi giorni sto praticamente senza connessione, come siamo messi con i bug? Di urgente cosa abbiamo oltre il GameOver?
P.S. ho trovato un amico con cui provare il gioco e ci siamo fatti un po' di partite... In alcuni casi le BigGem si spezzano in due lasciando dei vuoti in mezzo! Non ho ancora isolato il caso :P
cdimauro
19-04-2006, 15:43
Eclipse è tornato a funzionare. :p
Confermo anche il fallimento di quei test, apportando la modifica di cisc.
cdimauro
19-04-2006, 15:48
allora, un problema è in WaitStateBeforeNewGemsPair, infatti nell'update:
if(gridController.isGameOver())
{
return new GameOverState();
}
in pratica in questo modo non andiamo mai in gameOver....
E' il classico cane che si mangia la coda. :(
al momento la prima idea che mi viene in mente è aggiungere un metodo con visibilità di package che va a rifare il controllo che si faceva prima in isGameOver
Mumble. Non è detto che funzioni, perché non fa un controllo sul tipo di gemme di cui è composta la GemsPair, che potrebbe provocare un crash.
cdimauro
19-04-2006, 15:50
Prima il test, poi la modifica, poi il commit :P
Era soltanto una prova!!! :fiufiu: :D
OK, OK: ci tengo alle mie dita. :p
Io tra poco devo staccare, perché ho una laurea & annessa festa. Per il test se ne parla domani. Ho già in mente qualcosa: spero che vada bene.
E' il classico cane che si mangia la coda. :(
Mumble. Non è detto che funzioni, perché non fa un controllo sul tipo di gemme di cui è composta la GemsPair, che potrebbe provocare un crash.
non più, perchè il controllo verrà fatto in WaitStateBeforeNewGemsPair, dove tuttele crash sono avvenute e si attende solo un delay prima di inserire una numa GemsPair
cdimauro
19-04-2006, 15:56
Hai ragione. Problema risolto, allora. :)
Hai ragione. Problema risolto, allora. :)
manca solo il test.........provo a vedere se riesco io a fare qualcosa...cmq:
public void testGameOversAreDisplayingCorrectly()
{
MockEngine engine = new MockEngine();
gameLoop.setEngine(engine);
LayerManager layerManager = gameLoop.getLayerManager();
gameLoop.doOneStep();
engine.clearDisplay();
layerManager.drawLayers(engine);
int numberOfQuadsDrawn = engine.getNumberOfQuadsDrawn();
gameLoop.getPlayFieldOne().getGridController().getGemsPair().getPivotGem().drop();
gameLoop.getPlayFieldOne().getGridController().getGemsPair().getSlaveGem().drop();
gameLoop.getPlayFieldTwo().getGridController().getGemsPair().getPivotGem().drop();
gameLoop.getPlayFieldTwo().getGridController().getGemsPair().getSlaveGem().drop();
gameLoop.doOneStep();
engine.clearDisplay();
layerManager.drawLayers(engine);
assertEquals("Game over message must be shown", numberOfQuadsDrawn + 2,
engine.getNumberOfQuadsDrawn());
}
non capisco bene questo test, qualcuno può chiarirlo?
non più, perchè il controllo verrà fatto in WaitStateBeforeNewGemsPair, dove tuttele crash sono avvenute e si attende solo un delay prima di inserire una numa GemsPair
Perfetto...era quello a cui volevo arivarei io...il controllo viene fatto quando tutte le palle sono ferme....opss...gemme :D
Per ciò che riguarda il test, pensi che serva per controllare che il GameOverBox sia aggiunto al LayerManager.
Si risolverà da solo appena messo a posto il controllo in WaitStateBeforeNewGemsPair...almeno penso ;)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.