View Full Version : First Playable Lock Venerdì 21 Aprile - CHECKLIST + BUG LIST
cdimauro
19-04-2006, 16:07
Abbastanza criptico, direi. E fa uso di funzionalità che troviamo soltanto in MockEngine e non in Engine.
Anche questo salterà dopo la FP, al prossimo mega-refactoring di Engine/Texture, Audio/Sound, ecc.
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 ;)
ho applicato la modifica come prova, e il test non passa......
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?
Testa che se la gemspair è stoppata in 0,4 deve essere mostrata la png del gameover... Probabilmente va cambiato :)
questo è il test relativo al bug 17, che non passava prima e con l'ultima modifica a isGameOver passa:
public void testNotGameOverInCrushState() {
for(int i = 1; i < 14; i++)
{
Droppable newGem = Gem.createForTesting();
grid.insertGem(i, 4, newGem);
gemsPair.setPivotGem(newGem);
newGem.drop();
}
Droppable gem = createChest(DIAMOND);
grid.insertGem(0,4,gem);
grid.updateGem(gem);
controller.update(timer);
assertFalse("Not here in game over",controller.isGameOver());
controller.update(timer);
timer.setTime(config.getInteger("NewGemDelay"));
controller.update(timer);
assertFalse("Not here in game over",controller.isGameOver());
}
se mi confermate che il test va bene committo
Se sei sicuro VAI!!!
....tanto le dita sono le tue :Prrr: :Prrr: :Prrr:
Ma non e' che a questo ritmo finite prima di Venerdi' e non abbiamo niente da fare? :D
Se sei sicuro VAI!!!
....tanto le dita sono le tue :Prrr: :Prrr: :Prrr:
c'ho sempre il testGameOversAreDisplayingCorrectly che non passa
Jocchan. La cancellazione delle stone ora funziona quindi direi che puoi modificare il messaggio nella prima pagina. In quanto a feature siamo al completo ora. Ci rimangono gli ultimi bug e poi abbiamo finito.
ciao ;)
Ma non e' che a questo ritmo finite prima di Venerdi' e non abbiamo niente da fare? :D
Gli si trova qualcosa da fare. Anche a costo di introdurre bug apposta :D
ciao ;)
Cisc, fai qualche test in locale e dopo via libera per il commit.
Vic, fatto.
Stasera su msn ti passo le icone per windows e mac.
Jocc...ti sei scordato di togliere il bug 18...mi sa che cisc la fixato ;)
Jocc...ti sei scordato di togliere il bug 18...mi sa che cisc la fixato ;)
Non l'ho scordato, aspettavo conferme.
17 e 18 sono ufficialmente morti?
Sarò AFK un paio d'ore. Cionci, se ci sei, per favore, potresti aggiornare tu al posto mio lo status di 17 e 18? Grazie!
Non l'ho scordato, aspettavo conferme.
17 e 18 sono ufficialmente morti?
Sarò AFK un paio d'ore. Cionci, se ci sei, per favore, potresti aggiornare tu al posto mio lo status di 17 e 18? Grazie!
fra poco esco un paio di ore, il testGameOversAreDisplayingCorrectly non passa, se volete testare che il comportamento relativo al bug 17 sia risolto, commento il test e committo, altrimenti stasera cerco di aggiustare il test......e di vedere per il bug 6, se non c'è nessun altro che se ne vuole occupare..
Risolto il bug dell'eccezione OpenAL che veniva generata chiudento la finestra.
Non capisco perchè ma nei test l'eccezione non veniva lanciata... Ho modificato un test comunque per aggiungere la riga di codice per fermare la musica
Sigh, sotto gentoo continua a non andare :(
Tutto aggiornato, ma nulla...qualcuno ha per caso gentoo e gli funziona?
Allego un txt con i vari log
Sotto Xp invece funziona...
Allego un txt con i vari log
Questo è un po' strano:
List of available display modes:
1280 x 1024 x 24 @85Hz
Best mode: 0 x 0 x 0 @0Hz
Scheda video ?
Non l'ho scordato, aspettavo conferme.
17 e 18 sono ufficialmente morti?
Sarò AFK un paio d'ore. Cionci, se ci sei, per favore, potresti aggiornare tu al posto mio lo status di 17 e 18? Grazie!
Allora per questi ? Chi si è occupato del 17 e chi del 18 ?
committati i test mancanti per i vari state.
alcune cose non sono riuscito a testarle per bene, e ho lasciato dei TODO, ho un idea per risolvere il problema ma ci penseremo dopo la FP
il bug 9 non è fixed
Non è un problema, lo risolveremo con calma dopo la FP allora.
Ufo, segno il tuo bug come risolto.
il bug 9 non è fixed
mi è venuta un idea per risolverlo(un metodo isPlayerMoveEnabled per gli state da usare in gridController.reactToInput al posto della serie di condizioni nell if)(il problema è ora nel gemsPairOnControllState e nn lo posso aggiungere fra le condizioni)
oppure aggiungere uno stato intermedio fra gemsPairOnControllState e il crushState.
cmq dopo FP
Bug List:
6 - Quando uno dei due giocatori fa Game Over il gioco deve fermarsi 2 secondi, e resettarsi automaticamente B
10 - Talvolta WarningBox e CounterBox si sovrappongono C
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
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
Ricapitoliamo la situazione: a parte i bug 17 e 18, che potrebbero essere già stati fixati, c'è Cesare sul 6, e 10 e 11 sono liberi, giusto?
Ci sono altri bug non in elenco (ovviamente a parte quelli segnati come D)?
EDIT: Quindi, 17 e 18 siamo sicuri siano morti? Scusate se martello, ma sono bug importanti, e non possiamo sottovalutare la loro eliminazione.
il bug 9 non è fixed
Impossibile...
Come può non essere fixato ?
public void reactToInput(TimerInterface timer)
{
inputReactor.reactToInput(timer);
if(currentState.isCurrentState("StoneFall") || currentState.isCurrentState("GemFall"))
{
grid.setStrongestGravity();
}
}
Ecco il test che lo esercitava (ce n'è uno analogo anche per la caduta delel stone):
public void testDontReactToDownKeyDuringGemFallState()
{
Droppable gem = createGem(DroppableColor.DIAMOND);
insertAndUpdate(gem, 0, 0);
controller.update(timer);
controller.update(timer);
assertEquals(Config.createForTesting().getInteger("StrongestGravityMultiplier") * 0.5, grid.getActualGravity(), 0.01);
loop.getPlayerOneInput().notifyKeyEvent(KeyEvent.DOWN, KeyEvent.PRESSED);
controller.reactToInput(timer);
assertEquals(Config.createForTesting().getInteger("StrongestGravityMultiplier") * 0.5, grid.getActualGravity(), 0.01);
loop.getPlayerOneInput().notifyKeyEvent(KeyEvent.DOWN, KeyEvent.RELEASED);
controller.reactToInput(timer);
assertEquals(Config.createForTesting().getInteger("StrongestGravityMultiplier") * 0.5, grid.getActualGravity(), 0.01);
}
(il problema è ora nel gemsPairOnControllState e nn lo posso aggiungere fra le condizioni)
oppure aggiungere uno stato intermedio fra gemsPairOnControllState e il crushState.
E se da gemsPairOnControlState (attenzione c'è una l in più) passassi a GemsFallState quando una gemma è ferma ?
PS: questo aggiungerebbe un waitNextCrushState fra l'arresto della gemspair ed i crush...sinceramente io ce lo vedrei bene... Anche perchè ora quando cade la gemspair non si vede se si crea una biggem, ma avviene subito il crsh... Jocchan che ne dici ?
Impossibile...
Come può non essere fixato ?
non è fixato tutto :)
quando la gemsPair si divide(siamo in gemsPairOnControllState) quel codice non viene eseguito(giustamente, se no avremmo sempre gravità massima).
E se da gemsPairOnControlState (attenzione c'è una l in più) passassi a GemsFallState quando una gemma è ferma ?
mmmm
buona idea ci provo
quando la gemsPair si divide(siamo in gemsPairOnControllState) quel codice non viene eseguito(giustamente, se no avremmo sempre gravità massima).
Diciamo che in pratica ho fixato altri due bug, ma non quello :)
build rotta su checkstyle
vic, ma i test partono? Puoi sistemare questa cosa per favore?
edit: fissato io, abbiamo viaggiato tutto il giorno senza copertura dei test... grrrrrr
build rotta su checkstyle
vic, ma i test partono? Puoi sistemare questa cosa per favore?
edit: fissato io, abbiamo viaggiato tutto il giorno senza copertura dei test... grrrrrr
No i test non partono. Appena capisco come cavolo far partire Diamonds su Windows li rimetto.
ciao ;)
No i test non partono. Appena capisco come cavolo far partire Diamonds su Windows li rimetto.
ciao ;)
Perche'? Dov'e' il problema? A me partono adesso, ho fatto il commit.
Chi si occupa di fissare questo:
C:\dev\workspace\Diamonds\src\it\diamonds\tests\TestStoneFallState.java:338: Found duplicate of 15 lines in C:\dev\workspace\Diamonds\src\it\diamonds\tests\TestGemFallState.java, starting from line 55
BUILD FAILED
No i test non partono. Appena capisco come cavolo far partire Diamonds su Windows li rimetto.
ciao ;)
il problema su checkstyle e stata colpa mia(commit di 2 minuti fa, che mi ero accorto di aver duplicato una classe di test..)
per quanto riguarda i test a me nn vanno piu su eclipse o meglio dopo 250 e rotti test mi da outOfMemoryError direct buffer memory...
Perche'? Dov'e' il problema? A me partono adesso, ho fatto il commit.
Si i test bastava mettere test in depends="" li avevo tolti appsota perché altrimenti ad ogni prova ci mettevo 5 minuti. :D
Il problema è il file .exe per windows generato da ant dist. Non parte.
ciao ;)
E se da gemsPairOnControlState (attenzione c'è una l in più) passassi a GemsFallState quando almeno una gemma è ferma ?
PS: questo aggiungerebbe un waitNextCrushState fra l'arresto della gemspair ed i crush...sinceramente io ce lo vedrei bene... Anche perchè ora quando cade la gemspair non si vede se si crea una biggem, ma avviene subito il crush... Jocchan che ne dici ?
Faccio una correzione e rilancio a Jocchan...
Perche'? Dov'e' il problema? A me partono adesso, ho fatto il commit.
Chi si occupa di fissare questo:
C:\dev\workspace\Diamonds\src\it\diamonds\tests\TestStoneFallState.java:338: Found duplicate of 15 lines in C:\dev\workspace\Diamonds\src\it\diamonds\tests\TestGemFallState.java, starting from line 55
BUILD FAILED
ora và(l'hai fissata tu)
Faccio una correzione e rilancio a Jocchan...
onestamente..
il giro dei timming fra i vari passaggi(crush, caduta gemme, crush, etc) va rivisto .
io creando gli stati ho pensato piu a far passare i test gia presenti, ma ho notato spesso qualche incongruenza(che mi ha fatto pure dannare..).
cmq ora sto provando a passare a gemmFallState ma come sospettavo qualche test si incazza(e con il junit di eclipse inutilizzabile sono zoppo..)
(in game pero il bug è sparito)
Si i test bastava mettere test in depends="" li avevo tolti appsota perché altrimenti ad ogni prova ci mettevo 5 minuti. :D
Il problema è il file .exe per windows generato da ant dist. Non parte.
ciao ;)
Ok fare le prove, vic, ma lasciare tutto il giorno la build machine senza test e' un po' eccessivo ;)
Qual e' il problema dell'exe sotto Win?
Ok fare le prove, vic, ma lasciare tutto il giorno la build machine senza test e' un po' eccessivo ;)
Speravo di trovare aiuto da voi utenti windows e risolvere subito ma avete preferito prendere in giro bash :p
Qual e' il problema dell'exe sotto Win?
Ah questo devo ancora capirlo. La finestra con il prompt in cui mostra l'errore si apre e si chiude troppo velocemente.
ciao ;)
Era un bersaglio troppo succulento :D
Provo a guardarci.
Sembra che non trovi la main class. Ma questi di Sun sono proprio dei fenomeni a far aprire e chiudere subito la finestra. Ora mi scrivo un launcher in C++.
Ritiro quello che ho detto contro Sun, i fenomeni sono quelli di jstub, ecco l'errore:
Exception in thread "main" java.lang.NoClassDefFoundError: it/diamonds/Game
Non trova la classe Game, secondo me e' sbagliato il classpath nel jar o qualcosa di equivalente.
Apri un cmd.exe e scrivi:
java -Djava.library.path=lib/win32 -jar DiamondCrush.exe
Faccio una correzione e rilancio a Jocchan...
Va benissimo. Puoi farlo tu, per favore?
onestamente..
il giro dei timming fra i vari passaggi(crush, caduta gemme, crush, etc) va rivisto .
io creando gli stati ho pensato piu a far passare i test gia presenti, ma ho notato spesso qualche incongruenza(che mi ha fatto pure dannare..).
cmq ora sto provando a passare a gemmFallState ma come sospettavo qualche test si incazza(e con il junit di eclipse inutilizzabile sono zoppo..)
(in game pero il bug è sparito)
Cosa, nel dettaglio?
Sembra che non trovi la main class. Ma questi di Sun sono proprio dei fenomeni a far aprire e chiudere subito la finestra. Ora mi scrivo un launcher in C++.
Ritiro quello che ho detto contro Sun, i fenomeni sono quelli di jstub, ecco l'errore:
Exception in thread "main" java.lang.NoClassDefFoundError: it/diamonds/Game
Non trova la classe Game, secondo me e' sbagliato il classpath nel jar o qualcosa di equivalente.
Apri un cmd.exe e scrivi:
java -Djava.library.path=lib/win32 -jar DiamondCrush.exe
Chi controlla il classpath?
Questo è un po' strano:
List of available display modes:
1280 x 1024 x 24 @85Hz
Best mode: 0 x 0 x 0 @0Hz
Scheda video ?
6800GT con driver nvidia 87.56
Sembra che non trovi la main class. Ma questi di Sun sono proprio dei fenomeni a far aprire e chiudere subito la finestra. Ora mi scrivo un launcher in C++.
Ritiro quello che ho detto contro Sun, i fenomeni sono quelli di jstub, ecco l'errore:
Exception in thread "main" java.lang.NoClassDefFoundError: it/diamonds/Game
Non trova la classe Game, secondo me e' sbagliato il classpath nel jar o qualcosa di equivalente.
Apri un cmd.exe e scrivi:
java -Djava.library.path=lib/win32 -jar DiamondCrush.exe
Scoperto l'arcano. Ant ha la brutta abitudine di espandere tutti i percorsi relativi in percorsi completi quindi nel file manifest ci andavano a finire robe tipo /home/mirco/workspace/.... che ovviamente su Windows non ci sono.
ciao ;)
Va benissimo. Puoi farlo tu, per favore?
Come dicevo...so un pochino impegnato con gli esami...
Come spesso in questi giorni il .bat non va!! :mad:
Cosa, nel dettaglio?
purtroppo nn mi va il junit di eclipse...(me ne fa vedere una 10 e poi esplode)
ragazzi, i due sistemi di build si sono messi a fare a pugni, perchè ant cancella i file compilati dal build di eclipse..ogni volta che lancio ant, eclipse mi spara una serie di errori dicendo che il progetto è inconsistente...
allora, ho committato il fix per il bug 17, ho corretto alcuni test, il test in TestGameLoop testGameOversAreDisplayingCorrectly l'ho commentato perchè dovrà cmq essere rivisto, se non eliminato, per il bug 6
Scoperto l'arcano. Ant ha la brutta abitudine di espandere tutti i percorsi relativi in percorsi completi quindi nel file manifest ci andavano a finire robe tipo /home/mirco/workspace/.... che ovviamente su Windows non ci sono.
ciao ;)
Ho notato anch'io questo problema. Ma non riesco comunque a risolverlo e a fargli eseguire Game.java. Tu hai risolto?
ragazzi, i due sistemi di build si sono messi a fare a pugni, perchè ant cancella i file compilati dal build di eclipse..ogni volta che lancio ant, eclipse mi spara una serie di errori dicendo che il progetto è inconsistente...
E' normale, fai un clean. Dopo la FP faccio in modo che Ant usi un folder diverso per compilare.
purtroppo nn mi va il junit di eclipse...(me ne fa vedere una 10 e poi esplode)
ERRATA CORRIGE
ho fatto la modifica, e la build è verde, ma ho verificato che ci sono alcune situazioni nn testate, le testo e faccio commit.
ps.
la situazione in it.diamonds.grid è penosa, facciamo due package action e state?
ps.
la situazione in it.diamonds.grid è penosa, facciamo due package action e state?
Per refactoring di questo tipo direi, a meno che non si tratti di modifiche obbligatorie, di rinviare: siamo a 48 ore dalla chiusura della first playable, ed è meglio evitare di avere altri bug.
A proposito, ho segnato il 18 come fixed. Il 17 dovrebbe anche esserlo, ma testiamolo a fondo prima.
Restano il 6 (e ci stava pensando Cesare), il 10 e l'11.
Per refactoring di questo tipo direi, a meno che non si tratti di modifiche obbligatorie, di rinviare: siamo a 48 ore dalla chiusura della first playable, ed è meglio evitare di avere altri bug.
con eclipse è questioni di pochi secondi ;)
cmq np
ps.
la situazione in it.diamonds.grid è penosa, facciamo due package action e state?
Calma...non toccare niente.
In realtà la confusione non è dovuta ai 2 package...ma al fatto che non si capisce chi fa che cosa.
Le responsabilità non sono molto chiare...gli state, le action e Grid/GridController si litigano i compiti9 e il codice è molto confuso anche per quello.
Prossimo ciclo solo 1 storia: refactoring completo degli State e delle Action !!! :O
EDIT: e io quasi quasi non lo farei nenache a task...
...ma a "colloquio pubblico". Ovvero si fa un topic e finchè non si capicse bene quale classe deve fare cosa sì sta lì a discutere. :muro:
Calma...non toccare niente.
In realtà la confusione non è dovuta ai 2 package...ma al fatto che non si capisce chi fa che cosa.
Le responsabilità non sono molto chiare...gli state, le action e Grid/GridController si litigano i compiti9 e il codice è molto confuso anche per quello.
Prossimo ciclo solo 1 storia: refactoring completo degli State e delle Action !!! :O
EDIT: e io quasi quasi non lo farei nenache a task...
...ma a "colloquio pubblico". Ovvero si fa un topic e finchè non si capicse bene quale classe deve fare cosa sì sta lì a discutere. :muro:
io nn ci vedo confusione.
gli state descrivono il comportamento di gridController durante l'update
le action sono azioni sulla griglia(in particolare sulle gemme della griglia)
grid <-->action
gridController<-->state
L'exe va che è una meraviglia.
Fantastico, Vicius ;)
io nn ci vedo confusione.
gli state descrivono il comportamento di gridController durante l'update
le action sono azioni sulla griglia(in particolare sulle gemme della griglia)
grid <-->action
gridController<-->state
Allora gli state vanno messi a posto perchè alcune cose le fanno ancora grid e gridController.
Alcune cose che dovrebbero fare le Action le fanno gridController e mgli state.
Insomma...bisogna riguardare il codice perchè le cose siano veramente come le vedi tu...
grid <-->action
gridController<-->state
...idea che a me piace molto :D :D
Allora gli state vanno messi a posto perchè alcune cose le fanno ancora grid e gridController.
Alcune cose che dovrebbero fare le Action le fanno gridController e mgli state.
Insomma...bisogna riguardare il codice perchè le cose siano veramente come le vedi tu...
grid <-->action
gridController<-->state
...idea che a me piace molto :D :D
Appena passa la FP abbiano una settimana di "pulizia" prima di ricominciare il nuovo Ciclo. Possiamo occuparcene assieme.
allora, ho committato il fix per il bug 17, ho corretto alcuni test, il test in TestGameLoop testGameOversAreDisplayingCorrectly l'ho commentato perchè dovrà cmq essere rivisto, se non eliminato, per il bug 6
Dovrei aver risolto. Prova ora.
ciao ;)
Ho notato anch'io questo problema. Ma non riesco comunque a risolverlo e a fargli eseguire Game.java. Tu hai risolto?
Si ho messo i percorsi relativi hard-coded nel file .xml anche se non mi piace molto come soluzione.
ciao ;)
cdimauro
20-04-2006, 10:59
c'è Cesare sul 6
No, io ero soltanto sul 17, che ha risolto brillantemente cisc (ma grazie anche a Bonfo per le informazioni :))
No, io ero soltanto sul 17, che ha risolto brillantemente cisc (ma grazie anche a Bonfo per le informazioni :))
Avevo capito male io allora ;)
Bene, chi si occupa del 6? Consideriamo il 6 come nostra priorità attuale.
cdimauro
20-04-2006, 11:01
E' normale, fai un clean. Dopo la FP faccio in modo che Ant usi un folder diverso per compilare.
Veramente prima non succedeva: io eseguivo tranquillamente Ant, e poi ritornavo a lavorare con Eclipse senza alcuna ripercussione. C'è qualcosa che è cambiato e che fa sclerare Eclipse.
cdimauro
20-04-2006, 11:05
Avevo capito male io allora ;)
Bene, chi si occupa del 6? Consideriamo il 6 come nostra priorità attuale.
Oggi ho poco tempo, ma vedo quello che posso fare. Gli do un'occhiata.
Oggi ho poco tempo, ma vedo quello che posso fare. Gli do un'occhiata.
Grazie :)
Si ho messo i percorsi relativi hard-coded nel file .xml anche se non mi piace molto come soluzione.
ciao ;)
Per ora va benissimo cosi', grazie :D
Dopo la FP pensiamo ad una soluzione piu' elegante.
Veramente prima non succedeva: io eseguivo tranquillamente Ant, e poi ritornavo a lavorare con Eclipse senza alcuna ripercussione. C'è qualcosa che è cambiato e che fa sclerare Eclipse.
A me e' sempre successo invece :|
Anche qui, dopo la FP vedo di metterci una pezza.
Build rotta.
Test: testCrushAndDroppedGemCantMove
Class: it.diamonds.tests.TestCrushState
Type: junit.framework.AssertionFailedError
Message: grid chain not closed expected:<100> but was:<160>
junit.framework.AssertionFailedError: grid chain not closed expected:<100> but was:<160> at it.diamonds.tests.TestCrushState.testCrushAndDroppedGemCantMove(TestCrushState.java:72)
Avevo capito male io allora ;)
Bene, chi si occupa del 6? Consideriamo il 6 come nostra priorità attuale.
mi ci metto anche io.
ho solo il problema che sabato parto, per cui ho solo stasera..
Test: testCrushAndDroppedGemCantMove
Class: it.diamonds.tests.TestCrushState
Type: junit.framework.AssertionFailedError
Message: grid chain not closed expected:<100> but was:<160>
junit.framework.AssertionFailedError: grid chain not closed expected:<100> but was:<160> at it.diamonds.tests.TestCrushState.testCrushAndDroppedGemCantMove(TestCrushState.java:72)
fallisce a random(l'ho segnalato sul test quando me ne sono accorto, ma non ho fatto in tempo a capire perche)
A me e' sempre successo invece :|
Anche qui, dopo la FP vedo di metterci una pezza.
Dovrebbe essere gia risolto. Ora clean non cancella più bin/it. Quindi attenti a non committare quei file per sbaglio.
ciao ;)
fallisce a random(l'ho segnalato sul test quando me ne sono accorto, ma non ho fatto in tempo a capire perche)
Ok, puoi togliere il test e cercare di capire perche' fallisce a random?
Ok, puoi togliere il test e cercare di capire perche' fallisce a random?
non ho accesso a svn fino a stasera dopo le 20
non ho accesso a svn fino a stasera dopo le 20
Hmmm problema :)
Vic, puoi farlo tu?
Hmmm problema :)
Vic, puoi farlo tu?
Fatto.
ciao ;)
cdimauro
20-04-2006, 14:23
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.
Pork... ma allora non era un bug. :doh:
Mancano solo due piccoli bug e abbiamo finito con un giorno di anticipo! :D
Eccoli qui:
10 - Talvolta WarningBox e CounterBox si sovrappongono C
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
Chi se ne vuole occupare?
Venerdi' alle 22 CEST prendo il tag della FirstPlayable e la chiudiamo.
cdimauro
20-04-2006, 15:37
Per quanto riguarda il bug/task 6, definire il "reset del gioco" equivale a introdurre numerosi controlli.
Per il momento, per realizzare quanto chiesto, pensavo a due test abbastanza semplici e che testano il gameover del primo playfield/gamecontroller e quello del secondo, rispettivamente.
Il codice dovrebbe testare che, dopo aver appurato lo stato di gameover, passati 2 secondi ci siano due nuovi playfield e relativi input, e un nuovo layermanager.
Nell'implementazione questo significa spostare parte del codice del costruttore di GameLoop in un metodo privato reset, che verrà richiamato alla fine dei 2 secondi di attesa, e che si occupa semplicemente di ricreare i playfield, i loro input e il layermanager. Questo dovrebbe bastare per "resettare" il gioco.
Nel contempo, nell'arco di tempo dei 2 secondi, non verrebbe eseguito l'update e il reactToInput dei playfield, in modo da far rimanere tutto così com'è (in sostanza ci sarebbe soltanto il rendering della grafica).
Oltre al piccolo refactoring di GameLoop, pensavo anche di estendere TimerInterface, inglobando il metodo advance di MockTimer (quindi per questo non cambierebbe nulla), e implementandolo in Timer come chiamata a Thread.Sleep. In pratica verrebbe spostato il codice del metodo sleepOneMillisecond in questo "nuovo" metodo, e in GameLoop la chiamata a sleepOneMillisecond verrebbe rimpiazzata da quest'ultimo.
In questo modo la scrittura del test di reset del gioco si semplificherebbe, perché la chiamata ad advance (che sostituisce sleepOneMillisecond) verrebbe realizzata in fase di test da una chiamata a MockTimer.advance anziché a Thread.Sleep, e questo, oltre a portare vantaggi nell'esecuzione dei test (non si aspetterebbe alcunché), permetterebbe di controllare facilmente che siano passati i 2 secondi previsti (creando un metodo pubblico getTimer per GameLoop).
Questo perché altrimenti il timer creato in GameLoop.creatForTesting, che è un MockTimer, rimarrebbe "fermo" al valore iniziale.
Che ne pensate?
Per il 6 non è meglio definirlo all'esterno di loop ? Infatti questa sarebbe una situazione temporanea, quindi tanto vale definirla in Game... Basta chiamare l'inzializzazione della grafica da Game...
inizializzazione grafica
while(1)
{
creo il game loop
loop del gioco
se è stato premuto ESC esco dal loop
attendo 2 secondi
}
deinizializzo la grafica
L'unica cosa da mettere in gameLoop sarebbe il controllo della situazione di GameOver...
Per il 6 non è meglio definirlo all'esterno di loop ? Infatti questa sarebbe una situazione temporanea, quindi tanto vale definirla in Game... Basta chiamare l'inzializzazione della grafica da Game...
inizializzazione grafica
while(1)
{
creo il game loop
loop del gioco
se è stato premuto ESC esco dal loop
attendo 2 secondi
}
deinizializzo la grafica
L'unica cosa da mettere in gameLoop sarebbe il controllo della situazione di GameOver...
Come soluzione temporanea non e' male, e' semplice. La soluzione di Cesare pero' e' piu' future-proof, quindi... YAGNI (per ora).
Cesare, andiamo per l'hack?
Mancano solo due piccoli bug e abbiamo finito con un giorno di anticipo! :D
Eccoli qui:
10 - Talvolta WarningBox e CounterBox si sovrappongono C
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
Chi se ne vuole occupare?
Venerdi' alle 22 CEST prendo il tag della FirstPlayable e la chiudiamo.
vedo che posso fare con l'11, e poi chissà, che sparisce pure il 10:D:D
cdimauro
20-04-2006, 17:05
Per il 6 non è meglio definirlo all'esterno di loop ? Infatti questa sarebbe una situazione temporanea, quindi tanto vale definirla in Game... Basta chiamare l'inzializzazione della grafica da Game...
inizializzazione grafica
while(1)
{
creo il game loop
loop del gioco
se è stato premuto ESC esco dal loop
attendo 2 secondi
}
deinizializzo la grafica
L'unica cosa da mettere in gameLoop sarebbe il controllo della situazione di GameOver...
Come soluzione temporanea non e' male, e' semplice. La soluzione di Cesare pero' e' piu' future-proof, quindi... YAGNI (per ora).
Cesare, andiamo per l'hack?
Il problema è che non c'è soltanto l'inizializzazione della grafica: dentro GameLoop sono creati e definiti diversi metodi per accedere (settare e prelevare) Engine, Audio, Input, Timer, LayerManager, PlayField, ecc. ecc. che poi vengono anche passati agli oggetti che hanno bisogno di qualcuno di essi (quindi bisognerebbe propagarli).
Insomma, per spostare la parte di inizializzazione da GameLoop a Game ci sarebbe un po' di lavoro da fare.
Personalmente in questo momento vedo la soluzione che ho descritto prima come un hack più semplice da realizzare.
La soluzione di Riccardo è comunque quella migliore nonché quella a cui, a mio avviso, si dovrà necessariamente arrivare quando si effettuerà il massiccio refactoring, dopo la FP.
Infatti GameLoop dovrà, appunto, badare soltanto al loop del gioco e basta: la fase di inizializzione di Engine, Audio, e orpelli varii la vedo legata a Game (che in questo momento fa veramente poco: è GameLoop la "primadonna"), che provvederà a propagare l'istanza di Environment creata (che conterrà tutte le altre) a GameLoop & così via "scendendo".
Questa, chiaramente, è soltanto la mia visione delle cose.
Se voi vedete meglio la seconda soluzione, per me non c'è problema: implementare l'una o l'altra, visto che ancora non ho messo mano al sorgente, è la stessa cosa.
Non tutta l'inizializzazione...solo quella del Display... Poi va passato il display inizializzato all'inzializzazione dell'engine...
cdimauro
20-04-2006, 17:49
Mumble Mumble. A conti fatto toglierei di mezzo GameLoop.create e sposterei tutto il suo codice in Game: almeno Game.setUpGame farebbe qualcosina di più che richiamare GameLoop.create. :p
Sposterei anche parte del codice da GameLoop.quit a Game (.quit), per ovvi motivi.
Stessa sorte al codice "for testing".
Pure audio.playMusic lo sposterei da dal costruttore di GameLoop alla fase di inizializzazione di Game: in questo modo la musica non verrebbe bruscamente interrotta per poi ripartire dall'inizio, ma continuerebbe tranquillamente a essere riprodotta.
A questo punto dovrei ripensare al codice del test per questo task...
OK, ci penso sù e domani mi metto all'opera, ma penso di seguire questa via che hai suggerito: così anticipiamo un po' di refactoring. :)
Però il refactoring su TimerInterface e Timer lo farei comunque: trovo troppo brutto il codice così.
Mumble Mumble. A conti fatto toglierei di mezzo GameLoop.create e sposterei tutto il suo codice in Game: almeno Game.setUpGame farebbe qualcosina di più che richiamare GameLoop.create. :p
Sposterei anche parte del codice da GameLoop.quit a Game (.quit), per ovvi motivi.
Stessa sorte al codice "for testing".
Pure audio.playMusic lo sposterei da dal costruttore di GameLoop alla fase di inizializzazione di Game: in questo modo la musica non verrebbe bruscamente interrotta per poi ripartire dall'inizio, ma continuerebbe tranquillamente a essere riprodotta.
A questo punto dovrei ripensare al codice del test per questo task...
OK, ci penso sù e domani mi metto all'opera, ma penso di seguire questa via che hai suggerito: così anticipiamo un po' di refactoring. :)
Però il refactoring su TimerInterface e Timer lo farei comunque: trovo troppo brutto il codice così.
Allora vai avanti per questa strada. Per ora lascia solo stare Timer. Cerchiamo di mantenere i cambiamenti al minimo necessario, siamo a meno di due giorni dal Lock. Meno tocchiamo, meglio e'.
-ho risolto il bug random(ma da quel che ho capito ci ha gia pensato vic)
-ho risolto un bug che nn faceva eseguire tutti i test a eclipse(l'oggsound nn liberava la memoria)
-ho sul portatile diamonds che fa quello che dice cesare(con un test, appena accendo il portatile lo posto). Penso che l'idea sia identica perche ha spiegato gli stessi problemi che ho incontrato io
il test testa che vengano creati 2 nuovi playField, e un nuovo layerManager(ci sarebbe anche il backGround ma nn so come testarlo)
5 minuti e posto tutto. poi vedamo cosa commitare
ps.nella mia implementazione la musica continua a suonare ininterrotamente e le gemme della grigli senza gameOver sono bloccate.
allora, ecco il test (finalmente) per il bug 11:
public void testWarningBoxHiddenAfterStonesFall()
{
int updateRate = config.getInteger("UpdateRate");
playField1.addIncomingStones(1);
makeAllGemsFall();
for (int i=0; i<41; i++)
{
timer.setTime(timer.getTime()+updateRate+1);
playField1.update();
}
assertFalse("WarningBox must be shown ", warningBox.isHidden());
timer.setTime(timer.getTime()+updateRate+1);
playField1.update();
assertTrue("WarningBox must be hidden", warningBox.isHidden());
}
a breve il commit con il fix (basta cambiare una riga in playField:D)
-ho risolto il bug random(ma da quel che ho capito ci ha gia pensato vic)
Io l'ho solo commentato.
ciao ;)
per l'audio..
private OggPlayer musicPlayer = new OggPlayer();
l'oogplayer viene creato a ogni istanza di Audio, mentre nn và creato per il testing.
E bastato mettere la creazione nel costruttore.
Questo lo committo subito.
Poi...
Il test per il restartGameOver
public void setUp()
{
timer = new MockTimer();
config = Config.createForTesting();
loop = GameLoop.createForTesting(timer);
field1 = loop.getPlayFieldOne();
field2 = loop.getPlayFieldTwo();
controller = field1.getGridController();
grid = controller.getGrid();
this.newGemDelay = config.getInteger("NewGemDelay");
this.updateRate = config.getInteger("UpdateRate");
}
public void testPassToGameOverState()
{
LayerManager oldLayerManager = loop.getLayerManager();
makeAllGemsFall();
for (int row = 11; row >= 0; row--)
{
insertAndUpdate(createGem(DIAMOND), row, 4);
}
timer.advance(newGemDelay);
loop.doOneStep();
//verifico che il restart nn sia ancora stato fatto
assertEquals(oldLayerManager, loop.getLayerManager());
assertEquals(field1, loop.getPlayFieldOne());
assertEquals( field2, loop.getPlayFieldTwo());
timer.advance(1999);
loop.doOneStep();
//verifico che il restart nn sia ancora stato fatto
assertEquals(oldLayerManager, loop.getLayerManager());
assertEquals(field1, loop.getPlayFieldOne());
assertEquals( field2, loop.getPlayFieldTwo());
timer.advance(1);
loop.doOneStep();
assertNotSame("The layer must be different from old", oldLayerManager, loop.getLayerManager());
//TODO manca test che è stato settato il background(come si fa?)
assertNotSame("The field1 must be different from old", field1, loop.getPlayFieldOne());
assertNotSame("The field2 must be different from old", field2, loop.getPlayFieldTwo());
}
come detto nell'altro post nn so come testare che sia stato ricreato il backGround. Probabilmente il test è migliorabile.
questo il codice messo in gameLoop
private long haltOnGameOver;
private long waitForRestart;
private boolean isGameOver;
...
private GameLoop(Config config, EngineInterface engine, Audio audio, KeyboardInterface keyboard, TimerInterface timer)
{
setConfig(config);
// setBackground();
this.engine = engine;
this.timer = timer;
this.audio = audio;
this.keyboard = keyboard;
this.inputPlayerOne = new Input(keyboard, timer);
this.inputPlayerTwo = new Input(keyboard, timer);
inputPlayerOne.setKeyMappings(KeyMappings.createForPlayerOne());
inputPlayerTwo.setKeyMappings(KeyMappings.createForPlayerTwo());
keyMappings = KeyMappings.createForGameLoop();
keyboard.setListener(this);
initPlayField(timer);
frameRate = config.getInteger("FrameRate");
audio.playMusic();
waitForRestart = 2000;
isGameOver = false;
}
private void initPlayField(TimerInterface timer)
{
long timeStamp = timer.getTime();
long randomSeed = System.nanoTime();
createPlayFieldOne(timeStamp, randomSeed);
createPlayFieldTwo(timeStamp, randomSeed);
attachFields();
}
...
public static GameLoop create()
{
Audio audio = Audio.create();
Config config = new Config(
audio,
"data" + java.io.File.separator + "GameConfig");
EngineInterface engine = Engine.create(config.getInteger("width"), config.getInteger("height"), "Diamond Crush");
KeyboardInterface keyboard = new Keyboard();
TimerInterface timer = new Timer();
GameLoop gameLoop = new GameLoop(config, engine, audio, keyboard, timer);
gameLoop.setBackground();
return gameLoop;
}
public static GameLoop createForTesting()
{
return createForTesting(new MockTimer());
}
public static GameLoop createForTesting(MockTimer timer)
{
Config config = Config.createForTesting();
EngineInterface engine = Engine.createEngineForTesting(config.getInteger("width"), config.getInteger("height"));
Audio audio = Audio.createForTesting();
KeyboardInterface keyboard = new MockKeyboard();
return new GameLoop(config, engine, audio, keyboard, timer);
}
...
private void updateFields()
{
if (!isGameOver)
{
playFieldOne.update();
playFieldTwo.update();
checkAndShowGameOverMessage(playFieldOne);
checkAndShowGameOverMessage(playFieldTwo);
}
else
{
if(haltOnGameOver + waitForRestart <= timer.getTime())
{
restart();
}
}
}
private void restart()
{
isGameOver = false;
layerManager = new LayerManager();
setBackground();
initPlayField(timer);
}
private void checkAndShowGameOverMessage(PlayField field)
{
if (!field.getGridController().isGameOver())
{
return;
}
field.showGameOverMessage();
initRestartGame();
}
private void initRestartGame()
{
haltOnGameOver = timer.getTime();
isGameOver = true;
}
note:
ho creato un createForTesting(Timer) per avere il timer del gameLoop nel test(l'alternativa era un getter).
Non ho ancora messo la variabile nel config ma è hardCoded(modifica da 1 minuto circa)
ps. nn fate caso a come ho scritto hardCoded...
pps. fatemi sapere che fare con questo codice
allora, nell'applicare il fix, non passa più il seguente test:
public void testWarningBoxIsNotHideBeforePairGemsInsert()
{
playField.getWarningBox().show();
playField.getGridController().insertNewGemsPair();
update(playField);
playField.getWarningBox().show();
update(playField);
assertFalse("The WarningBox must be shown",
playField.getWarningBox().isHidden());
}
ora, prima si controllava se far sparire il warningBox in base all'inserimento di una nuova gemsPair, adesso ho modificato in modo che si faccia sparire il warningBox quando non c'è più nessuna incomingStone, per il momento commento il test per un'eventuale valutazione successiva....
ok, committato il fix al bug 11
Io l'ho solo commentato.
ciao ;)
ho visto solo adesso, e ho gia fatto update :|
fortuna cè la local history di eclipse :D
ps.
fatto commit, ho forzato la gemme della gemsPair a diamond
Ho parlato con TheBol e oggi, che era senza connessione, ha lavorato al task/bug sul game over e conseguente reset del gioco, senza sapere che ci stava già lavorando Cesare.
Dato però che domani TheBol non ci sarà fino alla serata, e che alle 22 chiudiamo la FP, gli ho dato il via libera per il commit.
Avrei preferito parlarne con gli altri, e soprattutto con Cesare (vedersi "fregare" quello su cui si stava lavorando non è carino... per niente...), ma visto che il tempo stringeva e andava presa una decisione subito, mi è sembrata la cosa migliore da fare.
Quindi, chiedo scusa anche io a Cesare per questa incomprensione e, in caso, non ci saranno problemi a revertare e inserire la sua. Committando ora, intanto, abbiamo già una versione del codice che ci serve, ed a 24 ore dalla FP è senza dubbio una cosa positiva, ma in ogni caso la decisione finale vedremo di prenderla con calma domani mattina.
Una cosa: quando avviene un game over e si ferma per 2 secondi, si deve fermare solo in caduta la pair di chi ha vinto o anche nei movimenti laterali (ora si può muovere) ?
Una cosa: quando avviene un game over e si ferma per 2 secondi, si deve fermare solo in caduta la pair di chi ha vinto o anche nei movimenti laterali (ora si può muovere) ?
mmm nn avevo notato la cosa...
cmq è abbastanza semplice inibire tutti gli input(compreso il tasto esc).
inibire solo i tasti di movimento invece è un po piu incasinato..
mmm nn avevo notato la cosa...
cmq è abbastanza semplice inibire tutti gli input(compreso il tasto esc).
inibire solo i tasti di movimento invece è un po piu incasinato..
ho risolto, ma nn riesco a scrivere il test..
ho risolto anche col test, ho committato
Ho parlato con TheBol e oggi, che era senza connessione, ha lavorato al task/bug sul game over e conseguente reset del gioco, senza sapere che ci stava già lavorando Cesare.
Dato però che domani TheBol non ci sarà fino alla serata, e che alle 22 chiudiamo la FP, gli ho dato il via libera per il commit.
Avrei preferito parlarne con gli altri, e soprattutto con Cesare (vedersi "fregare" quello su cui si stava lavorando non è carino... per niente...), ma visto che il tempo stringeva e andava presa una decisione subito, mi è sembrata la cosa migliore da fare.
Quindi, chiedo scusa anche io a Cesare per questa incomprensione e, in caso, non ci saranno problemi a revertare e inserire la sua. Committando ora, intanto, abbiamo già una versione del codice che ci serve, ed a 24 ore dalla FP è senza dubbio una cosa positiva, ma in ogni caso la decisione finale vedremo di prenderla con calma domani mattina.
Aspettiamo fino a domani. Io consiglio a thebol e Cesare di fare due chiacchiere su MSN e vedere che cosa della soluzione di Cesare si puo' integrare per semplificare la soluzione al bug. E' meglio avere due soluzioni e scegliere la piu' semplice o una combinazione piu' semplice. Se thebol non e' disponibile, Cesare conoscendo gia' il task puo' guardare la soluzione nel repository e semplificarla aggiornarla.
Il guaio è che TheBol domani non ci sarà fino alla sera, altrimenti ovviamente non gli avrei detto di committare (il problema non si sarebbe posto, avremmo aspettato e discusso domani mattina) :)
Aspettiamo fino a domani. Io consiglio a thebol e Cesare di fare due chiacchiere su MSN e vedere che cosa della soluzione di Cesare si puo' integrare per semplificare la soluzione al bug. E' meglio avere due soluzioni e scegliere la piu' semplice o una combinazione piu' semplice. Se thebol non e' disponibile, Cesare conoscendo gia' il task puo' guardare la soluzione nel repository e semplificarla aggiornarla.
roger(dovrei poter postare sul forum fino alle 13 poi silenzio fino alle sera :( )
cdimauro
21-04-2006, 08:34
Ho parlato con TheBol e oggi, che era senza connessione, ha lavorato al task/bug sul game over e conseguente reset del gioco, senza sapere che ci stava già lavorando Cesare.
Dato però che domani TheBol non ci sarà fino alla serata, e che alle 22 chiudiamo la FP, gli ho dato il via libera per il commit.
Avrei preferito parlarne con gli altri, e soprattutto con Cesare (vedersi "fregare" quello su cui si stava lavorando non è carino... per niente...), ma visto che il tempo stringeva e andava presa una decisione subito, mi è sembrata la cosa migliore da fare.
Quindi, chiedo scusa anche io a Cesare per questa incomprensione e, in caso, non ci saranno problemi a revertare e inserire la sua. Committando ora, intanto, abbiamo già una versione del codice che ci serve, ed a 24 ore dalla FP è senza dubbio una cosa positiva, ma in ogni caso la decisione finale vedremo di prenderla con calma domani mattina.
Non c'è alcun motivo per scusarti: l'obiettivo è quello di riuscire a risolvere i problemi che abbiamo, a prescindere da chi lo faccia e anche se questo dovesse significare buttare via lavoro e/o codice.
Siamo un team, no? Fa parte del mestiere. ;)
ulteriore update:
ora flusho gli input prima di ricominciare.
prima se uno teneva spindo left durante la pausa, ci si ritrovava alla partenza con la gemspair spostata a sx :(
naturalmente cè anche il test :)
cdimauro
21-04-2006, 08:36
roger(dovrei poter postare sul forum fino alle 13 poi silenzio fino alle sera :( )
Io sono già disponibile su MSN (o ICQ). :)
Io sono già disponibile su MSN (o ICQ). :)
l'unico mio strumento di uscita è il forum(siamo dietro a un firewall, sono abilitati quasi solo siti non tecnologici/programmazione, e uso l'account di un altro proxato :( )...
quindi qua, o al max pvt
cdimauro
21-04-2006, 09:27
OK, non c'è problema. Usiamo pure il forum, perché così anche altri possono intervenire.
Vorrei fare il punto della situazione. Ho visto il codice e il test che hai realizzato. La build è verde. Cos'è rimasto da fare?
OK, non c'è problema. Usiamo pure il forum, perché così anche altri possono intervenire.
Vorrei fare il punto della situazione. Ho visto il codice e il test che hai realizzato. La build è verde. Cos'è rimasto da fare?
imho nulla su questa cosa.
L'unico problema è che dopo 20/25 minuti di gioco il gioco crasha quando va a prelevare una texture by file. E' un problema pregresso(mi era saltato fuori anche quando avevo provato a far girare 10000 volte un test, sembra che ci sia un limite di riferimenti che puoi avere a un file o qualcosa del genere).
Per farlo saltare fuori in fretta, prova a fare una suite di test, che aggiunga un 10000 volte un test(usa il wizard di eclipse) e poi falla girare con junit di eclipse.
Dopo un po ti darà errore..
cdimauro
21-04-2006, 09:49
Ottimo. Allora il bug / task 6 è ufficialmente risolto. :)
Questo problema che segnali è, invece, un altro bug (abbastanza grave), che dovremmo aggiungere alla lista.
Do un'occhiata al codice di gestione di Texture et similia.
imho nulla su questa cosa.
L'unico problema è che dopo 20/25 minuti di gioco il gioco crasha quando va a prelevare una texture by file. E' un problema pregresso(mi era saltato fuori anche quando avevo provato a far girare 10000 volte un test, sembra che ci sia un limite di riferimenti che puoi avere a un file o qualcosa del genere).
Per farlo saltare fuori in fretta, prova a fare una suite di test, che aggiunga un 10000 volte un test(usa il wizard di eclipse) e poi falla girare con junit di eclipse.
Dopo un po ti darà errore..
Questa e' una bruttissima cosa, va assolutamente risolta oggi, e' un bug A. Chi vuole occuparsene?
Edit: me ne occupo io stasera.
cdimauro
21-04-2006, 10:24
Ce ne occupiamo oggi (penso in mattinata). :D
Chiamatemi su MSN se serve una mano :)
Questa e' una bruttissima cosa, va assolutamente risolta oggi, e' un bug A. Chi vuole occuparsene?
Edit: me ne occupo io stasera.
potrebbe essere un problema della jvm
vi posto il test
import junit.framework.Test;
import junit.framework.TestSuite;
public class AllTest
{
public static Test suite()
{
TestSuite suite = new TestSuite("Test lungo lungo");
for (int i=0; i<50; i++)
{
suite.addTestSuite(TestCrushState.class);//mettete il test che volete
}
return suite;
}
}
ho copiato a mano dal portatile, magari cè qualche errore.
Da far girare con junit (ALT + SHIFT + X; T)
ps. ho notato adesso, mi fa crasciare eclipse :|
pps ho modificato il codice mettendo 400. A questo numero si verifica l'errore della texture ma nn va in out of memory
ppps.a me sembra un errore di win(come se dopo che un file a troppi riferimenti non da piu l'accesso allo stesso). Cmq sarebbe meglio che i riferimenti venissero liberati(o che in modalità test non vengano caricati)
pps.ho ririmodificato il codice mettendo 50(400/8, il numero dei test per quella classe..)
Credo che basti far pooling delle texture come per i suoni. Ce ne occupiamo io e Cesare oggi.
Credo che basti far pooling delle texture come per i suoni. Ce ne occupiamo io e Cesare oggi.
ancora meglio =)
Mi è stato detto che le build di 2-3 giorni fa davano problemi con Mac e Linux.
Sono sicuro fosse per colpa delle librerie ogg, prima del fix a build.xml, ma per eliminare ogni dubbio, chi usa Mac o Linux potrebbe dire se ha problemi con le build?
Mi è stato detto che le build di 2-3 giorni fa davano problemi con Mac e Linux.
Sono sicuro fosse per colpa delle librerie ogg, prima del fix a build.xml, ma per eliminare ogni dubbio, chi usa Mac o Linux potrebbe dire se ha problemi con le build?
Su linux dava problemi subito dopo il primo commit della musica che usava javasound. Ora con ogg e openal è tutto ok.
ciao ;)
Ottimo, grazie Vic. Ho chiesto a Damacorp di riprovare su Mac, ma penso che il problema fosse proprio per la questione degli ogg.
P.S.: La build è rotta.
Abbiamo questo test che fallisce a random:
est: testPassToGameOverState
Class: it.diamonds.tests.TestWaitStateBeforeNewGemsPair
Type: junit.framework.AssertionFailedError
Message: not correct state returned
junit.framework.AssertionFailedError: not correct state returned at it.diamonds.tests.TestWaitStateBeforeNewGemsPair
Chi gli puo' dare un'occhiata?
Abbiamo questo test che fallisce a random:
est: testPassToGameOverState
Class: it.diamonds.tests.TestWaitStateBeforeNewGemsPair
Type: junit.framework.AssertionFailedError
Message: not correct state returned
junit.framework.AssertionFailedError: not correct state returned at it.diamonds.tests.TestWaitStateBeforeNewGemsPair
Chi gli puo' dare un'occhiata?
10 a 1 che è lo stesso problema di crushState....
basta inseririe nel setUp di quella classe
setDiamondsGemsPair(grid, controller.getGemsPair());
è un metodo inserito da me in gridTestCase che forza la gemsPair iniziale a 2 Diamonds(il fail si verifca se viene genereta una gemma e la sua chest, oppure una flash)
io nn posso fare la modifica...
ps.confermo sia la diagnosi che la cura.
Per provare usare il test postato prima da me :)
pps.si potrebbe fare un test(da inserire in maniera che sia eseguito solo dalla build machine, o solo su richiesta) che testa ogni classe un 200/300 volte per sgamare questo tipo di errori. Se nn sbaglio ho un pdf che spiegava come fare con junit, la prox settimana ci dò un occhiata.
A Damacorp su Mac il gioco non parte.
Ci sono altri utenti Mac che possono testare la build?
EDIT: Ecco la sua exception:
Display Adapter: null
List of available display modes:
800 x 500 x 16 @0Hz
640 x 480 x 32 @0Hz
640 x 480 x 16 @0Hz
1024 x 640 x 16 @0Hz
1152 x 720 x 32 @0Hz
800 x 600 x 16 @0Hz
1440 x 900 x 16 @0Hz
1440 x 900 x 32 @0Hz
1024 x 768 x 32 @0Hz
1024 x 640 x 32 @0Hz
1152 x 720 x 16 @0Hz
800 x 500 x 32 @0Hz
800 x 600 x 32 @0Hz
1024 x 768 x 16 @0Hz
Best mode: 800 x 600 x 32 @0Hz
Exception in thread "main" java.lang.ExceptionInInitializerError
at it.diamonds.GameLoop.createPlayFieldOne(Unknown Source)
at it.diamonds.GameLoop.initPlayField(Unknown Source)
at it.diamonds.GameLoop.<init>(Unknown Source)
at it.diamonds.GameLoop.create(Unknown Source)
at it.diamonds.Game.setUpGame(Unknown Source)
at it.diamonds.Game.create(Unknown Source)
at it.diamonds.Game.main(Unknown Source)
Caused by: it.diamonds.engine.video.TextureException: Texture loading error due to org.lwjgl.LWJGLException: Could not load devil library.
at it.diamonds.engine.video.Texture.loadTextureFromFile(Unknown Source)
at it.diamonds.engine.video.Texture.<init>(Unknown Source)
at it.diamonds.WarningBox.<init>(Unknown Source)
at it.diamonds.WarningBox.createForPlayerOne(Unknown Source)
at it.diamonds.PlayFieldDescriptor.<clinit>(Unknown Source)
... 7 more
A Damacorp su Mac il gioco non parte.
Ci sono altri utenti Mac che possono testare la build?
EDIT: Ecco la sua exception:
Display Adapter: null
List of available display modes:
800 x 500 x 16 @0Hz
640 x 480 x 32 @0Hz
640 x 480 x 16 @0Hz
1024 x 640 x 16 @0Hz
1152 x 720 x 32 @0Hz
800 x 600 x 16 @0Hz
1440 x 900 x 16 @0Hz
1440 x 900 x 32 @0Hz
1024 x 768 x 32 @0Hz
1024 x 640 x 32 @0Hz
1152 x 720 x 16 @0Hz
800 x 500 x 32 @0Hz
800 x 600 x 32 @0Hz
1024 x 768 x 16 @0Hz
Best mode: 800 x 600 x 32 @0Hz
Exception in thread "main" java.lang.ExceptionInInitializerError
at it.diamonds.GameLoop.createPlayFieldOne(Unknown Source)
at it.diamonds.GameLoop.initPlayField(Unknown Source)
at it.diamonds.GameLoop.<init>(Unknown Source)
at it.diamonds.GameLoop.create(Unknown Source)
at it.diamonds.Game.setUpGame(Unknown Source)
at it.diamonds.Game.create(Unknown Source)
at it.diamonds.Game.main(Unknown Source)
Caused by: it.diamonds.engine.video.TextureException: Texture loading error due to org.lwjgl.LWJGLException: Could not load devil library.
at it.diamonds.engine.video.Texture.loadTextureFromFile(Unknown Source)
at it.diamonds.engine.video.Texture.<init>(Unknown Source)
at it.diamonds.WarningBox.<init>(Unknown Source)
at it.diamonds.WarningBox.createForPlayerOne(Unknown Source)
at it.diamonds.PlayFieldDescriptor.<clinit>(Unknown Source)
... 7 more
è lo stesso errore che c'ho su linux amd64, relativo alle librerie devil
10 a 1 che è lo stesso problema di crushState....
basta inseririe nel setUp di quella classe
setDiamondsGemsPair(grid, controller.getGemsPair());
è un metodo inserito da me in gridTestCase che forza la gemsPair iniziale a 2 Diamonds(il fail si verifca se viene genereta una gemma e la sua chest, oppure una flash)
io nn posso fare la modifica...
ps.confermo sia la diagnosi che la cura.
Per provare usare il test postato prima da me :)
pps.si potrebbe fare un test(da inserire in maniera che sia eseguito solo dalla build machine, o solo su richiesta) che testa ogni classe un 200/300 volte per sgamare questo tipo di errori. Se nn sbaglio ho un pdf che spiegava come fare con junit, la prox settimana ci dò un occhiata.
Ho risolto in altra maniera.. comunque il TestCase sarà da refattorizzare :)
è lo stesso errore che c'ho su linux amd64, relativo alle librerie devil
Problema senza soluzione quindi?
A Damacorp su Mac il gioco non parte.
Ci sono altri utenti Mac che possono testare la build?
EDIT: Ecco la sua exception:
Display Adapter: null
List of available display modes:
800 x 500 x 16 @0Hz
640 x 480 x 32 @0Hz
640 x 480 x 16 @0Hz
1024 x 640 x 16 @0Hz
1152 x 720 x 32 @0Hz
800 x 600 x 16 @0Hz
1440 x 900 x 16 @0Hz
1440 x 900 x 32 @0Hz
1024 x 768 x 32 @0Hz
1024 x 640 x 32 @0Hz
1152 x 720 x 16 @0Hz
800 x 500 x 32 @0Hz
800 x 600 x 32 @0Hz
1024 x 768 x 16 @0Hz
Best mode: 800 x 600 x 32 @0Hz
Exception in thread "main" java.lang.ExceptionInInitializerError
at it.diamonds.GameLoop.createPlayFieldOne(Unknown Source)
at it.diamonds.GameLoop.initPlayField(Unknown Source)
at it.diamonds.GameLoop.<init>(Unknown Source)
at it.diamonds.GameLoop.create(Unknown Source)
at it.diamonds.Game.setUpGame(Unknown Source)
at it.diamonds.Game.create(Unknown Source)
at it.diamonds.Game.main(Unknown Source)
Caused by: it.diamonds.engine.video.TextureException: Texture loading error due to org.lwjgl.LWJGLException: Could not load devil library.
at it.diamonds.engine.video.Texture.loadTextureFromFile(Unknown Source)
at it.diamonds.engine.video.Texture.<init>(Unknown Source)
at it.diamonds.WarningBox.<init>(Unknown Source)
at it.diamonds.WarningBox.createForPlayerOne(Unknown Source)
at it.diamonds.PlayFieldDescriptor.<clinit>(Unknown Source)
... 7 more
Sembra un problema di linking come succede qui su linux. Dovrebbe dare da shell ldd(o quello che hanno su osx) lib/macos/liblwjgl-devil.jnilib e vedere se ci sono dei not found. Quasi sicuro sara colpa di libtiff o libmng
ciao ;)
Sembra un problema di linking come succede qui su linux. Dovrebbe dare da shell ldd(o quello che hanno su osx) lib/macos/liblwjgl-devil.jnilib e vedere se ci sono dei not found. Quasi sicuro sara colpa di libtiff o libmng
ciao ;)
Mi dicono dalla regia che probabilmente su osx dovrebbe usare otool -L, oppure objtool -x nome_file | grep NEEDED
ciao ;)
è lo stesso errore che c'ho su linux amd64, relativo alle librerie devil
mi correggo, quello è un problema di linking, su amd64 non funziona bene la libreria devil (non carica le png)
mi correggo, quello è un problema di linking, su amd64 non funziona bene la libreria devil (non carica le png)
Nel tuo caso potrebbe essere un problema di incompatibilità tra 32 e 64. Lwjgl che è compilato a 32bit no riesce a caricare libpng che è a 64bit e quindi esplode tutto.
ciao ;)
Il problema di Cisc sembra piuttosto complicato, ma questo problema di linking su Mac è risolvibile per la FP?
damacorp
21-04-2006, 13:45
Cme per la cronaca, parte la finestra di gioco (con il titolo Diamond Crush) ma non carica nulla.
Le configurazione del Mac è la seguente:
iMac con processore PowerPC G5 1.9ghz
Memoria Ram 1,5 GB DDR2 SDRam
Scheda Grafica ATi X600
OS. Mac OS X Tiger 10.4.6
;)
Il problema di Cisc sembra piuttosto complicato, ma questo problema di linking su Mac è risolvibile per la FP?
Per il problema del mac non possiamo fare niente. L'utente deve installare la libreria che manca. Oppure fare un link al nuovo file. Se mi regalate un mac lo risolvo io.
Per risolvere quello di cisc ci serve una nuova versione di lwjgl compilata a 64bit. Anche qui mi manca un amd64 su cui testare :D
ciao ;)
Per il problema del mac non possiamo fare niente. L'utente deve installare la libreria che manca. Oppure fare un link al nuovo file. Se mi regalate un mac lo risolvo io.
Per risolvere quello di cisc ci serve una nuova versione di lwjgl compilata a 64bit. Anche qui mi manca un amd64 su cui testare :D
ciao ;)
a dire la verità lwjgl l'ho ricompilate per amd64, ma il problema è devil
Sembra un problema di linking come succede qui su linux. Dovrebbe dare da shell ldd(o quello che hanno su osx) lib/macos/liblwjgl-devil.jnilib e vedere se ci sono dei not found. Quasi sicuro sara colpa di libtiff o libmng
ciao ;)
Setup... avanti avanti avanti... pure su macosx... *owned* :D
Per il problema del mac non possiamo fare niente. L'utente deve installare la libreria che manca. Oppure fare un link al nuovo file. Se mi regalate un mac lo risolvo io.
Per risolvere quello di cisc ci serve una nuova versione di lwjgl compilata a 64bit. Anche qui mi manca un amd64 su cui testare :D
ciao ;)
Ok, puoi scrivere due righe che spiegano la situazione e le includiamo nelle known issues del file di readme?
Per il problema del mac non possiamo fare niente. L'utente deve installare la libreria che manca. Oppure fare un link al nuovo file. Se mi regalate un mac lo risolvo io.
Per risolvere quello di cisc ci serve una nuova versione di lwjgl compilata a 64bit. Anche qui mi manca un amd64 su cui testare :D
ciao ;)
Quindi, l'unica soluzione per la FP è indicare sul readme e sul sito che, su alcune configurazioni di Mac, potrebbe essere necessario usare otool -L, oppure objtool -x nome_file | grep NEEDED ???
Quindi, l'unica soluzione per la FP è indicare sul readme e sul sito che, su alcune configurazioni di Mac, potrebbe essere necessario usare otool -L, oppure objtool -x nome_file | grep NEEDED ???
Da quello che mi hanno detto quei due comandi sarebbero l'equivalente di ldd su linux. Servono a capire quale libreria manca per il link. Una volta che abbiamo il nome possiamo trovare una soluzione se è possibile. Purtroppo ho toccato i mac poche volte in vita mia e mai per programmare quindi di piu non so.
ciao ;)
Ok, puoi scrivere due righe che spiegano la situazione e le includiamo nelle known issues del file di readme?
Ora modifico il readme e build.xml per aggiungerlo agli zip.
ciao ;)
a dire la verità lwjgl l'ho ricompilate per amd64, ma il problema è devil
Non hai qualche info in piu? Visto che sembra un problema di lwjgl ci conviene chiedere sul loro forum.
ciao ;)
Non hai qualche info in piu? Visto che sembra un problema di lwjgl ci conviene chiedere sul loro forum.
ciao ;)
già fatto, http://lwjgl.org/forum/viewtopic.php?t=1466 non lo controllavo da un po di tempo, adesso provo il cvs di devil......
cdimauro
21-04-2006, 17:12
Ragazzi, non ce la faccio a rifattorizzare tutto per introdurre i metodi createTexture, necessari per implementare il pooling delle Texture: c'è troppo codice da modificare. Texture viene usata già in tanti posti, ma sono poi roba come Sprite & discendenti che fanno esplodere il numero delle modifiche, a causa della necessità di propagare l'istanza di EngineInterface dove serve.
Inoltre un grosso scoglio è quello del refactoring di CrushBox, a causa della creazione "statica" delle varie texture che usa.
Un macello. Tra poco devo staccare e non ho proprio tempo per continuare e completare il tutto. Mi spiace. :(
Huston, we got a problem.
And when we got a problem, we need a hack. Turatevi il naso...
cdimauro
21-04-2006, 17:20
Se hack = istanza di engine propagata via config o altro, magari un bel po' di lavoro lo si evita, ma restano comunque tanti punti del sorgente che hanno bisogno di engine e non c'è un'istanza di config, o non è immediatamente disponibile.
Per non parlare dei test.
E' un inferno. :cry:
Create solo il display al di fuori di GameLoop... Poi lo passate al costruttore di GameLoop...
cdimauro
21-04-2006, 17:36
Adesso devo proprio andare. Comunque il mio suggerimento è quello di rifattorizzare il costruttore di CrushBox subito dopo Engine / Texture: è il punto più critico, IMHO.
Mi spiace ancora per non essere riuscito a completare questo lavoro. :(
Ci rivediamo lunedì.
Comunque ora funziona...fa tutto secondo le previsioni...quindi che si fa ? Siamo a cavallo ?
Ah...non avevo capito che parlavate dell'altro bug :muro: :muro: :muro:
TextureBank :fiufiu:
Adesso devo proprio andare. Comunque il mio suggerimento è quello di rifattorizzare il costruttore di CrushBox subito dopo Engine / Texture: è il punto più critico, IMHO.
Mi spiace ancora per non essere riuscito a completare questo lavoro. :(
Ci rivediamo lunedì.
Non ti preoccupare, ci vediamo lunedi' con l'uscita della FP :)
In questo momento Config gia propaga Audio. E se lo rinominassimo in qualcosa tipo Enviroment o simile e gli facessimo propagare anche altre cose tipo timer, engine?
ciao ;)
ok, adesso diamonds mi parte sull'amd64, avevo compilato lwjgl a gennaio, adesso ho compilato devil da cvs con il fix per le png e funziona
Jocchan: che ne dici di usare x, c e v per le rotazioni del player 1 ? farebbe recuperare un po' di spazio per il player 2...altrimenti in questo modo ci teniamo per mano :)
Jocchan: che ne dici di usare x, c e v per le rotazioni del player 1 ? farebbe recuperare un po' di spazio per il player 2...altrimenti in questo modo ci teniamo per mano :)
li vedo troppo vicini come tasti....
Jocchan: che ne dici di usare x, c e v per le rotazioni del player 1 ? farebbe recuperare un po' di spazio per il player 2...altrimenti in questo modo ci teniamo per mano :)
Ci stavo pensando prima. A cosa ci serve il tasto su ?
Q,W,E per ler direzioni e Z,X,C per le rotazioni del player 1.
Il player 2 è invariato tranne per il tasto Su.
ciao ;)
A cosa ci serve il tasto su ?
:rotfl: :rotfl: :rotfl: :rotfl:
Sono d'accprdo ...comunque.
Scusate l'assenza in questi giorni caldi....ma purtroppo ci sono motivi superiori (studio :puke:)
Io stasera torno mooolto dopo il lock. Sarebbe bello che qualcuno facesse un post sui fronti ancora aperti e critici...
Ci stavo pensando prima. A cosa ci serve il tasto su ?
Q,W,E per ler direzioni e Z,X,C per le rotazioni del player 1.
Il player 2 è invariato tranne per il tasto Su.
ciao ;)
In teoria in SPF2T il tasto "Freccia Su" è l'instant drop della gemspair
Committato un fix (spero) per il bug 23...che però non sono riuscito a riprodurre anche allocando 2 GB di texture...
Quindi la parola a chi riesce a riprodurlo per vedere se abbiamo risolto questo bug...
Ci stavo pensando prima. A cosa ci serve il tasto su ?
Q,W,E per ler direzioni e Z,X,C per le rotazioni del player 1.
Il player 2 è invariato tranne per il tasto Su.
ciao ;)
Per la FP il tasto su non ci serve, ma più avanti l'idea è di usarlo per l'instant drop (senza contare che la dinamite, nell'Advanced Mode, necessiterà di un altro tasto, per cui pensavo di "tenere da parte" la E o la Q).
Ora, noi ragioniamo sempre per YAGNI, e quindi potremmo benissimo fregarcene e implementare una configurazione (leggermente, perchè il cambiamento non sarebbe poi così eclatante) più comoda (quella di Cionci direi, visto che anche usando Q,W ed E accedere a Z, X e C, ma soprattutto a Z e X, molto più importanti, non è per niente facile).
Il mio unico dubbio è però che diffondere una versione con questa configurazione, e poi cambiarla in maniera tanto evidente, possa generare confusione in chi giocherà.
E' vero, i tasti saranno configurabili, ma introdurre deliberatamente un elemento di confusione non è quasi mai una scelta vantaggiosa.
Quindi, se riusciamo a trovare una configurazione migliore di quella attuale ben venga, altrimenti direi di evitare "sconvolgimenti" dell'ultimo minuto.
In teoria in SPF2T il tasto "Freccia Su" è l'instant drop della gemspair
Nel coin-op e (credo) su PSX il tasto su è inutilizzato :p
In ogni caso, abbiamo troppi tasti, e questo va contro il nostro "keep being simple". Quindi, pur senza toglierlo, non segnaleremo il mirroring.
Lo lasceremo come "Easter egg", utilizzabile da giocatori esperti ma - assolutamente - non necessario per giocare.
Nel coin-op e (credo) su PSX il tasto su è inutilizzato :p
In ogni caso, abbiamo troppi tasti, e questo va contro il nostro "keep being simple". Quindi, pur senza toglierlo, non segnaleremo il mirroring.
Lo lasceremo come "Easter egg", utilizzabile da giocatori esperti ma - assolutamente - non necessario per giocare.
Nella versione Game Boy advance funziona ed è utilissimo a mio parere :)
Nella versione Game Boy advance funziona ed è utilissimo a mio parere :)
Lo so :)
Lo inseriamo apposta per questo.
Anche il mirroring è utile in casi di emergenza, se hai sufficiente manualità.
Però, non possiamo confondere il giocatore, quindi semplicemente (visto che è un comando "non fondamentale, ma utile") non ne segnaliamo la presenza.
P.S. Vic, potresti ripassare un attimo su MSN per favore?
Committato un fix (spero) per il bug 23...che però non sono riuscito a riprodurre anche allocando 2 GB di texture...
Quindi la parola a chi riesce a riprodurlo per vedere se abbiamo risolto questo bug...
ho provato a far girare 5000 volte il test che prima dava il problema, e nn da piu il textureNotFound(pero è un test, nn è detto che in gioco funzioni..)
dopo 2000 test pero da outOfMemory java heap space, ma penso sia normale.
ok, adesso diamonds mi parte sull'amd64, avevo compilato lwjgl a gennaio, adesso ho compilato devil da cvs con il fix per le png e funziona
Dobbiamo anche inserire la versione compilata a 64bit nel nostro package? O magari la mettiamo scaricabile dal sito.
Dobbiamo anche inserire la versione compilata a 64bit nel nostro package? O magari la mettiamo scaricabile dal sito.
Fatemi sapere cosa deve essere scaricabile per giocare (a proposito, chi vuole dare una sbirciata al sito mi contatti su MSN) ;)
Fatemi sapere cosa deve essere scaricabile per giocare (a proposito, chi vuole dare una sbirciata al sito mi contatti su MSN) ;)
I file zip delle varie architetture sono autocontenuti. Oltre a quelli non serve altro.
Per la versione a 64bit non so se possiamo integrarla con il build system ma possiamo provare. Cisc puoi creare una cartella linux64 sotto a lib/ e committare i .so che hai compilato?
ciao ;)
I file zip delle varie architetture sono autocontenuti. Oltre a quelli non serve altro.
Per la versione a 64bit non so se possiamo integrarla con il build system ma possiamo provare. Cisc puoi creare una cartella linux64 sotto a lib/ e committare i .so che hai compilato?
ciao ;)
Riusciamo a fare quest'integrazione entro un'oretta? Alle 22 in punto prendo il tag appena Jocchan mi da' l'ok e da li' in poi la FP non si tocca piu' secular seculorum.
Riusciamo a fare quest'integrazione entro un'oretta? Alle 22 in punto prendo il tag appena Jocchan mi da' l'ok e da li' in poi la FP non si tocca piu' secular seculorum.
Se becco cisc online prima delle 22 ci provo. Altrimenti sarà per la prossima release.
Cmq. anche senza supporto per amd64 abbiamo fatto proprio un bel lavoro. Non so voi ma io in questi mesi mi sono divertito come un matto. :yeah:
ciao ;)
Bug di livello C: al posto della png Counter viene mostrata della grafica tutta sballata.
I file zip delle varie architetture sono autocontenuti. Oltre a quelli non serve altro.
Per la versione a 64bit non so se possiamo integrarla con il build system ma possiamo provare. Cisc puoi creare una cartella linux64 sotto a lib/ e committare i .so che hai compilato?
ciao ;)
lo sto facendo, c'è solo da precisare che funzionano solo con x.org, ho provato a compilarli con xfree, ma nisba....con tutti i problemi che avevo, ho preferito cambiare server x:D
Bug di livello C: al posto della png Counter viene mostrata della grafica tutta sballata.
A me non risulta :confused:
dopo 2000 test pero da outOfMemory java heap space, ma penso sia normale.
Ma allora non è un problema delle texture... Ho allocato 100000 texture in un vettore è mi ha swappato anche l'anima :D
Per il bug di un paio di post fa, non mi succede più.
Ora che ci faccio caso, è capitato dopo aver lasciato il gioco ridotto a icona per un paio di minuti... ed era una cosa "nota".
Essendo un evento che comunque non dipende direttamente dal gioco, lo indicherò come bug di livello D, e lo risolveremo dopo la FP.
A parte questo, siamo prontissimi per impacchettare.
Ottimo lavoro a tutto il team. :cincin:
Ma allora non è un problema delle texture... Ho allocato 100000 texture in un vettore è mi ha swappato anche l'anima :D
prima era un prob di texture, ora il problema sembra nn esserci piu.
sto facendo giarare il gioco da piu di un ora e nn batte ciglio =D
ps. fra l'altro è stabile a 37MB di ram occupata
lo sto facendo, c'è solo da precisare che funzionano solo con x.org, ho provato a compilarli con xfree, ma nisba....con tutti i problemi che avevo, ho preferito cambiare server x:D
Questo va messo nel readme.txt come known issue. Puoi farlo?
Questo va messo nel readme.txt come known issue. Puoi farlo?
In locale funziona tutto con l'amd64.....ho modificato anche il readme...vedremo se funzionerà anche ad altri.....
Ce lo diranno lunedi' :)
Ok, la First Playable e' ora nella sua tag, non possiamo piu' modificarla. Bravi tutti :)
A me continua a non andare sotto gentoo..uff, lunedì alla FP (che oltre tutto sarò via fino tardo pomeriggio :( ) la farò provare a un pò di altre persone sotto questo OS,avrò fatto io qualche danno sicuramente ^^°°°
Lunedì mattina inoltre ho già organizzato a casa di un mio compagno un mini torneo di diamonds per testarlo a fondo :D
Uomo con l'ascia
22-04-2006, 01:01
ISCRIVETEVI QUI!!!
URL EDITATA
Iniziamo a eliminare un pò di rumore, che ne dite? :stordita:
Ce lo diranno lunedi' :)
Ok, la First Playable e' ora nella sua tag, non possiamo piu' modificarla. Bravi tutti :)
Un applauso a tutti!! :mano:
Era da un sacco che non mi divertivo così a programmare...grazie a tutti per quello che ho imparato!!!
... e che continuerò a imparare ;)
Un continuo del cover bug :Prrr:
Non penso sia di priorità assoluta per la FP (anche premendo continuamente non si riesce a spostare in tempo, quindi ci sarebbe comunque game over...l'unica cosa persa sarebbero ovviamente dei punti in più e un brutto effetto), ma comunque a joc l'ultima parola.
Allego filmato che vale più di mille parole ^^
www.revoc.net/coverbug.avi.zip
Hmmmm... l'effetto è orribile.
Quindi, non abbiamo fixato bene il bug delle cancellazioni da fare prima del game over. Ce la facciamo a risolverlo domani (oddio, oggi... è già l'una)?
E' il bug 17 redivivo.
Ora si presenta quando c'è una sola casella libera nella quarta colonna, e non è possibile inserire tutta la gemspair... però se nella casella inferiore ci fosse un baule, e magari la colonna avesse subito sotto diverse gemme di quel colore, il gioco andrebbe in game over senza motivo.
Quindi, il bug resta di livello A
Bene, Cisc sta facendo delle prove.
Bene, Cisc sta facendo delle prove.
Non lo fissiamo per la FP.
Non lo fissiamo per la FP.
Immaginavo, e visto che manca così poco a lunedì è una cosa a cui stavo pensando anche io (magari per la prossima release), ma dobbiamo fissarlo.
L'addetto alle pubbliche relazioni...o in questo caso meglio conosciuto come bug hunter è tornato... :Prrr: :Prrr:
http://img213.imageshack.us/my.php?image=x6qn.jpg
Giocatore 2 (io) con una distruzione di massa ha fatto cadere al giocatore 1 (io :Prrr: ) 36 stone...il risultato? il giocatore 1 fermo senza game over e il secondo che continuava a giocare...
Edit: aggiunto filmato: www.revoc.net/coverbug2.avi.zip
Edit: questo bug non è mai esistito... :Prrr:
Mea culpa, avevo visto male ^^
et voilà, bug 17 redivivo fixato, il problema era che le crush partivano dalla riga 1 in poi, e non dalla riga 0
Ottimo lavoro, Cisc.
Ora manca solo il secondo Coverbug.
A seconda dei bug report che riceveremo, e' possibile che si faccia uscire una seconda FP all'inizio della settimana succesiva con tutti questi bug fix. Vedremo.
Consideriamo anche che i due bug scovati da Cover, anche se piuttosto rari, sono entrambi di livello A.
In ogni caso, che la 1.0a si faccia o no, ho diviso i bug fixati come se questa fosse sicura, in modo da sapere con certezza quali dei bug fixati ultimamente sono ancora presenti nella FP che distribuiremo domani.
Per il coverBug....diciamo che la garanzia non è bastata :cry:
In realtà la soluzione che avevo introdotto funzionava perfettamente....
...solo che adesso il GameOver non è più testato real-time, ma dipende dall'update e quindi dal passaggio di stato.
Per risolverlo basta mettere il controllo di GameOver anche in StoneFallState.
Non penso di avere molto tempo....ma se riesco faccio il test e il bugFix.
Per il coverBug....diciamo che la garanzia non è bastata :cry:
In realtà la soluzione che avevo introdotto funzionava perfettamente....
...solo che adesso il GameOver non è più testato real-time, ma dipende dall'update e quindi dal passaggio di stato.
Per risolverlo basta mettere il controllo di GameOver anche in StoneFallState.
Non penso di avere molto tempo....ma se riesco faccio il test e il bugFix.
Parli del secondo bug?
Il primo l'ha risolto Cisc con un >= al posto di un > :)
Parli del secondo bug?
Il primo l'ha risolto Cisc con un >= al posto di un > :)
Parlo di questo
25 - Coverbug2, si veda http://www.hwupgrade.it/forum/showp...7&postcount=437 A
Appena commitatto e risolto :sofico: :sofico:
Parlo di questo
Appena commitatto e risolto :sofico: :sofico:
Grandissimo ;)
Piuttosto, ho notato piuttosto chiaramente che, almeno in due occasioni, non mi è stata mostrata la CrushBox.
cdimauro
24-04-2006, 08:54
TextureBank :fiufiu:
Ho visto adesso: ottima soluzione. :)
Rimane da rifattorizzare di Engine/Texture: adesso c'è più tempo e tranquillità, ma il lavoro da fare è sempre enorme. :cry:
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.