View Full Version : Thread dei Problemi
Ciao ragazzi!
Stamattina stavo testando Diamonds e ho notato che dopo aver creato un cubo da 4 gemme gialle, se ne metto sopra altre 2 gialle non si crea il gemmone da 2X3, ma resta il cubo con sopra le 2 gemme gialle.
Provando con le altre gemme invece funziona. con alcuni tipi di gemme funziona e con uno solo no? :confused:
strano assai, un solo specifico tipo di gemma non dovrebbe influire sul riconoscimento degli agglomerati, forse hai prodotto quelle combinazioni in maniere differenti; non è che riesci a ricostruire le mosse esatte da fare (come ho fatto io più su) in modo tale da permetterci di riprodurre l'errore?
grazie :)
oggi gli errori saltano fuori come i funghi :p
ho appena aggiornato, e il problema precedente non mi si presenta più, ma adesso se ne presenta un altro che prima non mi sembrava esserci (vedere screenshot).
mentre cercavo l'esatta sequenza per riprodurre il precedente ne ho trovato un altro :muro:
può anche darsi che sia lo stesso bug...
ok, ecco l'esatta sequenza per il precedente:
O
O O
OOX
OO
OOO
OOX
cioè, formate la solista specie di U incompleta, aspettate che arrivi la doppia gemma, e riempite la U.
ok oggi io e fek sistemiamo tutto in pair
Oggi ero via ed ero curioso di sapere se si era risolta la serie di bug...
allora ?? :confused:
Altra cosa...come mai la build mi dà errore sul checkstyle in BigGem ?!? :mc:
ora non posso metterela a posto...sto uscendo :sborone:
...stanotte controllo :D :D
complimenti ragazzi, uno dei due problemi non si presenta più, ma ne è rimasto un altro ^^
nello screenshot i due gemmoni bianchi in basso avrebbero dovuto unirsi...
per riprodurre questo problema basta che cerchiate di formare indipendentemente i due gemmoni: uno da destra e uno da sinistra; provo a spiegarmi meglio con uno schema:
O O
OOOO
OO O
OOOO
OOOO
OOOO
e non dimenticatevi di quest'altro :D
O
OOO
OOX
OO
OOO
OOX
PS: gli darei molto volentieri un'occhiata io al codice ma sono sotto esami :cry:
strano che il bug non si presenti più dato che per ora non abbiamo ancora reso BigGem "ufficiale" :p
BlueDragon
22-01-2006, 13:40
strano che il bug non si presenti più dato che per ora non abbiamo ancora reso BigGem "ufficiale" :p
Beh, quello che avete messo nel repository si scarica e si vede.. :)
Cmq ho provato oggi a dedicarmi al progetto e vedere un po' la causa di questi problemi con i gemmoni (mi hanno reso curioso): ho esplorato un po' il codice ed andando a caso non ho trovato quello che cercavo (cioé il punto in cui si decide che un gemmone vada esteso) ma ho trovato alcune cose strane.. vi cito quelle che penso siano più rilevanti:
1) Il metodo update updateBigGems() in Grid: sembra gestire tutta la questione dei gemmoni che si allargano ed invece..."non serve a niente"!
L'unica classe a chiamare updateBigGems() è una classe di Test... il gioco funziona benissimo senza. Ci sono quindi dei test per una cosa che non usiamo? E' un residuo di qualcosa?
Inoltre updateBigGems() è l'unica a chiamare createNewBigGems() che è anche bello complesso....e non usato nel gioco :)
2) containsCell(int row, int column) in BigGem fa un ciclo su tutte le gemme di BigGem per vedere se ce n'è una che corrisponda a quella posizione. Ma non basterebbe vedere se quella posizione è presente nel rettangolo di BigGem?
Beh, ho provato a sostituire il ciclo con un
if (rowContained >= dimensions.bottom() && rowContained <= dimensions.top()
&& columnContained >= dimensions.left() && columnContained <= dimensions.right())
{
return true;
}
(ho refattorizzato il nome della variabile row in rowContained).
E cosa succede? Beh, quando lancio i test ad un certo punto vanno in loop e non finiscono più...
Non ho indagato a fondo la questione (non ho nemmeno cercato qual'è il test che impazzisce) ma è un po' strano....:)
2) containsCell(int row, int column) in BigGem fa un ciclo su tutte le gemme di BigGem per vedere se ce n'è una che corrisponda a quella posizione. Ma non basterebbe vedere se quella posizione è presente nel rettangolo di BigGem?
Il rettangolo è arrivato dopo quel metodo :p
1) Il metodo update updateBigGems() in Grid: sembra gestire tutta la questione dei gemmoni che si allargano ed invece..."non serve a niente"!
L'unica classe a chiamare updateBigGems() è una classe di Test... il gioco funziona benissimo senza. Ci sono quindi dei test per una cosa che non usiamo? E' un residuo di qualcosa?
Inoltre updateBigGems() è l'unica a chiamare createNewBigGems() che è anche bello complesso....e non usato nel gioco :)
BigGem e' una classe che stiamo sviluppando io e Ufo in Pair per risolvere i problemi di GemGroup, che e' la classe che si occupa dei gemmoni al momento. Non e' usata dal gioco perche' la stiamo ancora sviluppando e testando. Quando sara' relativamente stabile sostituiremo il codice vecchio con quello nuovo.
2) containsCell(int row, int column) in BigGem fa un ciclo su tutte le gemme di BigGem per vedere se ce n'è una che corrisponda a quella posizione. Ma non basterebbe vedere se quella posizione è presente nel rettangolo di BigGem?
Beh, ho provato a sostituire il ciclo con un
Perche' no? :D
E cosa succede? Beh, quando lancio i test ad un certo punto vanno in loop e non finiscono più...
Non ho indagato a fondo la questione (non ho nemmeno cercato qual'è il test che impazzisce) ma è un po' strano....:)
Ci guardo, l'idea e' interessante.
if (rowContained >= dimensions.bottom() && rowContained <= dimensions.top()
&& columnContained >= dimensions.left() && columnContained <= dimensions.right())
{
return true;
}
secondo me è sbagliato il codice.... Credo che la versione corretta sia:
if (rowContained <= dimensions.bottom() && rowContained >= dimensions.top()
&& columnContained >= dimensions.left() && columnContained <= dimensions.right())
{
return true;
}
Spero di fare cosa utile segnalando questo problema, anche se riguarda solo la mia macchina:
OS: Mac OS X
Version: 10.4.4
Architecture: ppc
VM Vendor: Apple Computer, Inc.
Version: 1.5.0_05
Class Path: /Users/gica/Sviluppo/eclipse/Diamonds/bin:/Users/gica/Sviluppo/eclipse/Diamonds/lib/junit.jar:
/Users/gica/Sviluppo/eclipse/Diamonds/lib/easymock.jar:/Users/gica/Sviluppo/eclipse/Diamonds/lib/jar/lwjgl.jar:
/Users/gica/Sviluppo/eclipse/Diamonds/lib/jar/lwjgl_devil.jar:/Users/gica/Sviluppo/eclipse/Diamonds/lib/jar/lwjgl_util.jar
JNI Library Path: lib/macos
Exception: class it.diamonds.engine.video.TextureException
Message: Texture loading error due to org.lwjgl.LWJGLException: Could not load ilu library.
Display Adapter Driver: null null
Stacktrace:
it.diamonds.engine.video.TextureException: Texture loading error due to org.lwjgl.LWJGLException: Could not load ilu library.
at it.diamonds.engine.video.Texture.loadTextureFromFile(Texture.java:127)
at it.diamonds.engine.video.Texture.<init>(Texture.java:87)
at it.diamonds.Background.<init>(Background.java:22)
at it.diamonds.Game.createBackground(Game.java:193)
at it.diamonds.Game.main(Game.java:72)
jappilas
22-01-2006, 16:25
ciao a tutti
da me con la rev 1157 ant build fallisce a livello Checkstyle con questi errori:
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\BigGem.java:90:19: 'row' hides a field.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\BigGem.java:106:19: 'column' hides a field.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\BigGem.java:122:19: 'column' hides a field.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\BigGem.java:140:18: 'column' hides a field.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\BigGem.java:158:18: 'column' hides a field.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\BigGem.java:169:18: 'row' hides a field.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\BigGem.java:187:18: 'row' hides a field.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\BigGem.java:285:5: Cyclomatic Complexity is 9 (max allowed is 8).
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\BigGemTileType.java:6: Class BigGemTileType should be declared as final.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\BigGemTileType.java:8:18: 'static' modifier out of order with the JLS suggestions.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\BigGemTileType.java:9:18: 'static' modifier out of order with the JLS suggestions.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\BigGemTileType.java:10:18: 'static' modifier out of order with the JLS suggestions.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestBigGemDrawing.java:67:20: 'engine' hides a field.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestBigGemDrawing.java:80:20: 'engine' hides a field.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestBigGemDrawing.java:93:20: 'engine' hides a field.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestBigGemDrawing.java:106:20: 'engine' hides a field.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestBigGemDrawing.java:119:20: 'engine' hides a field.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestBigGemDrawing.java:132:20: 'engine' hides a field.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestBigGemDrawing.java:145:20: 'engine' hides a field.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestBigGemDrawing.java:158:20: 'engine' hides a field.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestBigGemDrawing.java:181:20: 'engine' hides a field.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestBigGemDrawing.java:201:20: 'engine' hides a field.
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestGridWithBigGem.java:389: Found duplicate of 15 lines in E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestGridWithBigGem.java, starting from line 469
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestGridWithBigGem.java:409: Found duplicate of 15 lines in E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestGridWithBigGem.java, starting from line 489
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestGridWithBigGem.java:449: Found duplicate of 15 lines in E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestGridWithBigGem.java, starting from line 529
[checkstyle] E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestGridWithBigGem.java:469: Found duplicate of 15 lines in E:\Devel\Dev\Eclipse\Diamonds\src\it\diamonds\tests\TestGridWithBigGem.java, starting from line 549
BUILD FAILED
ora, molto probabilmente riguardano codice in fase di heavy coding & refactoring... se quest' indicazione non è d' aiuto o è ridondante, chiedo scusa :stordita:
Scusate se sono troppo invadente...ma perchè non avete fatto un thread sul pair programming per il bug fixing???
Dai Ufo13 & Fek.... :ave :ave:
Non so Fek ha voluto farlo solo via MSN... Non era un vero task in effetti...
Comunque ho committato la versione definitiva... Provatela :)
Bene... Ho già trovato 2 cose da sistemare :D
jappilas
22-01-2006, 17:37
:) :cool: ;)
...era qualche giorno che non vedevo più la build successful, mi sentivo quasi perso... :stordita:
occhio a questo ragazzi, guardate lo screenshot :)
supponiamo di riuscire a formare un gemmone di altezza 2 che non tocchi per terra ma sia appoggiato su altre gemme; il problema è che se arriva una coppia di due gemme uguali e dello stesso colore del gemmone, quando questa cade sfiorando il gemmone assume le forme che assumerebbe se fosse "droppata" e fusa accanto ad esso, solo che non essendo droppata continua a cadere e continua ad avere quelle forme anche quando poi tocca terra.
il problema è semplice: non ho visto il codice, ma suppongo che abbiate erroneamente fatto il controllo per i rettangoli senza prima controllare che tutte le gemme facenti parte del rettangolo che controllare siano dropped. :)
PS: se arrivo tardi e sono niubbo e sono old me ne scuso ^^
occhio a questo ragazzi, guardate lo screenshot :)
supponiamo di riuscire a formare un gemmone di altezza 2 che non tocchi per terra ma sia appoggiato su altre gemme; il problema è che se arriva una coppia di due gemme uguali e dello stesso colore del gemmone, quando questa cade sfiorando il gemmone assume le forme che assumerebbe se fosse "droppata" e fusa accanto ad esso, solo che non essendo droppata continua a cadere e continua ad avere quelle forme anche quando poi tocca terra.
il problema è semplice: non ho visto il codice, ma suppongo che abbiate erroneamente fatto il controllo per i rettangoli senza prima controllare che tutte le gemme facenti parte del rettangolo che controllare siano dropped. :)
PS: se arrivo tardi e sono niubbo e sono old me ne scuso ^^
lollez ce la fai mica a scrivere un test per questo caso?
Sono nel pieno del trasloco, la build machine andra' e verra' oggi. E poi andra' per un po' finche' non mi riallacciano l'adsl.
Qualcuno puo' fornire una build a Jocchan?
Poi c'e' da prendere il tag dell'iterazione.
E poi Jocchan e Vic, dovete fare i task nuovi senza di me oggi.
La build gliel'ho passata io ieri notte... cosa sono i tag? :p
Sarebbe il numero di build? :o
Sono nel pieno del trasloco, la build machine andra' e verra' oggi. E poi andra' per un po' finche' non mi riallacciano l'adsl.
Qualcuno puo' fornire una build a Jocchan?
Poi c'e' da prendere il tag dell'iterazione.
E poi Jocchan e Vic, dovete fare i task nuovi senza di me oggi.
Al tag ci penso io.
Però per i task non so se riusciremo. Sto litigando con msn che non si installa più. :mad:
ciao ;)
Al tag ci penso io.
Però per i task non so se riusciremo. Sto litigando con msn che non si installa più. :mad:
ciao ;)
Intanto ho postato la prima storia, per la seconda ne metteremo su una di servizio, con tutti i fix vari ed eventuali.
Aggiornamento. Da domani rivedrete me e la build machine online da casa nel giro di una ventina di giorni.
Se qualcuno vuole hostare la build machine sono circa 1.5 gb (ouch).
Intanto ho postato la prima storia, per la seconda ne metteremo su una di servizio, con tutti i fix vari ed eventuali.
Ora provo a scrivere qualcosa poi ti mando un pm sul forum. Vediamo se cosi riusciamo a combinare qualcosa.
ciao ;)
E' una mia impressione o dal task sui gemmoni le cose stanno prendendo una brutta piega... :cry: :cry:
..sembra che vada tutto storto...
...ma mi vien solo voglia di fare di più !! :sofico: :sofico:
E' una mia impressione o dal task sui gemmoni le cose stanno prendendo una brutta piega... :cry: :cry:
..sembra che vada tutto storto...
...ma mi vien solo voglia di fare di più !! :sofico: :sofico:
Sara colpa di qualche congiunzione astrale sfavorevole. :D
ciao ;)
E' una mia impressione o dal task sui gemmoni le cose stanno prendendo una brutta piega... :cry: :cry:
..sembra che vada tutto storto...
...ma mi vien solo voglia di fare di più !! :sofico: :sofico:
Ma no, sta andando tutto piuttosto bene, la storia dei gemmoni era la piu' complessa e l'abbiamo comunque finita in tempo. Non male. Ora la Storia di questo ciclo non e' neppure banalissima, anzi. Ci sono diverse incognite. Finita questa Storia, sostanzialmente il gioco e' finito nelle funzionalita' base :)
Da qui in poi ci saranno solo storie di supporto per sistemare i particolari del gameplay, magari creare il linguaggio di scripting per la parte single player e poi il multiplayer.
La build machine e' su, io sono ancora senza casa ma almeno ho un tetto per le prossime due settimane.
fek, ma a proposito di single player: dovremo sviluppare una AI minima?
fek, ma a proposito di single player: dovremo sviluppare una AI minima?
Niente AI, ho sistemato la struttura dello Story Mode in modo da non richiederne nemmeno una riga (ci saranno solo dei pattern fissi) ;)
ragazzi, a quanto il prossimo ciclo, che mi manca un po di coding su diamonds:D, ho abbandonato l'amd64, per diamonds mi arrangio sul portatile
ragazzi, a quanto il prossimo ciclo, che mi manca un po di coding su diamonds:D, ho abbandonato l'amd64, per diamonds mi arrangio sul portatile
I task sono già pronti. Aspetto solo una conferma.
ciao ;)
I task sono già pronti. Aspetto solo una conferma.
ciao ;)
Vic, mandameli via mp o via mail (mio nick + cicciolina + diamondcrush + punto + net) per favore ;)
Vic, mandameli via mp o via mail (mio nick + cicciolina + diamondcrush + punto + net) per favore ;)
Li ho gia mandati qualche ora fa sul forum ma evidentemente non sono arrivati :muro:
Provo a reinviarli.
ciao ;)
Scusate...ma nelle funzionalità base non ci sono anche le animazioni dei personaggi che si menano?? :stordita:
Scusate...ma nelle funzionalità base non ci sono anche le animazioni dei personaggi che si menano?? :stordita:
Per ora non ci servono quindi non ci pensiamo. :)
ciao ;)
Stacco la build machine per un paio d'ore.
Sono stato via per qualche giorno, torno e ci sono già le "gemmone" :|
Inizio ad avere paura di voi :D
Comunque, giocandoci un pò è saltato fuori un piccolo problema (non sò se è già stato notato da qualcuno):
se esiste già un blocco, e manca solo un'altra gemma per una nuova fusione, quando questa sta cadendo prima di essere droppata (appena entrata nella sua casella) avrà già la forma del gemmone...s'è capito ? ^^
Comunque screenshot che forse si capisce di più...
http://img230.imageshack.us/img230/2601/untitled6mp.jpg (http://imageshack.us)
Sono stato via per qualche giorno, torno e ci sono già le "gemmone" :|
Inizio ad avere paura di voi :D
Comunque, giocandoci un pò è saltato fuori un piccolo problema (non sò se è già stato notato da qualcuno):
se esiste già un blocco, e manca solo un'altra gemma per una nuova fusione, quando questa sta cadendo prima di essere droppata (appena entrata nella sua casella) avrà già la forma del gemmone...s'è capito ? ^^
Comunque screenshot che forse si capisce di più...
http://img230.imageshack.us/img230/2601/untitled6mp.jpg (http://imageshack.us)
Me n'ero accorto anche io, ed è uno dei piccoli bug che correggeremo nella storia 2 (e rientra nel caso già segnalato da 71104) ;)
Altro bug che correggeremo:
http://lnx.rc6.it/diamonds/varie/bug001.jpg
Il gioco continua a valutare gemme già impegnate in un agglomerato, con il risultato che, quando si costruiscono agglomerati grandi, ne vengono generati due (o più) sovrapposti.
cdimauro
25-01-2006, 09:40
Il fatto che il gioco continui a valutare agglomerati non è un male, perché in teoria due agglomerati potrebbero anche "fondersi". L'importante è valutare quando ha senso farlo e quando no.
Altro bug che correggeremo:
Ok, sono due bug relativamente semplici da fissare. Mi servono due test. E passiamo subito ai fix.
Ok, sono due bug relativamente semplici da fissare. Mi servono due test. E passiamo subito ai fix.
public void test4x4BigGem()
{
insert2x2BlockOfGems(GemType.EMERALD, 12, 3);
grid.updateBigGems();
insert2x2BlockOfGems(GemType.EMERALD, 12, 5);
grid.updateBigGems();
insert2x2BlockOfGems(GemType.EMERALD, 10, 3);
grid.updateBigGems();
insert2x2BlockOfGems(GemType.EMERALD, 10, 5);
grid.updateBigGems();
assertEquals("Grid must have one BigGem", 1, grid.numberOfBigGems());
}
:)
non è che qualcuno riesce a far passare questo test :p
Scusate...spartacus è down o ho problemi io??? :muro: :muro:
Sono stato via per qualche giorno, torno e ci sono già le "gemmone" :|
Inizio ad avere paura di voi :D
Comunque, giocandoci un pò è saltato fuori un piccolo problema (non sò se è già stato notato da qualcuno):
se esiste già un blocco, e manca solo un'altra gemma per una nuova fusione, quando questa sta cadendo prima di essere droppata (appena entrata nella sua casella) avrà già la forma del gemmone...s'è capito ? ^^
Comunque screenshot che forse si capisce di più...
http://img230.imageshack.us/img230/2601/untitled6mp.jpg (http://imageshack.us)
si, il problema era già stato evidenziato; l'errore sta nel fatto che il controllo sui rettangoli non tiene conto del fatto che una gemma con cui esso viene effettuato potrebbe non essere "dropped"; adesso provo a scrivere un test...
PS: cavolo, sei stato veloce a prendere lo screenshot tempestivamente prima che la gemma si unisse al resto del gemmone :D
ecco fatto:
public void testNonDroppedGems()
{
insertAndUpdate(createEmerald(), 13, 4);
insertAndUpdate(createEmerald(), 13, 5);
insertAndUpdate(createEmerald(), 12, 4);
insertAndUpdate(createEmerald(), 12, 5);
insertAndUpdate(createEmerald(), 13, 6);
insertAndUpdate(createEmerald(), 11, 6);
grid.updateBigGems();
assertFalse(grid.isCellInABigGem(12, 6));
}
ho anche corretto il bug e committato, ora non dovrebbe più presentarsi; cover, puoi verificare anche tu per favore?
ora rimane solo l'altro bug delle gemmone sovrapposte, dopodiché la costruzione delle big gems dovrebbe essere a posto...
71104 c'è un bug nell'introduzione del baule... prova a fare un test con un gruppo 2x2 di bauli dello stesso tipo... lancia un'eccezione
Non sono sicuro che il problema si possa mai presentare ma secondo me una combo potrebbe far venir fuori una configurazione di quel tipo... Meglio evitare l'eccezione imho
lo so lo so, sono a conoscenza del problema: l'eccezione viene lanciata perché il programma tenta di costruire la gemmona di bauli, ma non trova la texture per farlo; guarda il thread della storia corrente, dobbiamo fare un refactoring in proposito.
[checkstyle] D:\Valerio\workspace\Diamonds\src\it\diamonds\gems\GemFactory.java:15:5: Variable access definition in wrong order.
[checkstyle] D:\Valerio\workspace\Diamonds\src\it\diamonds\gems\GemFactory.java:17:5: Variable access definition in wrong order.
Ma in che cavolo di ordine li vuole :muro: :muro: :muro: le ho provate tutte!!
Non è : public static final int ????
Siamo sicuri che le probabilità tra bauli e gemme sia sufficentemente diversa??
Non è : public static final int ????
Sì, ma li devi mettere in cima alle lista delle dichiarazioni ;)
[checkstyle] D:\Valerio\workspace\Diamonds\src\it\diamonds\gems\GemFactory.java:15:5: Variable access definition in wrong order.
[checkstyle] D:\Valerio\workspace\Diamonds\src\it\diamonds\gems\GemFactory.java:17:5: Variable access definition in wrong order.
Ma in che cavolo di ordine li vuole :muro: :muro: :muro: le ho provate tutte!!
Non è : public static final int ????
sistemato, fai update :)
:help: :help: :help:
public static final int NO_GEM_INDEX = GEM_TYPES.length;
public static final int GEM_FREQUENCY = 90;
private static final GemType GEM_TYPES[] = { DIAMOND, RUBY, SAPPHIRE, EMERALD, TOPAZ, DIAMONDBOX, RUBYBOX, SAPPHIREBOX, EMERALDBOX, TOPAZBOX };
Come si fa a metterlo in cima...dà errore!!!
Ma adesso non sono più pubblic!!!
Possono non esserlo ...??? :bimbo:
devono essere privati se non servono fuori dalla classe :)
Oddio... devono è una parola grossa... è molto meglio che la visibilità resti minimale...
Si...lo so ...quello che mi chiedevo e se quelle due variabili erano state definite pubbliche per un motivo o per "errore"...
...sicccome passa i test e compila...direi che era stato un "errore" :D
ho risolto il bug delle gemme che si sovrappongono però ora ne è uscito un altro:
java.util.ConcurrentModificationException
provando a fare una gemma 4x4 costruento 3 gemme dello stesso tipo:
AABB
AABB
CCCC
CCCC
ovvero inserendo prima tutte le C, poi tutte le B e poi 3A tenendosi per ultima questa (la O):
XOXX
XXXX
XXXX
XXXX
Io purtroppo non ho tempo stasera per fixare anche questo
Non so se è la stessa cosa di Ufo...e non so neppure come ho fatto!!!
:cry: :cry: :cry: :cry: :cry:
Non so se è la stessa cosa di Ufo...e non so neppure come ho fatto!!!
:cry: :cry: :cry: :cry: :cry:
Come non lo sai... Azz... Altro bug sembrerebbe...
public void testNotThrowingConcurrentModificationException()
{
try
{
insert2x2BlockOfGems(GemType.EMERALD, 12, 3);
insert2x2BlockOfGems(GemType.EMERALD, 12, 5);
insert2x2BlockOfGems(GemType.EMERALD, 10, 3);
insert2x2BlockOfGems(GemType.EMERALD, 10, 5);
grid.updateBigGems();
}
catch(ConcurrentModificationException exc)
{
fail("ConcurrentModificationException thrown");
}
}
Questo è il codice che lancia l'eccezione
Non so se è la stessa cosa di Ufo...e non so neppure come ho fatto!!!
:cry: :cry: :cry: :cry: :cry: @Ufo13: :confused: non riesco a riprodurre il tuo errore, a me funziona tutto regolarmente... :confused: prova a fare un refresh da eclipse...
@Bonfo: no, non credo sia la stessa cosa che diceva Ufo, comunque penso che la situazione che tu hai creato sia perfettamente normale: il merge non avviene in quel caso perché il gioco si è fermato: l'ultima gemma rossa (quella che sta in alto a destra nell'agglomerato non formato) se non erro fa parte della coppia che non è riuscita più a scendere e che ha causato il game over... ho indovinato?
se non erro fa parte della coppia che non è riuscita più a scendere e che ha causato il game over... ho indovinato?
Purtroppo non è così...l'ultima gemma che ho aggiunto è quella in alto a sinistra e quando è capitato non ero ancora in Game Over... :cry: :cry:
71104 prova con il mio test :)
Purtroppo non è così...l'ultima gemma che ho aggiunto è quella in alto a sinistra e quando è capitato non ero ancora in Game Over... :cry: :cry: hum, un bel guaio non sapere come hai fatto ad arrivare a quella situazione...
71104 prova con il mio test :) fallisce... mi incuriosisce, provo a fare il debug...
fallisce... mi incuriosisce, provo a fare il debug... lolz, credo di aver capito... :p
a quanto pare è un problema banalissimo...
problema risolto :)
grazie Ufo13 per aver fatto il test, ma prima di committare verifico che non ci siano effetti collaterali.
la volete sapere una cosa stranissima? :confused:
temo si tratti di un problema della JVM, gli ingredienti per un bug report alla Sun ci stanno tutti...
il problema è stato corretto con quello che sembra più che altro un workaround, perché quando ho provato a vedere se le modifiche al codice avevano avuto effetti collaterali, mi sono accorto che l'ipotesi che mi ero fatto sul possibile bug era in realtà infondata e non riesco in nessuna maniera a spiegarmi altrimenti il problema, senza contare che poco dopo eseguendo JUnit i test mi si interrompono e sulla console leggo una access violation della JVM...
mah, comunque ora il problema è risolto con un test e un workaround, buona notte a tutti e speriamo che domani fek non mi cazzia troppo ^^'
o almeno prima di cazziarmi mi fornisca una spiegazione al problema che non sia dovuta alla JVM e che si possa quindi risolvere con codice pulito :Prrr:
ma in tutta franchezza un'eccezione che parla di concorrenza in un programma che usa un solo thread, la vedo proprio come un bug della JVM... :D
ottimo ma cosa hai fatto? :p
ah... hai cambiato da foreach a for :D
In realtà non so se è un vero e proprio bug della JVM...
I metodi merge, quando vanno a termine, eliminano un elemento dall'ArrayList che viene utilizzata nel foreach... Probabilmente viene considerato accesso concorrente in quanto il foreach non è terminato e grid cerca di eliminare uno degli elementi su cui il foreach sta iterando...
Non mi viene altra spiegazione in mente :)
Oltre a quello risolto da 71104 col workaround sono rimasti altri bug per i gemmoni?
Non so se è la stessa cosa di Ufo...e non so neppure come ho fatto!!!
:cry: :cry: :cry: :cry: :cry:
Rimarrebbe solo questo ma.... Non è ancora stato riprodotto a quanto pare...
In realtà non so se è un vero e proprio bug della JVM...
I metodi merge, quando vanno a termine, eliminano un elemento dall'ArrayList che viene utilizzata nel foreach... Probabilmente viene considerato accesso concorrente in quanto il foreach non è terminato e grid cerca di eliminare uno degli elementi su cui il foreach sta iterando...
Non mi viene altra spiegazione in mente :) era precisamente l'ipotesi che mi ero fatto io e il motivo percui ho sostituito il for al foreach, ma poi ho scoperto essee un'ipotesi infondata, te l'assicuro.
Ho cercato su dei forum... Hanno avuto lo stesso problema... Cancellazione di elementi in un foreach e dava quell'eccezione :)
Già...è sicuramente quello. Il foreach usa per fdorza un iterator che mantiene l'uso dell'ArrayList, quindi se si opera su un elemtno dell'ArrayList si fa un bel conflittone. ;)
Ho cercato su dei forum... Hanno avuto lo stesso problema... Cancellazione di elementi in un foreach e dava quell'eccezione :) e il crash come lo spieghi? e come spieghi che in questo codice
for (int i = 0; i < bigGems.size(); i++)
{
BigGem bigGem = bigGems.get(i);
bigGem.mergeUp(this);
bigGem.mergeRight(this);
if (bigGems.get(i) != bigGem)
{
i--;
}
}
mettendo un breakpoint su "i--;" il debugger non si fermava mai? :Prrr:
te lo sei spiegato da solo...
se cancelli una gemma su cui hai già iterato l'indice della gemma corrente viene decrementato di 1. Quindi nel if stai testando la gemma successiva (ovviamente diversa o nulla). Una volta uscito dall'if...
Beh la storia si ripete i viene incrementato e poi da te decrementato all'infinito...
problema:
la classe GemType non è testata!!!
te lo sei spiegato da solo...
se cancelli una gemma su cui hai già iterato l'indice della gemma corrente viene decrementato di 1. Quindi nel if stai testando la gemma successiva (ovviamente diversa o nulla). Una volta uscito dall'if...
Beh la storia si ripete i viene incrementato e poi da te decrementato all'infinito... no, non hai capito, non parlavo del crash del nostro programma, parla del crash della JVM! :sofico:
e comunque sia prima di far crashare il programma il debugger avrebbe dovuto raggiungere il breakpoint... no?
infatti non capisco quello che vuoi dire... Io sono convinto che la jvm va bene... Comunque il problema è risolto e va bene così :)
In BagOfGems questi due metodi sono praticamente replicati
createMapOfGemsWithoutBonus();
createMapOfGemsWithBonus();
... è fatto si proposito o si può fattorizzare un metodo comune??
Ho il bug e so come lo ho fatto :D :D
Calma..ora spiego. Cercate di concentrarvi.
Inizio (G è il gemmone giallo, X gemme casuali, R gemma rossa in basso a sinistra)
RX
GGXX
GGXX
Arriva una coppia CR (Chest_giallo e gemma_rossa)
CRRX
GGXX
GGXX
Arriva una coppia CR (Chest_giallo e gemma_rossa)
CR
CRRX
GGXX
GGXX
Arriva una coppia CR (Chest_rosso e gemma_rossa)
BBC
CRR
CRRX
GGXX
GGXX
(BB sta per BLANK...ovvero vuoto...altrimenti non viene formattata bene la griglia)
L'agglomerato non si forma...ho aggiunto pure un altra coppia prima di rendermene conto ;)
Ora sono soddisfatto e posso andare a letto felice :D :ronf:
grandissimo bonfo!! :)
bene, ora cerco di riprodurlo da me e di risolverlo ;)
sai una cosa? mentre provavo a rifare quello che dici tu ho sbagliato e non è venuto, e allora ho lasciato perdere e mi sono messo a giocherellare (questo giochino inizia ad essere maledettamente divertente :D) e giocherellando sono riuscito a riprodurre il bug in un'altra maniera!! :fagiano:
la maniera che hai descritto tu non è la più semplice, devo riuscire a trovare le condizioni minimali necessarie a far verificare l'errore :mbe:
fiuuu, è stata una dura lotta ma ce l'ho fatta ^^
public void testBugDiscoveredByBonfo()
{
insert2x2BlockOfGems(EMERALD, 12, 0);
insert2x2BlockOfGems(RUBY, 12, 2);
insertAndUpdate(Gem.create(TOPAZ, 3500), 11, 1);
insertAndUpdate(Gem.create(TOPAZ, 3500), 11, 2);
insertAndUpdate(Gem.create(TOPAZ, 3500), 10, 1);
insertAndUpdate(Gem.create(TOPAZ_CHEST, 3500), 11, 0);
insertAndUpdate(Gem.create(TOPAZ_CHEST, 3500), 10, 0);
grid.insertGem(10, 2, Gem.create(TOPAZ, 3500));
grid.insertGem(9, 2, Gem.create(TOPAZ_CHEST, 3500));
grid.updateBigGems();
assertEquals(3, grid.numberOfBigGems());
}
dopo pranzo cerco di correggerlo; Bonfo, puoi controllarmelo e verificare anche tu che l'abbia fatto bene?
come non detto, quel test non va bene: fallisce solo perché le due gemme finali non sono dropped :cry:
lo devo rifare
Hmmmm pensavo l'altro giorno poi mi son dimenticato di postare...
L'unica che lavora ancora in float è Point... E' ragionevole cambiarla in Int?
L'unica che lavora ancora in float è Point... E' ragionevole cambiarla in Int? mah, secondo me a questo punto no... fosse stato prima si, ma adesso perché mai cambiare qualcosa che funziona rischiando di introdurre errori?
Ho letto adesso...addirittura un test col mio nome!! :sofico:
Non esageriamo! :asd:
Allora...il task 9.1.2 è finito...ma non va come dovrebbe. :cry:
Secondo me si gioca tutto su dove viene invocato il metodo updateCrushes().
public void update(TimerInterface timer)
{
gemsPair.update(timer);
if(!waitState)
{
if(oneGemIsNotFalling())
{
grid.setStrongestGravity();
}
else if(bothGemsAreNotFalling())
{
grid.setNormalGravity();
grid.updateCrushes();
initializeWaitState(timer);
}
}
if(waitState)
{
handleWaitState(timer);
}
grid.updateBigGems();
grid.updateGemAnimations(timer);
}
secondo me andrebbe nello stesso posto di updateBigGems() e non all'interno dell'if.
Che ne pensate...Ufo qualche idea??
Dopo le ultime modifiche ricevo spesso questo errore.
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# SIGSEGV (0xb) at pc=0xb7e94b0e, pid=12391, tid=3085100736
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing)
# Problematic frame:
# C [libc.so.6+0x65b0e]
#
# An error report file with more information is saved as hs_err_pid12391.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
C'è decisamente qualcosa che non va nel codice perché riuscire a far andare in segmentation fault la jvm stessa è grave.
ciao ;)
Forse ho risolto il problema del crash. Ho riscritto il ciclo con un foreach e liberato l'array list solo alla fine del ciclo. Ora non esplode più.
ciao ;)
Bonfo non so a cosa ti riferisci... Ho fixato 2 bug stanotte fammi sapere se era uno di quelli.
Boh....io sono rimasto a come l'avevamo lasciato io e te.
Poi quando sono tornato ho cercato di capire...ma cotto com'ero mi è venuto in mente solo quello e poi il sonno ha vinto.
Dopo che hai fixato non ho ancora giocato. Ora provo e poi ti dico ;)
Raga...l'ho provato e mi sembra che funzioni alla grande...questa storia era difficile, davvero complimenti !!!
Probabilmente è un bug introdotto con gli ultimi refactoring...spesso le gemme quando si sono divise (o cadono dopo una cancellazione) non arrivano ad occupare l'intera casella di destinazione, ma si fermano prima... Non sono riuscito a riprodurre esattamente il bug...
Ecco la prova di quello che dice cionci.
testUpdateOnWaitingState fallisce a random...
Magari non è stato usato il mock per il random e quindi scende una coppia gemma+trunk dello stesso tipo?
Magari non è stato usato il mock per il random e quindi scende una coppia gemma+trunk dello stesso tipo?
Questo potrebbe essere un problema per tutti i test che non usano il MockGemGenerator... Sicuramente è qualcosa che va "aggiustato" nella createForTesting di GridController... Ora provo...
Ho modificato GridController.createForTesting in questo modo:
public static GridController createForTesting(MockTimer timer)
{
GridController gridController = create(Config.createForTesting(),
Input.createForTesting(timer));
gridController.gemGenerator = new MockGemGenerator();
return gridController;
}
Non è bastato...continua a fallire in modo random...quindi il problema non è figlio solo della sequenza di gemme, visto che ora quelle generate casualmente dal gridController sono tutte uguali...
Sinceramente non capisco nemmeno bene cosa voglia testare quel test ;)
Penso sia del task 9.1.3... quello della gravità sulle gemme dopo l'eliminazione
cionci, la tua modifica non è bastata a risolvere il problema del random perchè la prima gemsPair viene creata nel costruttore di GridController, quindi quando sostituisci il gemGenerator di GridController con il Mock, una gemsPair è stata già creata..adesso ho modificato il metodo come l'avevo fatto io la prima volte che si era presentato il problema, sono consapevole che si introduce una duplicazione, ma non saprei come elimarla al momento
Il nome del test effettivamente non ne chiarisce la funzione, che sarebbe quella di testare l'inserimento di updateFalls in update di GridController, quindi l'ho modificato;)
Ah...ho capito...
La modifica non l'avevo messa sul repository ;)
dato che checkstyle non perdona, ho eliminato la duplicazione, per il bug che hanno segnalato cionci e Bonfo, il test che testa queste situazioni passa, strano....
Qualcuno mi ha anticipato con l'eliminazione della duplicazione :D
cisc ricorda di lanciare sempre ant prima di committare che si rompe la build :)
il test che testa queste situazioni passa, strano....
Prova a giocare... Si verifica spesso, ma non sempre... Sembra quasi che la gemma "perda" la gravità prima che venga a contatto con il bordo inferiore della cella...
Ho committato il test per la estensione verso il basso delle BigGem... Ora manca solo quel bug credo...
Prova a giocare... Si verifica spesso, ma non sempre... Sembra quasi che la gemma "perda" la gravità prima che venga a contatto con il bordo inferiore della cella...
ho notato anche io... ed alla distruzione successiva tendono a sistemarsi... Sembra che la gravità venga tolta troppo "presto" in certi casi...
Ad esempio mi è capitato sempre quando dopo una distruzione una gemma cadeva di 1 casella ed una serie di altre gemme cadeva di 3...
ho notato anche io... ed alla distruzione successiva tendono a sistemarsi... Sembra che la gravità venga tolta troppo "presto" in certi casi...
Ad esempio mi è capitato sempre quando dopo una distruzione una gemma cadeva di 1 casella ed una serie di altre gemme cadeva di 3...
Aggiungo pure che non solo ci vuole la distruzione successiva ma ci vuole anche che le gemme vengano "smosse" da quella distruzione altrimenti rimangono così.
Aggiungo pure che non solo ci vuole la distruzione successiva ma ci vuole anche che le gemme vengano "smosse" da quella distruzione altrimenti rimangono così.
Confermo...l'ho visto anche io...
ho fatto il test e dovrei aver risolto il bug
il metodo secondo me va spezzato... In teoria dal nome deve restituire un booleano e non eseguire pure operazioni (alignGemToCellUpperBound per esempio)...
Per questo il bug non è stato immediato da trovare...
sono d'accordo, si dovrebbe usare un metodo canMoveGemDown che restituisca true anche quando la gemma non ha raggiunto completamente il fondo, oppure chiamare updateFalls in gridController indistintamente dal valore restituito da droppedGemCanMoveDown, adesso io devo proprio scappare all'uni, quindi non ho tempo per rifattorizzare....
il metodo secondo me va spezzato... In teoria dal nome deve restituire un booleano e non eseguire pure operazioni (alignGemToCellUpperBound per esempio)...
Per questo il bug non è stato immediato da trovare...
cmq, l'operazione alignGemToCellUpperBound l'ho aggiunta per risolvere il bug, altrimenti il metodo è nato solo per restituire una boolean, quindi non centra niente con la difficoltà di risolvere il bug, semplicemente il test che doveva verificare quella situazione non funzionava bene, quindi durante un refactoring è stato introdotto senza che potesse essere notato lanciando i test
Bug...forse non nuovo...
La gemmona si è formata dopo la cancellazione di altre gemme...
Ecco la prova di quello che dice cionci.
Non so se era già stato corretto, ma a me si verifica ancora...
Basta avere un chest e poi una gemma di colore diverso dal chest nel pair...
Se si emtte il chest nella parte bassa e si va a farlo collidere con una gemma dello stesso colore, dopo la cancellazione la gemma sopra rimane rialzata di qualche pixel...
Non so se era già stato corretto, ma a me si verifica ancora...
Basta avere un chest e poi una gemma di colore diverso dal chest nel pair...
Se si emtte il chest nella parte bassa e si va a farlo collidere con una gemma dello stesso colore, dopo la cancellazione la gemma sopra rimane rialzata di qualche pixel...
A me questo bug non è mai capitato, nemmeno riproducendo la sequenza che hai descritto (ho una build del 4 febbraio).
Allora può darsi che sia stato reintrodotto più tardi...io ora lo ottengo sistematicamente...
Confermo, mi succede sempre quando c'è una cancellazione con la Gemspair in verticale e la gemma sopra non viene cancellata...
Volevo porre questo quesito, visto che non mi sembra il caso di parlarne nell'altro thread:
Ho in mente di fare una modifica anche all'aggiornamento dei timestamp....
Vi spiego, ora, praticamente da ogni parte, funzina così:
if(nuovoTimeStamp > vecchioTimeStamp + X)
{
vecchioTimeStamp = nuovoTimeStamp;
faiAzione();
}
Secondo me va SEMPRE trasformato in questo modo:
if(nuovoTimeStamp >= vecchioTimeStamp + X)
{
vecchioTimeStamp += X;
faiAzione();
}
Il primo metodo va benissimo in locale, quando i ritardi sono minimi, ma il secondo, oltre ad andare bene in locale va bene anche per la griglia secondaria...che in questo modo non si perderebbe mai una "azione"...
inoltre sarebbe compatibile con l'aumento/diminuzione dello sfasamento del timer...
Cosa ne pensate ?
Non so se era già stato corretto, ma a me si verifica ancora...
Basta avere un chest e poi una gemma di colore diverso dal chest nel pair...
Se si emtte il chest nella parte bassa e si va a farlo collidere con una gemma dello stesso colore, dopo la cancellazione la gemma sopra rimane rialzata di qualche pixel...
ti si verifica solo in questo specifico caso?
per il timestamp sono d'accordo con la modifica
Sicuramente in quel caso si verifica sempre... Ho notato anche che si verifica in altri casi purtroppo... Boh...
^TiGeRShArK^
09-02-2006, 20:07
ecco.. pure a me è capitato lo stesso bug di cionci immagino...
qui c'è lo screen:
http://img229.imageshack.us/img229/9302/bug8uo.png
[javac] 3 errors
BUILD FAILED
Non è bello :(
[javac] 3 errors
BUILD FAILED
Non è bello :(
Sistemato.
ciao ;)
Ho nuovamente la connessione a casa, una fiammante DSL 2mbit. Sto risistemando il server e la build machine.
Bear with me another bit.
Per il resto seguo lo sviluppo a spizzichi e bocconi, e mi faccio aggiornare da Andrea e Vicius quando possibile. Ma ancora non sono riuscito a guardare l'ultima versione del codice. Questo Ciclo 10 mi vedra' coinvolto ancora meno purtroppo. La prossima settimana sono via sballottato fra Londra, Spagna e Italia e torno all'inizio del prossimo ciclo.
Non sono affatto preoccupato perche' vedo che lo sviluppo procede molto bene. Passato questo periodo di fuoco, torno a spezzarvi le ditine.
La build machine e' tornata su al solito indirizzo:
http:\\fcarucci.homeip.net:8080\cruisecontrol
DanieleC88
12-02-2006, 10:53
La build machine e' tornata su al solito indirizzo:
http:\\fcarucci.homeip.net:8080\cruisecontrol
Che sono quei backslash in stile Win32? Forza, mettiamo gli slash in stile Unix. :D
C'è un bug derivato dall'inizializzazione a 0 dei timestamp e dal nuovo modello di aggiornamento dei timestamp... In pratica all'inizio del gioco c'è un "salto"...
Faccio test e correzione...
Ho risolto, ma per fare in modo che entrambi i playField venissero inizializzati con lo stesso timeStamp ho dovuto aggiungere un metodo... Non mi piace molto...ma inserirlo nel costruttore è una duplicazione...
cionci attento, ho appena commitato e nn vorrei averti mangiato la tua modifica(ho fatto sync, pero nn si sa mai che siano stati contemporanei).
brutto bug:(
provate a roteare in fretta la gemma, ogni tanto(a random proprio), le 2 gemme si droppano e cadono giu da sole a gravita alta come se si fossero divise.
Ho fatto una prova con la codebase precedente al commit sull'input dei 2 giocatori, e il problema c'era gia.
Ho visto ora questo bug... Si verifica molto frequentemente... Chissà quando è stato inserito...non mi sembrava di averlo mai visto...
Altro piccolo bug... le gemme cadono un pixel troppo in basso... prima non succedeva :eek:
Questo può essere anche un semplice errore di allineamento della griglia... Mi dai le posizioni esatte di entrambe le griglie ?
Piccolo errore mio...magari creava anche tutti gli altri problemi... Ora provo...
Sì...eliminato anche l'altro bug !!! :sofico:
ecco.. pure a me è capitato lo stesso bug di cionci immagino...
qui c'è lo screen:
http://img229.imageshack.us/img229/9302/bug8uo.png
dovrei aver risolto questo bug, scusate l'assenza, ma sono stato incasinato da impegni e progetti vari, ora grdd necessiterebbe un refactoring per eliminare delle duplicazioni e delle ambiguità, tipo i metodi gemCantMoveDown, e gemCanMoveDown, che non sono esattamente l'uno la negazioni dell'altro, se trovo il tempo provo a farlo io, ma oltre ai problemi di tempoho problemi con java e l'aggiornamento della mia debian che ha incasinato qualcosa, non posso assicurare niente :(
^TiGeRShArK^
19-02-2006, 00:25
ma è normale ke oltre a non passarmi il checkstyle, forzando la compilazione mi dia questi errori???:confused:
compile-debug:
[javac] Compiling 125 source files to C:\Diamonds\trunk\bin\debug
[javac] C:\Diamonds\trunk\src\it\diamonds\tests\TestBigGemInGrid.java:609: c
annot find symbol
[javac] symbol : method createP1(it.diamonds.engine.Config,<nulltype>,it.di
amonds.engine.RandomGenerator)
[javac] location: class it.diamonds.GridController
[javac] GridController gridController = GridController.createP1(conf
ig,
[javac] ^
[javac] C:\Diamonds\trunk\src\it\diamonds\tests\TestGemsPairBase.java:67: ca
nnot find symbol
[javac] symbol : method createP1(it.diamonds.engine.Config,it.diamonds.engi
ne.input.Input,it.diamonds.engine.RandomGenerator)
[javac] location: class it.diamonds.GridController
[javac] gridController = GridController.createP1(config, input, new
RandomGenerator());
[javac] ^
[javac] 2 errors
ma è normale ke oltre a non passarmi il checkstyle, forzando la compilazione mi dia questi errori???:confused:
compile-debug:
[javac] Compiling 125 source files to C:\Diamonds\trunk\bin\debug
[javac] C:\Diamonds\trunk\src\it\diamonds\tests\TestBigGemInGrid.java:609: c
annot find symbol
[javac] symbol : method createP1(it.diamonds.engine.Config,<nulltype>,it.di
amonds.engine.RandomGenerator)
[javac] location: class it.diamonds.GridController
[javac] GridController gridController = GridController.createP1(conf
ig,
[javac] ^
[javac] C:\Diamonds\trunk\src\it\diamonds\tests\TestGemsPairBase.java:67: ca
nnot find symbol
[javac] symbol : method createP1(it.diamonds.engine.Config,it.diamonds.engi
ne.input.Input,it.diamonds.engine.RandomGenerator)
[javac] location: class it.diamonds.GridController
[javac] gridController = GridController.createP1(config, input, new
RandomGenerator());
[javac] ^
[javac] 2 errors
Qui funziona tutto perfettamente. Prova a fare un nuovo checkout dal repository.
ciao ;)
È già un po' di tempo che ho notato questi difetti ma ora stanno diventando veramente fastidiosi.
Il primo problema è anche il più grave. La VM di Java continua ad andare in segfault in istanti completamente random. La funzione che da problemi è glBegin si Engine.drawQuad(). Questo è il log:
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# SIGSEGV (0xb) at pc=0xb0d8c2d1, pid=8704, tid=3085166272
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing)
# Problematic frame:
# C [libGLcore.so.1+0x37b2d1]
#
--------------- T H R E A D ---------------
Current thread (0x0805cb98): JavaThread "main" [_thread_in_native, id=8704]
siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00010000
Registers:
EAX=0x00010000, EBX=0x08452320, ECX=0x0000335c, EDX=0x00002400
ESP=0xbffb87b4, EBP=0x00000000, ESI=0x00000000, EDI=0x0844eb28
EIP=0xb0d8c2d1, CR2=0x00010000, EFLAGS=0x00210202
Top of Stack: (sp=0xbffb87b4)
0xbffb87b4: b063c000 b063c000 00002400 00ffffff
0xbffb87c4: 00000000 083e7660 0000335c 00000000
0xbffb87d4: 00000000 00000001 b065a74c b0ec1c7c
0xbffb87e4: b0e9c999 b063c000 b063c000 b063c000
0xbffb87f4: 00002400 00ffffff 00002400 00ffffff
0xbffb8804: b0e83f6d b063c000 b063c000 00000004
0xbffb8814: 00000004 00ffffff 00000004 00ffffff
0xbffb8824: 00000001 b065a74c b063c000 00000004
Instructions: (pc=0xb0d8c2d1)
0xb0d8c2c1: 03 85 c0 74 32 8b 40 38 8b 4c 24 18 8b 74 24 1c
0xb0d8c2d1: 89 0c b0 8b 03 66 ff 48 32 8b 03 66 ff 48 08 8b
Stack: [0xbfdbc000,0xbffbc000), sp=0xbffb87b4, free space=2033k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libGLcore.so.1+0x37b2d1]
[error occurred during error reporting, step 120, id 0xb]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J org.lwjgl.opengl.GL11.nglBegin(IJ)V
J it.diamonds.engine.Engine.drawQuad(Lit/diamonds/engine/Point;FFLit/diamonds/engine/video/Texture;Lit/diamonds/engine/Rectangle;)V
J it.diamonds.engine.video.Sprite.draw(Lit/diamonds/engine/EngineInterface;)V
J it.diamonds.Grid.draw(Lit/diamonds/engine/EngineInterface;)V
J it.diamonds.engine.video.LayerManager.drawLayers(Lit/diamonds/engine/EngineInterface;)V
J it.diamonds.GameLoop.render()V
J it.diamonds.GameLoop.loop()V
v ~OSRAdapter
[error occurred during error reporting, step 130, id 0xb]
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x083cc770 JavaThread "AWT-XAWT" daemon [_thread_in_native, id=8717]
0x08337008 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=8716]
0x080a3c18 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=8714]
0x080a26b8 JavaThread "CompilerThread0" daemon [_thread_blocked, id=8713]
0x080a17b0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=8712]
0x0809ab80 JavaThread "Finalizer" daemon [_thread_blocked, id=8711]
0x08099e38 JavaThread "Reference Handler" daemon [_thread_blocked, id=8710]
=>0x0805cb98 JavaThread "main" [_thread_in_native, id=8704]
Other Threads:
0x08097320
[error occurred during error reporting, step 170, id 0xb]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
def new generation total 576K, used 60K [0x88a70000, 0x88b10000, 0x88f50000)
eden space 512K, 10% used [0x88a70000, 0x88a7d650, 0x88af0000)
from space 64K, 10% used [0x88af0000, 0x88af1a38, 0x88b00000)
to space 64K, 0% used [0x88b00000, 0x88b00000, 0x88b10000)
tenured generation total 1408K, used 483K [0x88f50000, 0x890b0000, 0x8ca70000)
the space 1408K, 34% used [0x88f50000, 0x88fc8f20, 0x88fc9000, 0x890b0000)
compacting perm gen total 8192K, used 1019K [0x8ca70000, 0x8d270000, 0x90a70000)
the space 8192K, 12% used [0x8ca70000, 0x8cb6ef48, 0x8cb6f000, 0x8d270000)
ro space 8192K, 68% used [0x90a70000, 0x90fec408, 0x90fec600, 0x91270000)
rw space 12288K, 48% used [0x91270000, 0x91833a30, 0x91833c00, 0x91e70000)
Dynamic libraries:
08048000-08057000 r-xp 00000000 03:01 596757 /usr/lib/j2sdk1.5-sun/bin/java
08057000-08059000 rwxp 0000e000 03:01 596757 /usr/lib/j2sdk1.5-sun/bin/java
08059000-096e7000 rwxp 08059000 00:00 0 [heap]
88a70000-88b10000 rwxp 88a70000 00:00 0
88b10000-88f50000 rwxp 88b10000 00:00 0
88f50000-890b0000 rwxp 88f50000 00:00 0
890b0000-8ca70000 rwxp 890b0000 00:00 0
8ca70000-8d270000 rwxp 8ca70000 00:00 0
8d270000-90a70000 rwxp 8d270000 00:00 0
90a70000-90fed000 r-xs 00001000 03:01 581352 /usr/lib/j2sdk1.5-sun/jre/lib/i386/client/classes.jsa
90fed000-91270000 rwxp 90fed000 00:00 0
91270000-91834000 rwxp 0057e000 03:01 581352 /usr/lib/j2sdk1.5-sun/jre/lib/i386/client/classes.jsa
91834000-91e70000 rwxp 91834000 00:00 0
91e70000-91f3f000 rwxp 00b42000 03:01 581352 /usr/lib/j2sdk1.5-sun/jre/lib/i386/client/classes.jsa
91f3f000-92270000 rwxp 91f3f000 00:00 0
92270000-92274000 r-xs 00c11000 03:01 581352 /usr/lib/j2sdk1.5-sun/jre/lib/i386/client/classes.jsa
92274000-92670000 rwxp 92274000 00:00 0
af286000-af9c9000 rwxp af286000 00:00 0
af9ff000-afb01000 rwxp af9ff000 00:00 0
afb01000-afb21000 rwxs 00000000 00:07 1711308802 /SYSV0056a4d6 (deleted)
afb21000-afb31000 rwxs 00000000 00:0c 10195 /dev/snd/pcmC0D0p
afb31000-afb32000 rwxs 81000000 00:0c 10195 /dev/snd/pcmC0D0p
afb32000-afb33000 r-xs 80000000 00:0c 10195 /dev/snd/pcmC0D0p
afb33000-afb34000 rwxs 00000000 00:07 1711276033 /SYSV0056a4d5 (deleted)
afb34000-afba6000 rwxp afb34000 00:00 0
afbd8000-afc9a000 rwxp afbd8000 00:00 0
afc9a000-afcba000 rwxs 00000000 00:07 1711308802 /SYSV0056a4d6 (deleted)
afcba000-afcca000 rwxs 00000000 00:0c 10195 /dev/snd/pcmC0D0p
afcca000-afcf4000 r-xp 00000000 03:01 374672 /usr/lib/liblcms.so.1.0.13
afcf4000-afcf6000 rwxp 0002a000 03:01 374672 /usr/lib/liblcms.so.1.0.13
afcf6000-afcf8000 rwxp afcf6000 00:00 0
afcf8000-afd0b000 r-xp 00000000 03:01 374317 /usr/lib/libz.so.1.2.3
afd0b000-afd0c000 rwxp 00012000 03:01 374317 /usr/lib/libz.so.1.2.3
afd0c000-afd6e000 r-xp 00000000 03:01 374674 /usr/lib/libmng.so.1.0.0
afd6e000-afd71000 rwxp 00061000 03:01 374674 /usr/lib/libmng.so.1.0.0
afd71000-afdc2000 r-xp 00000000 03:01 383930 /usr/lib/libtiff.so.4.2.0
afdc2000-afdc5000 rwxp 00050000 03:01 383930 /usr/lib/libtiff.so.4.2.0
afdc5000-afde4000 r-xp 00000000 03:01 374670 /usr/lib/libjpeg.so.62.0.0
afde4000-afde5000 rwxp 0001f000 03:01 374670 /usr/lib/libjpeg.so.62.0.0
afde5000-afe09000 r-xp 00000000 03:01 374404 /usr/lib/libpng12.so.0.1.2.8
afe09000-afe0a000 rwxp 00023000 03:01 374404 /usr/lib/libpng12.so.0.1.2.8
afe0b000-afe20000 r-xp 00000000 03:06 6209652 /home/mirco/workspace/Diamonds/lib/linux/libILU.so
afe20000-afe21000 rwxp 00014000 03:06 6209652 /home/mirco/workspace/Diamonds/lib/linux/libILU.so
afe21000-afe6f000 r-xp 00000000 03:06 6209659 /home/mirco/workspace/Diamonds/lib/linux/libIL.so
afe6f000-afe71000 rwxp 0004d000 03:06 6209659 /home/mirco/workspace/Diamonds/lib/linux/libIL.so
afe71000-aff24000 rwxp afe71000 00:00 0
aff24000-aff2c000 r-xp 00000000 03:06 6209656 /home/mirco/workspace/Diamonds/lib/linux/liblwjgl-devil.so
aff2c000-aff2d000 rwxp 00008000 03:06 6209656 /home/mirco/workspace/Diamonds/lib/linux/liblwjgl-devil.so
aff2d000-aff2e000 rwxp aff2d000 00:00 0
aff2e000-aff49000 r-xp 00000000 03:01 500285 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
aff49000-aff4b000 rwxp 0001b000 03:01 500285 /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
aff4b000-aff4d000 rwxp 00000000 00:0c 2097 /dev/zero
aff4d000-aff4f000 rwxp 00000000 00:0c 2097 /dev/zero
aff4f000-aff51000 rwxp 00000000 00:0c 2097 /dev/zero
aff51000-aff53000 rwxp 00000000 00:0c 2097 /dev/zero
aff53000-aff55000 rwxp 00000000 00:0c 2097 /dev/zero
aff55000-aff57000 rwxp 00000000 00:0c 2097 /dev/zero
aff57000-aff59000 rwxp 00000000 00:0c 2097 /dev/zero
aff59000-aff5b000 rwxp 00000000 00:0c 2097 /dev/zero
aff5b000-aff5d000 rwxp 00000000 00:0c 2097 /dev/zero
aff5d000-aff5f000 rwxp 00000000 00:0c 2097 /dev/zero
aff5f000-aff60000 rwxs 00000000 00:07 572915730 /SYSV00000000 (deleted)
aff60000-aff61000 rwxs 00000000 00:07 572882958 /SYSV00000000 (deleted)
aff61000-b0061000 rwxs e0112000 00:0c 12544 /dev/nvidia0
b0061000-b04e3000 rwxp b0061000 00:00 0
b04e3000-b04e4000 rwxs dfbca000 00:0c 12544 /dev/nvidia0
b04e4000-b04e5000 rwxs 09d1c000 00:0c 12544 /dev/nvidia0
b04e5000-b04e9000 rwxs 1b8e7000 00:0c 12544 /dev/nvidia0
b04e9000-b04f9000 rwxs dfbcb000 00:0c 12544 /dev/nvidia0
b04f9000-b05fb000 rwxs e0010000 00:0c 12544 /dev/nvidia0
b05fb000-b063c000 rwxp b05fb000 00:00 0
b063c000-b069b000 rwxp 00000000 00:0c 2097 /dev/zero
b069b000-b099b000 rwxs d0000000 00:0c 12544 /dev/nvidia0
b099b000-b09b2000 rwxs 00000000 00:07 1677852672 /SYSV00000000 (deleted)
b09b2000-b0a0f000 rwxp b09b2000 00:00 0
b0a0f000-b0a10000 r-xp 00000000 03:01 537021 /usr/lib/nvidia/libnvidia-tls.so.1.0.8178
b0a10000-b0a11000 rwxp 00000000 03:01 537021 /usr/lib/nvidia/libnvidia-tls.so.1.0.8178
b0a11000-b1198000 r-xp 00000000 03:01 381482 /usr/lib/libGLcore.so.1.0.8178
b1198000-b11cb000 rwxp 00786000 03:01 381482 /usr/lib/libGLcore.so.1.0.8178
b11cb000-b11cf000 rwxp b11cb000 00:00 0
b11cf000-b1238000 r-xp 00000000 03:01 381481 /usr/lib/libGL.so.1.0.8178
b1238000-b1251000 rwxp 00069000 03:01 381481 /usr/lib/libGL.so.1.0.8178
b1251000-b1252000 rwxp b1251000 00:00 0
b1252000-b1253000 ---p b1252000 00:00 0
b1253000-b1a53000 rwxp b1253000 00:00 0
b1a53000-b1b01000 r-xp 00000000 03:01 373117 /usr/lib/libasound.so.2.0.0
b1b01000-b1b06000 rwxp 000ae000 03:01 373117 /usr/lib/libasound.so.2.0.0
b1b06000-b1b07000 rwxs 81000000 00:0c 10195 /dev/snd/pcmC0D0p
b1b07000-b1b08000 r-xs 80000000 00:0c 10195 /dev/snd/pcmC0D0p
b1b08000-b1b09000 rwxs 00000000 00:07 1711276033 /SYSV0056a4d5 (deleted)
b1b09000-b1b0a000 rwxs 1a007000 00:0c 12544 /dev/nvidia0
b1b0a000-b1b0b000 rwxs e4001000 00:0c 12544 /dev/nvidia0
b1b0b000-b1b1b000 rwxs e4820000 00:0c 12544 /dev/nvidia0
b1b1b000-b1b1d000 rwxp 00000000 00:0c 2097 /dev/zero
b1b1d000-b1b25000 r-xp 00000000 03:06 6209654 /home/mirco/workspace/Diamonds/lib/linux/libopenal.so
b1b25000-b1b26000 rwxp 00007000 03:06 6209654 /home/mirco/workspace/Diamonds/lib/linux/libopenal.so
b1b26000-b1b59000 r-xp 00000000 03:06 6209655 /home/mirco/workspace/Diamonds/lib/linux/liblwjgl.so
b1b59000-b1b5b000 rwxp 00032000 03:06 6209655 /home/mirco/workspace/Diamonds/lib/linux/liblwjgl.so
b1b5b000-b1b5d000 rwxp b1b5b000 00:00 0
b1b5d000-b1b60000 ---p b1b5d000 00:00 0
b1b60000-b1bde000 rwxp b1b60000 00:00 0
b1bde000-b1be1000 ---p b1bde000 00:00 0
b1be1000-b1c5f000 rwxp b1be1000 00:00 0
b1c5f000-b1cd2000 r-xp 00000000 03:01 581379 /usr/lib/j2sdk1.5-sun/jre/lib/i386/libfontmanager.so
b1cd2000-b1cdc000 rwxp 00073000 03:01 581379 /usr/lib/j2sdk1.5-sun/jre/lib/i386/libfontmanager.so
b1cdc000-b1ce0000 rwxp b1cdc000 00:00 0
b1ce0000-b1da7000 r-xp 00000000 03:01 487406 /usr/X11R6/lib/libX11.so.6.2
b1da7000-b1dab000 rwxp 000c6000 03:01 487406 /usr/X11R6/lib/libX11.so.6.2
b1dab000-b1db8000 r-xp 00000000 03:01 487408 /usr/X11R6/lib/libXext.so.6.4
b1db8000-b1db9000 rwxp 0000c000 03:01 487408 /usr/X11R6/lib/libXext.so.6.4
b1db9000-b1dba000 rwxs e4001000 00:0c 12544 /dev/nvidia0
b1dba000-b1dbb000 r-xp 00000000 03:01 581385 /usr/lib/j2sdk1.5-sun/jre/lib/i386/libjawt.so
b1dbb000-b1dbc000 rwxp 00000000 03:01 581385 /usr/lib/j2sdk1.5-sun/jre/lib/i386/libjawt.so
b1dbc000-b1dc4000 r-xp 00000000 03:01 374407 /usr/lib/libXrender.so.1.3.0
b1dc4000-b1dc5000 rwxp 00007000 03:01 374407 /usr/lib/libXrender.so.1.3.0
b1dc5000-b1dcd000 r-xp 00000000 03:01 374409 /usr/lib/libXcursor.so.1.0.2
b1dcd000-b1dce000 rwxp 00007000 03:01 374409 /usr/lib/libXcursor.so.1.0.2
b1dce000-b1dcf000 r-xp 00000000 03:01 500287 /usr/X11R6/lib/X11/locale/lib/common/xlcUTF8Load.so.2
b1dcf000-b1dd0000 rwxp 00000000 03:01 500287 /usr/X11R6/lib/X11/locale/lib/common/xlcUTF8Load.so.2
b1dd0000-b1e06000 r-xp 00000000 03:01 581374 /usr/lib/j2sdk1.5-sun/jre/lib/i386/xawt/libmawt.so
b1e06000-b1e09000 rwxp 00035000 03:01 581374 /usr/lib/j2sdk1.5-sun/jre/lib/i386/xawt/libmawt.so
b1e09000-b1e0a000 rwxp b1e09000 00:00 0
b1e0a000-b1ed0000 r-xp 00000000 03:01 581369 /usr/lib/j2sdk1.5-sun/jre/lib/i386/libmlib_image.so
b1ed0000-b1ed1000 rwxp 000c5000 03:01 581369 /usr/lib/j2sdk1.5-sun/jre/lib/i386/libmlib_image.so
b1ed1000-b1f46000 r-xp 00000000 03:01 581370 /usr/lib/j2sdk1.5-sun/jre/lib/i386/libawt.so
b1f46000-b1f4c000 rwxp 00074000 03:01 581370 /usr/lib/j2sdk1.5-sun/jre/lib/i386/libawt.so
b1f4c000-b1f70000 rwxp b1f4c000 00:00 0
b1f70000-b1f8d000 r-xs 00000000 03:06 6209974 /home/mirco/workspace/Diamonds/lib/jar/lwjgl_util.jar
b1f8d000-b1f91000 r-xs 00000000 03:06 6209976 /home/mirco/workspace/Diamonds/lib/jar/lwjgl_devil.jar
b1f91000-b1fea000 r-xs 00000000 03:06 6209975 /home/mirco/workspace/Diamonds/lib/jar/lwjgl.jar
b1fea000-b1ff9000 r-xs 00000000 03:06 6209998 /home/mirco/workspace/Diamonds/lib/easymock.jar
b1ff9000-b2017000 r-xs 00000000 03:06 6209996 /home/mirco/workspace/Diamonds/lib/junit.jar
b2017000-b20db000 r-xs 00000000 03:01 581399 /usr/lib/j2sdk1.5-sun/jre/lib/ext/localedata.jar
b20db000-b2106000 r-xs 00000000 03:01 581397 /usr/lib/j2sdk1.5-sun/jre/lib/ext/sunpkcs11.jar
b2106000-b212c000 r-xs 00000000 03:01 581396 /usr/lib/j2sdk1.5-sun/jre/lib/ext/sunjce_provider.jar
b212c000-b212d000 ---p b212c000 00:00 0
b212d000-b21ad000 rwxp b212d000 00:00 0
b21ad000-b21b0000 ---p b21ad000 00:00 0
b21b0000-b222e000 rwxp b21b0000 00:00 0
b222e000-b2231000 ---p b222e000 00:00 0
b2231000-b22af000 rwxp b2231000 00:00 0
b22af000-b22b2000 ---p b22af000 00:00 0
b22b2000-b2330000 rwxp b22b2000 00:00 0
b2330000-b2450000 r-xp 00000000 03:01 387828 /usr/lib/locale/locale-archive
b2450000-b2453000 ---p b2450000 00:00 0
b2453000-b24d1000 rwxp b2453000 00:00 0
b24d1000-b24d4000 ---p b24d1000 00:00 0
b24d4000-b2552000 rwxp b24d4000 00:00 0
b2552000-b2553000 ---p b2552000 00:00 0
b2553000-b25df000 rwxp b2553000 00:00 0
b25df000-b25fb000 rwxp b25df000 00:00 0
b25fb000-b25fc000 rwxp b25fb000 00:00 0
b25fc000-b2619000 rwxp b25fc000 00:00 0
b2619000-b261a000 rwxp b2619000 00:00 0
b261a000-b261b000 rwxp b261a000 00:00 0
b261b000-b261d000 rwxp b261b000 00:00 0
b261d000-b2639000 rwxp b261d000 00:00 0
b2639000-b263d000 rwxp b2639000 00:00 0
b263d000-b2659000 rwxp b263d000 00:00 0
b2659000-b2669000 rwxp b2659000 00:00 0
b2669000-b26e4000 rwxp b2669000 00:00 0
b26e4000-b27f4000 rwxp b26e4000 00:00 0
b27f4000-b46e4000 rwxp b27f4000 00:00 0
b46e4000-b4f1f000 r-xs 00000000 03:01 581967 /usr/lib/j2sdk1.5-sun/jre/lib/charsets.jar
b4f1f000-b4f33000 r-xs 00000000 03:01 581400 /usr/lib/j2sdk1.5-sun/jre/lib/jce.jar
b4f33000-b4fb8000 r-xs 00000000 03:01 581911 /usr/lib/j2sdk1.5-sun/jre/lib/jsse.jar
b4fb8000-b5021000 rwxp b4fb8000 00:00 0
b5021000-b7609000 r-xs 00000000 03:01 581969 /usr/lib/j2sdk1.5-sun/jre/lib/rt.jar
b7609000-b761c000 r-xp 00000000 03:01 581359 /usr/lib/j2sdk1.5-sun/jre/lib/i386/libzip.so
b761c000-b761e000 rwxp 00012000 03:01 581359 /usr/lib/j2sdk1.5-sun/jre/lib/i386/libzip.so
b761e000-b763f000 r-xp 00000000 03:01 581357 /usr/lib/j2sdk1.5-sun/jre/lib/i386/libjava.so
b763f000-b7641000 rwxp 00020000 03:01 581357 /usr/lib/j2sdk1.5-sun/jre/lib/i386/libjava.so
b7641000-b764b000 r-xp 00000000 03:01 64562 /lib/tls/i686/cmov/libnss_files-2.3.6.so
b764b000-b764d000 rwxp 00009000 03:01 64562 /lib/tls/i686/cmov/libnss_files-2.3.6.so
b764d000-b7655000 r-xp 00000000 03:01 64564 /lib/tls/i686/cmov/libnss_nis-2.3.6.so
b7655000-b7657000 rwxp 00008000 03:01 64564 /lib/tls/i686/cmov/libnss_nis-2.3.6.so
b7657000-b7669000 r-xp 00000000 03:01 64537 /lib/tls/i686/cmov/libnsl-2.3.6.so
b7669000-b766b000 rwxp 00012000 03:01 64537 /lib/tls/i686/cmov/libnsl-2.3.6.so
b766b000-b766d000 rwxp b766b000 00:00 0
b766d000-b766e000 rwxs e4001000 00:0c 12544 /dev/nvidia0
b766e000-b7670000 r-xs 00000000 03:01 581398 /usr/lib/j2sdk1.5-sun/jre/lib/ext/dnsns.jar
b7670000-b767b000 r-xp 00000000 03:01 581356 /usr/lib/j2sdk1.5-sun/jre/lib/i386/libverify.so
b767b000-b767c000 rwxp 0000b000 03:01 581356 /usr/lib/j2sdk1.5-sun/jre/lib/i386/libverify.so
b767c000-b7684000 rwxs 00000000 03:01 806437 /tmp/hsperfdata_mirco/8704
b7684000-b76a8000 r-xp 00000000 03:01 64535 /lib/tls/i686/cmov/libm-2.3.6.so
b76a8000-b76aa000 rwxp 00023000 03:01 64535 /lib/tls/i686/cmov/libm-2.3.6.so
b76aa000-b7a0a000 r-xp 00000000 03:01 581350 /usr/lib/j2sdk1.5-sun/jre/lib/i386/client/libjvm.so
b7a0a000-b7a28000 rwxp 0035f000 03:01 581350 /usr/lib/j2sdk1.5-sun/jre/lib/i386/client/libjvm.so
b7a28000-b7e3f000 rwxp b7a28000 00:00 0
b7e3f000-b7f6d000 r-xp 00000000 03:01 64523 /lib/tls/i686/cmov/libc-2.3.6.so
b7f6d000-b7f72000 r-xp 0012d000 03:01 64523 /lib/tls/i686/cmov/libc-2.3.6.so
b7f72000-b7f75000 rwxp 00132000 03:01 64523 /lib/tls/i686/cmov/libc-2.3.6.so
b7f75000-b7f77000 rwxp b7f75000 00:00 0
b7f77000-b7f79000 r-xp 00000000 03:01 64534 /lib/tls/i686/cmov/libdl-2.3.6.so
b7f79000-b7f7b000 rwxp 00001000 03:01 64534 /lib/tls/i686/cmov/libdl-2.3.6.so
b7f7b000-b7f8a000 r-xp 00000000 03:01 64567 /lib/tls/i686/cmov/libpthread-2.3.6.so
b7f8a000-b7f8c000 rwxp 0000e000 03:01 64567 /lib/tls/i686/cmov/libpthread-2.3.6.so
b7f8c000-b7f94000 rwxp b7f8c000 00:00 0
b7f94000-b7f9b000 r-xp 00000000 03:01 64554 /lib/tls/i686/cmov/libnss_compat-2.3.6.so
b7f9b000-b7f9d000 rwxp 00006000 03:01 64554 /lib/tls/i686/cmov/libnss_compat-2.3.6.so
b7f9d000-b7fa3000 r-xp 00000000 03:01 581345 /usr/lib/j2sdk1.5-sun/jre/lib/i386/native_threads/libhpi.so
b7fa3000-b7fa4000 rwxp 00006000 03:01 581345 /usr/lib/j2sdk1.5-sun/jre/lib/i386/native_threads/libhpi.so
b7fa4000-b7fa5000 rwxp b7fa4000 00:00 0
b7fa5000-b7fa6000 r-xp b7fa5000 00:00 0
b7fa6000-b7fbc000 r-xp 00000000 03:01 16132 /lib/ld-2.3.6.so
b7fbc000-b7fbe000 rwxp 00015000 03:01 16132 /lib/ld-2.3.6.so
bfdbc000-bfdbf000 ---p bfdbc000 00:00 0
bfdbf000-bffbc000 rwxp bfdbf000 00:00 0 [stack]
ffffe000-fffff000 ---p 00000000 00:00 0 [vdso]
VM Arguments:
jvm_args: -Djava.library.path=lib/linux
java_command: it.diamonds.Game
Launcher Type: SUN_STANDARD
Environment Variables:
PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
LD_LIBRARY_PATH=/usr/lib/j2sdk1.5-sun/jre/lib/i386/client:/usr/lib/j2sdk1.5-sun/jre/lib/i386:/usr/lib/j2sdk1.5-sun/jre/../lib/i386:/usr/lib/mozilla
SHELL=/bin/bash
DISPLAY=:0.0
Signal Handlers:
SIGSEGV: [libjvm.so+0x31b990], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x31b990], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x281230], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: [libjvm.so+0x281230], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x281230], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x283580], sa_mask[0]=0x00000004, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x282fb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: SIG_IGN, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGQUIT: [libjvm.so+0x282fb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGTERM: [libjvm.so+0x282fb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
--------------- S Y S T E M ---------------
OS:testing/unstable
uname:Linux 2.6.15-1-k7 #1 Fri Feb 10 16:09:44 UTC 2006 i686
libc:glibc 2.3.6 NPTL 2.3.6
rlimit: STACK 8192k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity
load average:2.64 1.99 1.73
CPU:total 1 family 6, cmov, cx8, fxsr, mmx, sse
Memory: 4k page, physical 516664k(6260k free), swap 1510068k(1217140k free)
vm_info: Java HotSpot(TM) Client VM (1.5.0_06-b05) for linux-x86, built on Nov 10 2005 12:08:33 by java_re with gcc 3.2.1-7a (J2SE release)
Il secondo problemi riguarda la tastiera. Ogno volta che il gioco crasha oppure viene terminato bruscamente va in qualche modo ad interferire con il sistema e disabilita la ripetione dei tasti.
ciao ;)
vicius, ho lo stesso problema, debian testing/unstable(kde 3.5) aggiornata una settimana fa, e ho come avuto l'impressione che i problemi siano cominciati appunto dal dist upgrade, io inoltre ho anche il problema che mi si blocca tutto il sistema quando lancio tramite ant i test da eclipse
In windows non ho di questi problemi...
Dunque. Ho provato ad aggiornare a Lwjgl 0.99 ma i problemi rimangono. :muro:
ciao ;)
Oggi sembro una calamita. Altro problema.
OS: Linux
Version: 2.6.15-1-k7
Architecture: i386
VM Vendor: Sun Microsystems Inc.
Version: 1.5.0_06
Class Path: /home/mirco/workspace/Diamonds/bin:/home/mirco/workspace/Diamonds/lib/junit.jar:/home/mirco/workspace/Diamonds/lib/easymock.jar:/home/mirco/workspace/Diamonds/lib/jar/lwjgl.jar:/home/mirco/workspace/Diamonds/lib/jar/lwjgl_devil.jar:/home/mirco/workspace/Diamonds/lib/jar/lwjgl_util.jar
JNI Library Path: lib/linux
Exception: class java.lang.NullPointerException
Message: null
Display Adapter Driver: null null
Stacktrace:
java.lang.NullPointerException
at it.diamonds.gems.GemsPair.toString(GemsPair.java:252)
at it.diamonds.PlayField.logActions(PlayField.java:99)
at it.diamonds.PlayField.reactToInput(PlayField.java:78)
at it.diamonds.GameLoop.processInput(GameLoop.java:165)
at it.diamonds.GameLoop.loop(GameLoop.java:198)
at it.diamonds.Game.main(Game.java:205)
Probabilmente è stato introdotto con il nuovo task.
ciao ;)
^TiGeRShArK^
19-02-2006, 18:49
Dunque. Ho provato ad aggiornare a Lwjgl 0.99 ma i problemi rimangono. :muro:
ciao ;)
hai provato ad aumentare l'heap della VM con l'opzione -Xmx 256 ad esempio???
non so se c'entri qualkosa..
ma prova.. non si sa mai :D
hai provato ad aumentare l'heap della VM con l'opzione -Xmx 256 ad esempio???
non so se c'entri qualkosa..
ma prova.. non si sa mai :D
Mi spunta letteralmente in faccia dicendomi che non può creare una Vm. :mad:
ciao ;)
^TiGeRShArK^
19-02-2006, 21:35
Mi spunta letteralmente in faccia dicendomi che non può creare una Vm. :mad:
ciao ;)
:eek:
....:stordita:
ah vero... errore mio :D
-Xmx 256M
altrimenti cerca di creare una virtual machine con una dimensiona max x l'heap di 256 byte .... e immagino si incazzi un poketto! :sofico:
:eek:
....:stordita:
ah vero... errore mio :D
-Xmx 256M
altrimenti cerca di creare una virtual machine con una dimensiona max x l'heap di 256 byte .... e immagino si incazzi un poketto! :sofico:
Niente. Il crash continua a presentarsi. :(
Ma non è finita qui. In una delle tante partite ho trovato anche un'altro problema con openal:
java: pcm_local.h:389: snd_pcm_channel_area_addr: Assertion `bitofs % 8 == 0' failed.
Questo pero è molto più raro. Poco prima di dare questo errore il suono diventa per un po distorto e poi il gioco esce.
ciao ;)
Sono tornato. In questi giorni mi rimetto in pari col codice con una bella review del lavoro svolto.
Sono tornato. In questi giorni mi rimetto in pari col codice con una bella review del lavoro svolto.
Ah quando il ritorno della build-machine?
ciao ;)
Ah quando il ritorno della build-machine?
La build machine era attiva anche oggi...guarda un po' chi l'ha lasciata rossa :D
La build machine era attiva anche oggi...guarda un po' chi l'ha lasciata rossa :D
Strano qua non è arrivato niente. :confused:
ciao ;)
Secondo me c'è da fare un mucchio di refactoring alla fine di questo ciclo... Il codice secondo me è diventato epsante da leggere... Dobbiamo trovare qualche soluzione per le bigGem... Magari spostando parte della logica nelle gemme...ad esempio:
- quando una gemma si ferma ci può pensare la gemma stessa a verificare se deve formare una BigGem
- oppure quando la gemma si muove può verificare se il moviemto è possibile (anche quello di gravità)
- oppure se la gemma è una Chest ci dovrebbe pensare la Chest stessa a cancellare tutte le gemme e le chest dello stesso tipo a contatto (questo potrebbe avvenire con una specie di funzione ricorsiva, che viene richiamata da gemma a gemma)
cdimauro
22-02-2006, 08:42
In effetti anch'io ho bisogno di una bella review del codice. Poi se potessi compilare Diamonds e lanciare Ant sulla mia macchina con OpenSuse 10, sarebbe anche meglio. :muro:
cdimauro
22-02-2006, 08:45
A proposito, cercando di effettuare l'update SVN mi dice questo:
update -r HEAD /home/cesare/workspace/Diamonds
svn: No route to host
C'è qualche problema col server?
Secondo me c'è da fare un mucchio di refactoring alla fine di questo ciclo... Il codice secondo me è diventato epsante da leggere... Dobbiamo trovare qualche soluzione per le bigGem... Magari spostando parte della logica nelle gemme...ad esempio:
- quando una gemma si ferma ci può pensare la gemma stessa a verificare se deve formare una BigGem
- oppure quando la gemma si muove può verificare se il moviemto è possibile (anche quello di gravità)
- oppure se la gemma è una Chest ci dovrebbe pensare la Chest stessa a cancellare tutte le gemme e le chest dello stesso tipo a contatto (questo potrebbe avvenire con una specie di funzione ricorsiva, che viene richiamata da gemma a gemma)
Buona quella della Chest...
Però il coupling stretto tra Gem e Grid e BigGem lo eviterei...
Comunque sono d'accordissimo con il refactoring... C'è molta roba da sistemare...
Però il coupling stretto tra Gem e Grid e BigGem lo eviterei...
Non volevo creare una cosa del genere, ma una specie struttura linkata dinamicamente...in modo che una gemma (o una bigGem) possa conoscere ad ogni istante (oppure solo quando si ferma) i riferimenti ai suoi "vicini", magari può essere Grid stessa a passarglieli...
Mi ha appena detto Antares che ieri ci sono stati problemi col server, ma sta già riuppando tutto, e tra poco sarà di nuovo operativo :)
I problemi con opengl non finiscono più. :muro:
Questa volta sono riuscito ad ottenere più informazioni.
OS: Linux
Version: 2.6.15-1-k7
Architecture: i386
VM Vendor: Sun Microsystems Inc.
Version: 1.5.0_06
Class Path: /home/mirco/workspace/Diamonds/bin:/home/mirco/workspace/Diamonds/lib/junit.jar:/home/mirco/workspace/Diamonds/lib/easymock.jar:/home/mirco/workspace/Diamonds/lib/jar/lwjgl.jar:/home/mirco/workspace/Diamonds/lib/jar/lwjgl_devil.jar:/home/mirco/workspace/Diamonds/lib/jar/lwjgl_util.jar
JNI Library Path: lib/linux
Exception: class org.lwjgl.opengl.OpenGLException
Message: Invalid operation (1282)
Display Adapter Driver: null null
Stacktrace:
org.lwjgl.opengl.OpenGLException: Invalid operation (1282)
at org.lwjgl.opengl.Util.checkGLError(Util.java:56)
at org.lwjgl.opengl.Display.update(Display.java:567)
at it.diamonds.engine.video.DisplayImplementation.update(DisplayImplementation.java:71)
at it.diamonds.engine.Engine.updateDisplay(Engine.java:71)
at it.diamonds.GameLoop.render(GameLoop.java:186)
at it.diamonds.GameLoop.loop(GameLoop.java:219)
at it.diamonds.Game.main(Game.java:206)
ciao ;)
cdimauro
23-02-2006, 08:26
Sono riuscito a far funzionare Ant, ma condivide gli stessi problemi del gioco principale. In fase di compilazione ottengo sempre:
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/cesare/workspace/Diamonds/lib/linux/liblwjgl.so: /home/cesare/workspace/Diamonds/lib/linux/liblwjgl.so: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:992)
at org.lwjgl.Sys$1.run(Sys.java:67)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.<clinit>(Sys.java:65)
at org.lwjgl.openal.AL.<clinit>(AL.java:77)
at it.diamonds.engine.audio.Audio.<init>(Audio.java:28)
at it.diamonds.Game.setUpAudio(Game.java:78)
at it.diamonds.Game.main(Game.java:188)
Il tutto su OpenSUSE 10 x86-64, con:
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_06-b05, mixed mode)
javac 1.5.0_06
Eclipse SDK
Version: 3.1.2
Build id: M20060118-1600
Da premettere che mi sono riletto questo thread e ho fatto un po' di prove con le indicazioni che ho trovato.
Ho anche fatto una ricerca con google, ma le soluzioni erano simili a quelle di questo thread (a parte una che diceva di aggiungere il path delle librerie a /etc/ld.so.conf.d/ , ma era già presente).
Insomma, mi sono arenato. :cry:
Qualcuno potrebbe darmi una mano, per favore?
^TiGeRShArK^
23-02-2006, 10:23
immagino ke non ti trovi le librerie opengl native x linux...
a me dava ieri lo stesso problema quando cercavo di fare funzionare i demo di jogl scaricati con webstart sotto java 6....:muro:
e non ho capito ancora km risolvere il problema...
immagino cmq dipenda sempre da java.library.path...
(a proposito... ti 6 ricordato d aggiungere -Djava.library.path=tuoPercorsoDoveHaiLeLibOpenGlPerLinux vero??? :stordita: )
cdimauro
23-02-2006, 11:22
Già provato, ma niente. :muro:
Secondo me c'è da fare un mucchio di refactoring alla fine di questo ciclo... Il codice secondo me è diventato epsante da leggere... Dobbiamo trovare qualche soluzione per le bigGem... Magari spostando parte della logica nelle gemme...ad esempio:
- quando una gemma si ferma ci può pensare la gemma stessa a verificare se deve formare una BigGem
- oppure quando la gemma si muove può verificare se il moviemto è possibile (anche quello di gravità)
- oppure se la gemma è una Chest ci dovrebbe pensare la Chest stessa a cancellare tutte le gemme e le chest dello stesso tipo a contatto (questo potrebbe avvenire con una specie di funzione ricorsiva, che viene richiamata da gemma a gemma)
Il prossimo Ciclo sara' concentrato prevalentemente sul Refactoring. E questo vuol dire posticipare la First Playable di due settimane, e ci insegnera' come non curare la qualita' del codice porta inevitabilmente a rallentamenti. In futuro, sempre prima di iniziare il proprio task, fare refactoring del codice sul quale si andra' a lavorare.
^TiGeRShArK^
23-02-2006, 21:47
HELPPPP!!!!!
guardate il mio post nella storia 1 :cry:
cdimauro
24-02-2006, 10:36
Non c'è proprio nessuno che potrebbe darmi una mano per risolvere il mio problema? Su ICQ e MSN sono collegato fino alle 17.
Pleeeeeease. :)
ho aggiornato x.org e altre cosine, ma ecco che errore mi esce adesso
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# SIGSEGV (0xb) at pc=0xb7993fca, pid=3278, tid=3085256928
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode, sharing)
# Problematic frame:
# V [libjvm.so+0x29afca]
#
--------------- T H R E A D ---------------
--------------- S Y S T E M ---------------
OS:testing/unstable
uname:Linux 2.6.15 #3 Fri Feb 3 18:21:32 CET 2006 i686
libc:glibc 2.3.5 NPTL 2.3.5
rlimit: STACK 8192k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity
load average:0.25 0.43 0.20
CPU:total 1 family 6, cmov, cx8, fxsr, mmx, sse, sse2
Memory: 4k page, physical 514096k(16600k free), swap 0k(0k free)
vm_info: Java HotSpot(TM) Client VM (1.5.0_04-b05) for linux-x86, built on Jun 3 2005 03:17:33 by java_re with gcc 3.2.1-7a (J2SE release)
Credo che a questo punto sia importante fare una sincronizzazione stretta dei timeStamp che girano per il sistema...attualmetne ogni volta che bisogna dare un valore ad un timeStamp gli diciamo di prendersi il valore attuale del timer... Questa cosa secondo me è errate se vogliamo riprodurre correttamente gli eventi (sia per il log che per le funzionalità di rete)...
La mia idea era di propagare il timeStamp della update e della reactToInput invece di propagare il timer...
Questo di fatto appiatttisce tutti gli eventi all'interno del gioco come se avvenissero nello stesso istante in cui avviene la update o la reactToInput...
Che ne dite ?
Ehm...errore di thread...
DanieleC88
28-02-2006, 09:15
Edit: tu non hai visto niente :)
Uh? :wtf:
A me in locale è verde !!!
Confermo...ora è verde, ma ho solo messo una riga vuota in GridController... Quel test fallsice casualmente ? Forse perchè non si basa sul MockGemGenerator...
Confermo...ora è verde, ma ho solo messo una riga vuota in GridController... Quel test fallsice casualmente ? Forse perchè non si basa sul MockGemGenerator...
Un test che fallisce casualmente e' cosa davvero molto antipatica. Puoi cambiarlo per usare MockGemGenerator?
Ora non posso, devo andare...Domani lo posso fare...
Ora non posso, devo andare...Domani lo posso fare...
Ok, allora puoi solo fare il revert oppure commentare via il test? Non possiamo lasciare la build rotta.
qual'è il test che passa ancora random?
Build verde.
Cisc, il test e' testGridIsUpdatedWithBigGems.
La pagina della build machine relativa:
http://fcarucci.homeip.net:8080/cruisecontrol/buildresults/diamonds?log=log20060228101324&tab=testResults
ho fixato un test che falliva a random...
Ieri nei miei refactoring avevo introdotto un bug:
Ad inizio partita comparivano i WarningBox sotto le due griglie.
Il bug è stato risolto perchè il caso non era testato. Ora vedo che è fixato ma non trovo ancora il test!
Ultimamente noto moltissimi test mancanti... Sarà che la complessità del progetto sta aumentando notevolmente ma tra un po' cominceremo a fare refactoring pesante e non penso sia il massimo farlo con test mancanti...
Intanto aggiungo questo va :)
Ieri nei miei refactoring avevo introdotto un bug:
Ad inizio partita comparivano i WarningBox sotto le due griglie.
Il bug è stato risolto perchè il caso non era testato. Ora vedo che è fixato ma non trovo ancora il test!
Ultimamente noto moltissimi test mancanti... Sarà che la complessità del progetto sta aumentando notevolmente ma tra un po' cominceremo a fare refactoring pesante e non penso sia il massimo farlo con test mancanti...
Intanto aggiungo questo va :)
Si il bug l'ho risolto io. Il test me lo sono scordato. Provvedo subito a punirmi. :muro:
ciao ;)
Ultimamente noto moltissimi test mancanti... Sarà che la complessità del progetto sta aumentando notevolmente ma tra un po' cominceremo a fare refactoring pesante e non penso sia il massimo farlo con test mancanti...
L'aumento della complessita' non giustifica la diminuzione di test, anzi, i test devono aumentare per mantenere la complessita' gestibile.
Al momento e' evidente che la nostra curva di costo sta aumentando e questo e' dovuto principalmente a due fattori:
- poco refactoring, con conseguente complicazione del codice
- pochi test, che portano a meno refactoring
E' una spirale che fa bloccata immediatamente.
Quindi, tassativamente, prima di iniziare ogni task guardate dove e' possibile semplificare il codice che state per toccare. Prima del refactoring, aggiungete i test mancanti al codice che state per rifattorizzare.
Ok fek, capita l'antifona! ;)
Ma ti devo assicurare che non mi sento così tranquillo nel refactoring. :bimbo:
Finchè si tratta di un extract-method ok....ma fino a che punto si può "refattorizzare"??
Ad esempio il vecchio "problema" che un Chest non è una Gem porterebbe ad un refactoring...ma andrebbe a toccare tantissimo codice e andrebbe a modificare anche molte delle logiche implementate.
Sarebbe quasi un refactoring da fare in pair...e in più....serve?? Veramente andrebbe a semplificare il codice e renderlo più gestibile?? :confused:
Insegnami Fek!!! :ave: :ave: :ave:
Ok fek, capita l'antifona! ;)
Ma ti devo assicurare che non mi sento così tranquillo nel refactoring. :bimbo:
Finchè si tratta di un extract-method ok....ma fino a che punto si può "refattorizzare"??
Ad esempio il vecchio "problema" che un Chest non è una Gem porterebbe ad un refactoring...ma andrebbe a toccare tantissimo codice e andrebbe a modificare anche molte delle logiche implementate.
Sarebbe quasi un refactoring da fare in pair...e in più....serve?? Veramente andrebbe a semplificare il codice e renderlo più gestibile?? :confused:
Insegnami Fek!!! :ave: :ave: :ave:
Secondo me ci sono refactoring molto più importanti ed "urgenti" in questo momento...
Ad esempio ci sarebbe da togliere completamente la WarningBox da Grid, implementare le ForeachAction che mancano... Sono solo esempi...
Basta che guardi il codice e se vedi qualcosa che può semplificare lo fai! Non serve che cerchi il refactoring grosso!
Comincia da quelli più urgenti e falli un passo per volta. Per esempio ora ho un quarto d'ora vedo cosa riesco a fare :p
Altri possibili refactoring sono:
- Eliminare tutto il codice duplicato tra TestGameLoop e GameLoop
- Eliminare duplicazione alcune duplicazioni nelle classi di test della griglia e delle gemme che hanno alcune funzioni di help e setUp in comune.
ciao ;)
^TiGeRShArK^
03-03-2006, 22:06
ehm...
problemino....
qualcuno sa come mai ottengo questo:
http://img203.imageshack.us/img203/3799/warning2pg.jpg (http://imageshack.us)
settando l'origine del Number in questo modo:
crushNumber = Number.create16x24(getCrushNumberX(), getCrushNumberY());
public int getCrushNumberX()
{
return (int)getX() + 21;
}
public int getCrushNumberY()
{
return (int)getY() + 9;
}
ehm...
problemino....
qualcuno sa come mai ottengo questo:
http://img203.imageshack.us/img203/3799/warning2pg.jpg (http://imageshack.us)
settando l'origine del Number in questo modo:
crushNumber = Number.create16x24(getCrushNumberX(), getCrushNumberY());
public int getCrushNumberX()
{
return (int)getX() + 21;
}
public int getCrushNumberY()
{
return (int)getY() + 9;
}
Sembra come se gli assi siano invertiti o qualcosa di simile. Provato a lancaire qualche numero a caso ? :D
ciao ;)
^TiGeRShArK^
03-03-2006, 22:30
ma ke palle...
avevo preso la dimensione dalla texture......
ma così facendo sembrerebbe che siano invertiti gli assi e che l'origine sia posta in alto a destra..:muro:
può essere Number il problema???
ma ke palle...
avevo preso la dimensione dalla texture......
ma così facendo sembrerebbe che siano invertiti gli assi e che l'origine sia posta in alto a destra..:muro:
può essere Number il problema???
Non mi pare. Se quello è l'unico problema che hai puoi sempre fare il commit cosi posso guardarci anche io e darti una mano.
ciao ;)
Ho appena notato che la texture di Warning è sbagliata. Provvedo ad aggiornarla.
EDIT: Fatto. La texture di riferimento è warning.png, e non incoming.png (errore mio, quella era una vecchia immagine che, a causa del nome poco indicativo, mi era sfuggita quando ho controllato il repository prima di uppare la nuova). Per favore, che qualcuno cambi il riferimento nel codice, in modo da poter eliminare incoming.png.
Ho appena notato che la texture di Warning è sbagliata. Provvedo ad aggiornarla.
EDIT: Fatto. La texture di riferimento è warning.png, e non incoming.png (errore mio, quella era una vecchia immagine che, a causa del nome poco indicativo, mi era sfuggita quando ho controllato il repository prima di uppare la nuova). Per favore, che qualcuno cambi il riferimento nel codice, in modo da poter eliminare incoming.png.
Ci penso io.
ciao ;)
Ci penso io.
ciao ;)
Grazie :)
ma ke palle...
avevo preso la dimensione dalla texture......
ma così facendo sembrerebbe che siano invertiti gli assi e che l'origine sia posta in alto a destra..:muro:
può essere Number il problema???
Ok. Risolto anche questo. I numeri vengono mostrati al loro posto. Questo dovrebbe concludere anche la storia e il ciclo.
ciao ;)
^TiGeRShArK^
04-03-2006, 11:00
ok tnx...
ieri sera stavo scoppiando di sonno e dopo il post ero andato a letto :D
per curiosità... qual'era il problema???
non partivano tutte le coordinate dall'origine in alto a sinisistra, e quindi anche le posizioni degli oggetti erano espressi in funzione del loro angolo in alto a sinistra???:fagiano:
ok tnx...
ieri sera stavo scoppiando di sonno e dopo il post ero andato a letto :D
per curiosità... qual'era il problema???
non partivano tutte le coordinate dall'origine in alto a sinisistra, e quindi anche le posizioni degli oggetti erano espressi in funzione del loro angolo in alto a sinistra???:fagiano:
La Y era in alto come doveva. La X invece ritornava il centro dello sprite quindi invece di aggiungere si doveva sottrarre per andare verso sinistra.
ciao ;)
^TiGeRShArK^
04-03-2006, 11:39
La Y era in alto come doveva. La X invece ritornava il centro dello sprite quindi invece di aggiungere si doveva sottrarre per andare verso sinistra.
ciao ;)
:doh:
e come mai abbiamo deciso questo comportamento assurdo x gli oggetti?:fagiano:
^TiGeRShArK^
04-03-2006, 11:51
ehm....
problemino....non mi passa 4 test...
capita anche a voi o solo da me fa le bizze???
i test sono:
TestBigGemFallingFromHigher - TestGemFalling
TestBigGemFallingWithGravity - TestGemFallingWithGravity
TestBigGemFallingFromHigherWithGravity - TestGemFallingWithGravity
TestBigGemFallingWithGravityToGridBottom - TestGemFallingWithGravity
ehm....
problemino....non mi passa 4 test...
capita anche a voi o solo da me fa le bizze???
i test sono:
TestBigGemFallingFromHigher - TestGemFalling
TestBigGemFallingWithGravity - TestGemFallingWithGravity
TestBigGemFallingFromHigherWithGravity - TestGemFallingWithGravity
TestBigGemFallingWithGravityToGridBottom - TestGemFallingWithGravity
confermo.
forse bisogna guardare come fanno altri test per simulare la caduta delle gemme(guardando l'array di gem di grid, sembra che scenda solo di una riga invece che di 2).
Io ho fatto un po' di refactoring aggiungendo le ForeachAction però ho lanciato i test sempre prima di committare ed era green! Non vorrei aver fatto qualcosa io! Ci do un'occhiata
:muro: :muro: non ci credo, mi sono portato diamonds su windows sul portatile, non essendo riuscito a capire il problema per ant e libGLCore su linux, vado per lanciare il gioco, e mi ritrovo una griglia di linee azzurre, in cui si riescono a distinguere appena le gemme (dei quadrati)!!!! :muro: :muro:
Da me non appare più la WarningBox... Deve essere stato qualche refactoring ieri...
Da me non appare più la WarningBox... Deve essere stato qualche refactoring ieri...
E' molto probabile. Qualunque cosa non coperta da test puo' essere saltata durante il refactoring. Puoi darci un'occhiata per favore?
E' molto probabile. Qualunque cosa non coperta da test puo' essere saltata durante il refactoring. Puoi darci un'occhiata per favore?
Ho dato un'occhiata veloce e ho subito notato un altro bug che vedete in allegato... Ad occhio e croce direi che è portato dai refactoring in PlayField, Grid, GameLoop etc...
Ho fatto un po' di refactoring e prima di stasera sicuramente non avrò tempo di controllare questi bug quindi se qualcuno può farlo al posto mio è meglio :)
Ho dato un'occhiata veloce e ho subito notato un altro bug che vedete in allegato... Ad occhio e croce direi che è portato dai refactoring in PlayField, Grid, GameLoop etc...
Ho fatto un po' di refactoring e prima di stasera sicuramente non avrò tempo di controllare questi bug quindi se qualcuno può farlo al posto mio è meglio :)
Ma la coppia è disegnata sotto la griglia? :mbe:
Ho dato un'occhiata veloce e ho subito notato un altro bug che vedete in allegato... Ad occhio e croce direi che è portato dai refactoring in PlayField, Grid, GameLoop etc...
Ho fatto un po' di refactoring e prima di stasera sicuramente non avrò tempo di controllare questi bug quindi se qualcuno può farlo al posto mio è meglio :)
c'era un errore in abstractGame(Veniva lanciata la setUpFieldTwo() e la creataGridOpponent()), per cui si avevano 2 griglie a dx, ma ne veniva aggiornata solo 1.
ps.ho risolto il nuovo bug, quello del warning mi sa che cè ancora.
c'era un errore in abstractGame(Veniva lanciata la setUpFieldTwo() e la creataGridOpponent()), per cui si avevano 2 griglie a dx, ma ne veniva aggiornata solo 1.
ps.ho risolto il nuovo bug, quello del warning mi sa che cè ancora.
hai aggiunto anche il test? Siamo molto carenti coi test ultimamente :D
trovato il bug del warning:
e sparita l'assegnazione delle griglie fra di loro per mostrare il warning(ma è veramente necessario? nn si riesce ad assegnare a griglia1 le coordinate giuste e viceversa?).
cmq ora creo un metodo attachFields() in gameLoop e lo dovrei fare rifunzionare.
trovato il bug del warning:
e sparita l'assegnazione delle griglie fra di loro per mostrare il warning(ma è veramente necessario? nn si riesce ad assegnare a griglia1 le coordinate giuste e viceversa?).
cmq ora creo un metodo attachFields() in gameLoop e lo dovrei fare rifunzionare.
Puoi postare il test che esercita il bug?
hai aggiunto anche il test? Siamo molto carenti coi test ultimamente :D
no, nn saprei come formulare il test
no, nn saprei come formulare il test
Troviamo un modo assieme magari. E' assolutamente fondamentale che ogni bug fix sia coperto da un test.
Puoi postare il test che esercita il bug?
è impossibile per come è organizzato il codice adesso.
dovrei instanziare game, ma ha costruttore privato.
Introduco un createGame pubblico e poi posto il test.
è impossibile per come è organizzato il codice adesso.
dovrei instanziare game, ma ha costruttore privato.
Introduco un createGame pubblico e poi posto il test.
Se e' impossibile per come e' organizzato il codice, si cambia l'organizzazione del codice. Il nostro scopo primario e' testare quello che scriviamo, se non possiamo testarlo, allora lo si modifica.
AbstractGame e' gia' un ottimo candidato ad essere rifattorizzato, perche' il nome non descrive affatto quello che sta facendo e la sua relazione con GameFactory e' tutt'altro che naturale. Il fatto poi che vi sia un bug e il suo fix non possa essere testato e' ulteriore sintomo di qualcosa che non va. E' il momento di intervenire e riportare AbstractGame sulla retta via :)
^TiGeRShArK^
05-03-2006, 13:11
dunque...
sto provando a vedere il problema del warningbox....
ho aggiunto questo test:
public void testWarningBoxIsShownAfterThreeCrushes()
{
gridUtil.insertAndUpdate(gridUtil.createGem(DIAMOND), 13, 3);
gridUtil.insertAndUpdate(gridUtil.createGem(DIAMOND_CHEST), 13, 2);
gridUtil.insertAndUpdate(gridUtil.createGem(RUBY), 13, 4);
gridUtil.insertAndUpdate(gridUtil.createGem(RUBY_CHEST), 13, 5);
gridUtil.insertAndUpdate(gridUtil.createGem(DIAMOND), 13, 6);
gridUtil.insertAndUpdate(gridUtil.createGem(DIAMOND_CHEST), 13, 7);
assertTrue("WarningBox not correctly shown", grid.getOpponentGrid().getWarningBox().isHidden());
grid.updateCrushes();
assertFalse("WarningBox not correctly shown", grid.getOpponentGrid().getWarningBox().isHidden());
}
che passa....
la visualizzazione dovrebbe avvenire perchè passa anche questo test che già c'era:
public void testNumberCorrectlyDrawn()
{
MockEngine engine = MockEngine.createForTesting(800, 600);
warningBox.setCrushCounter(2);
warningBox.show();
warningBox.draw(engine);
assertEquals("Number of crushes not correctly drawn", 2, engine.getNumberOfQuadsDrawn());
}
come posso fare per testare che il warningbox sia disegnato correttamente dopo i 3 crush???
non riesco a capire perchè il warning box è inserito dentro layerManager e non ho idea di come gestire il ridisegno del layerManager dopo l'update di grid.....
et voila, il primo test su game \o/
public void testGridAttached()
{
Game game = Game.createGameForTesting();
assertEquals("grid1 and opponent of grid2 are not the same",
game.getFieldOne().getGridController().getGrid().getOpponentGrid(),
game.getFieldTwo().getGridController().getGrid()
);
assertEquals("grid1 and opponent of grid2 are not the same",
game.getFieldTwo().getGridController().getGrid().getOpponentGrid(),
game.getFieldOne().getGridController().getGrid()
);
}
ho dovuto fare un refactorin e aggiungere un createGame e un createGamefortesting a game.
in piu ho creato un MockDiamondsGameFactory.
ho quasi risolto, ho aggiunto un metodo a gameloop(testato, e fatto un po di refactoring in giro).
Ora rifaccio un giro di test, rilascio ed esco :)
per l'altro bug da trovare il test, non ne ho proprio idea di come fare...
(ps, io ho creato game.createForTesting, un altra idea potrebbe essere quella di creare un mock che estende abstractGame)
una possibile idea potrebbe essere un contatore all'interno di playfield o gameloop che conta quante istanza di playField vengono create(ma è una soluzione tutt'altro che pulita...)
1) mi è capitato purtroppu un'altra BigGem che non è caduta completamente ma si è fermata poco sopra le gemme sottostanti.
Non chiedetemi nulla perchè ero in una fase concitata del gioco e non ho capito nulla :p
2) Stavo giocando con la mia ragazza (ragazzi mi sa che sto gioco appassiona, piace anche ad una sua amica ;) ) ad una sfida all'ultimo sangue.
Sul punteggio di 54.000 e passa a 51.000 e passa il gioco si è piantato...da solo.
Ecco il report:
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6916ebf4, pid=3236, tid=340
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing)
# Problematic frame:
# C [atioglxx.dll+0x16ebf4]
#
1) mi è capitato purtroppu un'altra BigGem che non è caduta completamente ma si è fermata poco sopra le gemme sottostanti.
Non chiedetemi nulla perchè ero in una fase concitata del gioco e non ho capito nulla :p
2) Stavo giocando con la mia ragazza (ragazzi mi sa che sto gioco appassiona, piace anche ad una sua amica ;) ) ad una sfida all'ultimo sangue.
Sul punteggio di 54.000 e passa a 51.000 e passa il gioco si è piantato...da solo.
Ecco il report:
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6916ebf4, pid=3236, tid=340
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing)
# Problematic frame:
# C [atioglxx.dll+0x16ebf4]
#
Roba di OpenGL & ATI... Ti è capitato solo una volta?
Sì...mi è capitato una sola volta :(
Sì...mi è capitato una sola volta :(
Pensi che provare a mandare una mail alla Sun può essere di aiuto?
Pensi che provare a mandare una mail alla Sun può essere di aiuto?
:mbe: :mbe: :mbe:
:mbe: :mbe: :mbe:
Io penso di sì dato che è un errore dato dalla JVM...
Abbiamo un memory leak abissale...fate conto che sono arrivato a 497 Mb di ram occupata... IMHO è arrivato il momento di inserire la classe TextureBank che avevo creato tempo fa... In questo modo allochiamo una sola texture per ogni immagine...
H scoperto cosa causava il memory leak... E la texture realtiva al chainCounter che probabilmente viene allocato ad ogni frame...roba da 100 mega a botta !!! :)
H scoperto cosa causava il memory leak... E la texture realtiva al chainCounter che probabilmente viene allocato ad ogni frame...roba da 100 mega a botta !!! :)
Mi sembrava stano. :)
Tempo fa mi ero girato tutte classi alla ricerca dei punti in cui venivano eliminate gemme e biggem inserendo tutte le cleanup necessarie.
C'è modo di non allocare ogni volta la texture ?
ciao ;)
Boh...sinceramente non ho capito nemmeno dove viene creata la classe :sofico:
Boh...sinceramente non ho capito nemmeno dove viene creata la classe :sofico:
La texture viene creata quando imposta la nuova cifra da mostrare. Si potrebbe mettere un controllo che chiama la cleanup ogni volta pero non mi piace molto come soluzione. Il TextureBank che hai creato è nel repository cosi ci posso dare un occhiata?
I task sono quasi finiti e mancano ancora 6 giorni alla fine del ciclo cosi possiamo concentrarci ad inserire questo nuovo elemento nel engine.
ciao ;)
Sì...dovrebbe essere in branches/SoundBank (sotto engine/video)...
A quei tempi c'era anche il tipo di gemma in texture... Quindi va leggermente modificato per supportare tutte le texture...
Comunque non è facile propagare il riferimento TextureBank in tutte queste classi...
PS: TextureBank è molto semplice...è solamente un HashMap di Texture indicizzate in base al loro nome ;)
Usare il pattern Flyweight ???? :sofico:
Usare il pattern Flyweight ???? :sofico:
TextureBank è simile a flyweight. :)
ciao ;)
^TiGeRShArK^
13-03-2006, 23:47
La texture viene creata quando imposta la nuova cifra da mostrare. Si potrebbe mettere un controllo che chiama la cleanup ogni volta pero non mi piace molto come soluzione. Il TextureBank che hai creato è nel repository cosi ci posso dare un occhiata?
I task sono quasi finiti e mancano ancora 6 giorni alla fine del ciclo cosi possiamo concentrarci ad inserire questo nuovo elemento nel engine.
ciao ;)
:fiufiu:
mi sa ke l'ho introdotto io 'sto bug...
in effetti ci avevo pure pensato infatti originariamente quando il crushbox era in grid anzikè cambiare la texture distruggevo il crushBox e lo ricreavo quando si doveva visualizzare...
in quel modo avveniva sempre il memory leak???
a okkio direi di no..ma a quest'ora non riesco + a pensare :D
La CrushBox ora si vede sopra la griglia, ma si vede anche sopra le gemme... Vogliamo questo ?
Credo che sia da evitare l'estrazione di due flashing gem consecutive...mi è siccesso :eek: Che dite ?
La CrushBox ora si vede sopra la griglia, ma si vede anche sopra le gemme... Vogliamo questo ?
Si Jocchan è stato chiaro.
ciao ;)
Credo che sia da evitare l'estrazione di due flashing gem consecutive...mi è siccesso :eek: Che dite ?
In effetti è da impedire anche perché non sappiamo cosa fare se due flashing gem collidono.
ciao ;)
^TiGeRShArK^
14-03-2006, 18:10
La CrushBox ora si vede sopra la griglia, ma si vede anche sopra le gemme... Vogliamo questo ?
ehm.. a quanto ho capito si....
pure a me sembrava strano però... :mbe:
In effetti è da impedire anche perché non sappiamo cosa fare se due flashing gem collidono.
ciao ;)
il test lo sa :O
forse nn era richiesto :asd: ma si comporta come se fosse una qualsiasi altra gemma. In caso siano impilate verticalmente, cancella tutte le flashing gem presenti nella griglia.
l'unico caso nn coperto da test(che mi è venuto in mente adesso) e il caso:
RFFR
In questo caso ho paura che rimanga la seconda flash(è giusto?). Infatti trova la prima F, cancella tutte le R, trova la seconda F ma è sola e rimane.
Problema: ieri il mio hard disk è collassato, e probabilmente si è portato dietro nell'oblio gli ultimi lavori che avevo fatto, e che non avevo fatto in tempo a backuppare (ossia il psd della schermata del titolo ed i primi frame di Ice).
Dopodomani proverò a montare un hdd nuovo di pacca, e - collegando quello attuale come secondario - a vedere se sarà possibile recuperarli.
Incrociate le dita anche per me.
Problema: ieri il mio hard disk è collassato, e probabilmente si è portato dietro nell'oblio gli ultimi lavori che avevo fatto, e che non avevo fatto in tempo a backuppare (ossia il psd della schermata del titolo ed i primi frame di Ice).
Dopodomani proverò a montare un hdd nuovo di pacca, e - collegando quello attuale come secondario - a vedere se sarà possibile recuperarli.
Incrociate le dita anche per me.
Siamo tutti attorcigliati :D
Buona fortuna con l'hd nuovo.
ciao ;)
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.