View Full Version : Thread dei Problemi
cdimauro
15-03-2006, 08:44
Rieccomi, ma con qualche problema (come al solito: sfiga walks with me :p).
Ho abbandonato Linux e sono tornato all'ovile (Windows XP x64 :D), e finora è andato tutto bene anche con Eclipse e Java, tranne che per una cosa. Lanciando game.java mi capita questo:
OS: Windows 2003
Version: 5.2
Architecture: x86
VM Vendor: Sun Microsystems Inc.
Version: 1.5.0_06
Class Path: C:\workspace\Diamonds\bin;C:\workspace\Diamonds\lib\junit.jar;C:\workspace\Diamonds\lib\easymock.jar;C:\workspace\Diamonds\lib\jar\lwjgl.jar;C:\workspace\Diamonds\lib\jar\lwjgl_devil.jar;C:\workspace\Diamonds\lib\jar\lwjgl_util.jar
JNI Library Path: C:\workspace\Diamonds\lib\win32
Exception: class java.lang.RuntimeException
Message: GameLoop was not properly initialized
Display Adapter Driver: ati2dvag null
Stacktrace:
java.lang.RuntimeException: GameLoop was not properly initialized
at it.diamonds.GameLoop.loop(GameLoop.java:266)
at it.diamonds.Game.startGame(Game.java:30)
at it.diamonds.Game.main(Game.java:44)
L'output della console si ferma alla visualizzazione dell'elenco delle modalità disponibili:
Display Adapter: ati2dvag
List of available display modes:
512 x 384 x 16 @60Hz
320 x 240 x 16 @75Hz
1024 x 768 x 16 @72Hz
1600 x 1200 x 32 @60Hz
640 x 400 x 32 @75Hz
1280 x 1024 x 16 @70Hz
640 x 480 x 16 @75Hz
1280 x 960 x 16 @72Hz
1024 x 768 x 32 @85Hz
1280 x 960 x 32 @75Hz
800 x 600 x 32 @70Hz
1280 x 960 x 16 @60Hz
800 x 600 x 16 @85Hz
1024 x 768 x 16 @75Hz
400 x 300 x 32 @60Hz
800 x 600 x 16 @72Hz
1280 x 1024 x 16 @75Hz
1280 x 960 x 16 @70Hz
800 x 600 x 32 @56Hz
1920 x 1200 x 16 @60Hz
640 x 400 x 16 @60Hz
1280 x 1024 x 32 @85Hz
1024 x 768 x 32 @60Hz
1920 x 1440 x 32 @60Hz
1856 x 1392 x 16 @60Hz
800 x 600 x 32 @60Hz
320 x 240 x 32 @60Hz
1280 x 1024 x 32 @60Hz
1800 x 1440 x 16 @60Hz
1280 x 960 x 32 @85Hz
1920 x 1080 x 32 @60Hz
800 x 600 x 16 @75Hz
640 x 480 x 16 @72Hz
1024 x 768 x 16 @70Hz
1152 x 864 x 32 @85Hz
512 x 384 x 32 @75Hz
1152 x 864 x 16 @60Hz
1152 x 864 x 16 @70Hz
320 x 200 x 16 @60Hz
800 x 600 x 16 @70Hz
1280 x 1024 x 32 @70Hz
1792 x 1344 x 16 @60Hz
800 x 600 x 32 @72Hz
1920 x 1440 x 16 @60Hz
1856 x 1392 x 32 @60Hz
1280 x 1024 x 32 @75Hz
640 x 480 x 16 @60Hz
800 x 600 x 16 @56Hz
1920 x 1200 x 32 @60Hz
1152 x 864 x 32 @70Hz
640 x 400 x 32 @60Hz
1024 x 768 x 32 @70Hz
1280 x 960 x 16 @85Hz
400 x 300 x 16 @60Hz
640 x 400 x 16 @75Hz
1152 x 864 x 16 @75Hz
640 x 480 x 32 @75Hz
1024 x 768 x 16 @60Hz
1280 x 960 x 16 @75Hz
512 x 384 x 32 @60Hz
320 x 240 x 32 @75Hz
1024 x 768 x 32 @75Hz
512 x 384 x 16 @75Hz
1280 x 1024 x 16 @60Hz
400 x 300 x 16 @75Hz
1152 x 864 x 32 @60Hz
640 x 480 x 32 @72Hz
320 x 240 x 16 @60Hz
640 x 480 x 16 @85Hz
1280 x 960 x 32 @72Hz
800 x 600 x 16 @60Hz
800 x 600 x 32 @85Hz
400 x 300 x 32 @75Hz
1024 x 768 x 16 @85Hz
1280 x 960 x 32 @70Hz
320 x 200 x 32 @75Hz
1920 x 1080 x 16 @60Hz
320 x 200 x 16 @75Hz
800 x 600 x 32 @75Hz
1152 x 864 x 32 @75Hz
1152 x 864 x 16 @85Hz
1792 x 1344 x 32 @60Hz
1600 x 1200 x 16 @60Hz
1800 x 1440 x 32 @60Hz
1024 x 768 x 32 @72Hz
640 x 480 x 32 @85Hz
1280 x 1024 x 16 @85Hz
320 x 200 x 32 @60Hz
1280 x 960 x 32 @60Hz
640 x 480 x 32 @60Hz
Best mode: 800 x 600 x 32 @85Hz
Altra cosa, il dialog con la segnalazione del crash mi appare due volte di seguito.
La build con ANT, invece, è green.
Cesare, ma a ce risoluzione lavora il tuo desktop ? Lì sembra che scelga 800x600 :eek:
Secondo me sceglie la risoluzione sbaglita e quindi si incricca sulla creazione dell'engine...
Io ho un altro problema sul portatile:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
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:57)
at it.diamonds.engine.audio.Audio.<init>(Audio.java:28)
at it.diamonds.AbstractGame.setUpGame(AbstractGame.java:25)
at it.diamonds.Game.createGame(Game.java:114)
at it.diamonds.Game.main(Game.java:43)
Questo quando lancio Game, mentre sui test da Eclipse ho un problema credo simile, sempre relativo lwjgl... Da notare che la build con ant funziona...
Altra cosa...è normale che mi prenda 500 MB di RAM per fare la build ?!?!? Mi sembra un'esagerazione...si può fare qualcosa per rilasciare le risorse fra un test e l'altro della build (si vede proprio che la ram aumenta ad ogni test)... Contate che il mio portatile ha 384 Mb di ram...quindi pensate a come va veloce :) Oltre 3 minuti per fare la build :eek:
LA JVM veniva già forkata, ma c'era come parametro once, cioè veniva creata una jvm per tutti i task... Sto provando il parametro perTask, ma è lento (nemmeno tanto, 1m 49s su un P3-m 1133)... Ora provo il parametro perBatch...
Con perBatch si ottiene lo stesso comportamento che con once...infatti c'è un batch solo...
Comunque su una macchina performante la differenza fra l'uso di perTest e once è di circa 20 secondi...
Attualmente la memoria allocata con once è di circa 500 MB contate che aumenterà molto con l'aumentare dei test...
Cesare, ma a ce risoluzione lavora il tuo desktop ? Lì sembra che scelga 800x600 :eek:
Secondo me sceglie la risoluzione sbaglita e quindi si incricca sulla creazione dell'engine...
Io ho un altro problema sul portatile:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
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:57)
at it.diamonds.engine.audio.Audio.<init>(Audio.java:28)
at it.diamonds.AbstractGame.setUpGame(AbstractGame.java:25)
at it.diamonds.Game.createGame(Game.java:114)
at it.diamonds.Game.main(Game.java:43)
Questo quando lancio Game, mentre sui test da Eclipse ho un problema credo simile, sempre relativo lwjgl... Da notare che la build con ant funziona...
Altra cosa...è normale che mi prenda 500 MB di RAM per fare la build ?!?!? Mi sembra un'esagerazione...si può fare qualcosa per rilasciare le risorse fra un test e l'altro della build (si vede proprio che la ram aumenta ad ogni test)... Contate che il mio portatile ha 384 Mb di ram...quindi pensate a come va veloce :) Oltre 3 minuti per fare la build :eek:
Avevo lo stesso problema per i test... Ho risolto aggiungendo ai VM Arguments:
-Djava.library.path=lib\win32
Grazie, Vic :)
Perderei tantissime cose, ma soprattutto mi farebbe rabbia perdere gli ultimi psd creati per Diamonds.
Cesare, ma a ce risoluzione lavora il tuo desktop ? Lì sembra che scelga 800x600 :eek:
Secondo me sceglie la risoluzione sbaglita e quindi si incricca sulla creazione dell'engine...
Io ho un altro problema sul portatile:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
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:57)
at it.diamonds.engine.audio.Audio.<init>(Audio.java:28)
at it.diamonds.AbstractGame.setUpGame(AbstractGame.java:25)
at it.diamonds.Game.createGame(Game.java:114)
at it.diamonds.Game.main(Game.java:43)
Questo quando lancio Game, mentre sui test da Eclipse ho un problema credo simile, sempre relativo lwjgl... Da notare che la build con ant funziona...
Altra cosa...è normale che mi prenda 500 MB di RAM per fare la build ?!?!? Mi sembra un'esagerazione...si può fare qualcosa per rilasciare le risorse fra un test e l'altro della build (si vede proprio che la ram aumenta ad ogni test)... Contate che il mio portatile ha 384 Mb di ram...quindi pensate a come va veloce :) Oltre 3 minuti per fare la build :eek:
Sì anche io quando lancio i test mi sfrulla l'HD per mezz'ora dopo che sono finiti...
Sì anche io quando lancio i test mi sfrulla l'HD per mezz'ora dopo che sono finiti...
Ok...allora se per tutti va bene possiamo mettere l'opzione forkmode="perTest" in build.xml...
Ok...allora se per tutti va bene possiamo mettere l'opzione forkmode="perTest" in build.xml...
Esegue una fork per ogni test? Beh se migliora così tanto io son d'accordo :)
Sì, esegue una fork della JVM per ogni test... Sulle macchine performanti e con tanta memoria raddoppia circa il tempo di build (sempre inferiore al minuto comunque)...mentre in macchine con poca memoria dimezza (anzi, spesso di più, dipende da quanta roba c'era aperta prima) il tempo di build... Da notare che le macchine con poca memoria non sono rallentate solo durante la build, ma anche dopo, quando si riswappare la memoria di Eclipse e degli altri applicativi da disco a Ram...
Sì, esegue una fork della JVM per ogni test... Sulle macchine performanti e con tanta memoria raddoppia circa il tempo di build (sempre inferiore al minuto comunque)...mentre in macchine con poca memoria dimezza (anzi, spesso di più, dipende da quanta roba c'era aperta prima) il tempo di build... Da notare che le macchine con poca memoria non sono rallentate solo durante la build, ma anche dopo, quando si riswappare la memoria di Eclipse e degli altri applicativi da disco a Ram...
Commit! Il mio povero PC muore ogni volta che faccio partire i test.
ciao ;)
Come previsto il tempo di build del server è raddoppiato, ma provate pure in locale con meno di un giga di ram dovreste avere netti miglioramenti...
cdimauro
16-03-2006, 08:16
Cesare, ma a ce risoluzione lavora il tuo desktop ? Lì sembra che scelga 800x600 :eek:
Secondo me sceglie la risoluzione sbaglita e quindi si incricca sulla creazione dell'engine...
Il mio desktop è impostato a 1280x1024x32@85Hz. :D
Ho fatto delle prove e il tracing, e avevo visto che veniva scelto una modalità a 800x600x32@200Hz.
Pensavo che fosse la frequenza il problema, per cui ho patchato la funzione displayModeIsBetter di DisplayImplementation facendo in modo di limitare a 120Hz mode.getFrequency; non so per quale motivo, ma selezionava sempre la 800x600x32@70Hz (quando invece era disponibile la 800x600x32@120Hz).
In ogni caso, anche con questa modalità, mi dà lo stesso problema: si pianta su
Display.create(new PixelFormat(24, 0, 0, 0, 0));
generando un'eccezione.
L'eccezione viene intrappolata nel try / catch a cui appartiene, e da lì risalendo nella catena di try / catch l'esecuzione viene bloccata, generato il file di log e il dialog di avvertimento (che però appare 2 volte, come già detto, e non una).
La cosa di cui mi sono accorto è che il messaggio dell'eccezione viene perso, e quindi non riportato nel file di log, rendendo difficile il debug. Infatti nel file di log appare:
Exception: class java.lang.RuntimeException
Message: GameLoop was not properly initialized
ma in realtà l'eccezione è stata:
org.lwjgl.LWJGLException: Could not find a valid pixel format
La mia scheda video è una Radeon 9250, coi driver standard di XP x64.
A questo punto mi sono fermato perché non so più cosa fare.
Altra cosa...è normale che mi prenda 500 MB di RAM per fare la build ?!?!? Mi sembra un'esagerazione...si può fare qualcosa per rilasciare le risorse fra un test e l'altro della build (si vede proprio che la ram aumenta ad ogni test)... Contate che il mio portatile ha 384 Mb di ram...quindi pensate a come va veloce :) Oltre 3 minuti per fare la build :eek:
Con l'ultima build sulla mia macchina (XP x64, 512MB, Eclipse & JDK a 32 bit) ho tenuto d'occhio i processi di eclipse e i 3 processi della jvm, e mediamente il consumo di ram si è assestato sui 100MB, con qualche picco che è arrivato a circa 150MB. Ottimo direi. ;)
Come previsto il tempo di build del server è raddoppiato, ma provate pure in locale con meno di un giga di ram dovreste avere netti miglioramenti...
Il server e' li per fare la build, ci puo' mettere anche dieci minuti per me. L'importante e' che per voi sia veloce mentre sviluppate.
^TiGeRShArK^
16-03-2006, 21:40
Come previsto il tempo di build del server è raddoppiato, ma provate pure in locale con meno di un giga di ram dovreste avere netti miglioramenti...
ehm...
io ho 1GB.. :fiufiu:
mi sa ke devo mantenere la vecchia impostazione allora :D
^TiGeRShArK^
16-03-2006, 21:41
jocchan...km è andata???
dimmi ke hai recuperato almeno i PSD :cry:
jocchan...km è andata???
dimmi ke hai recuperato almeno i PSD :cry:
Sono felice di annunciarvi che ho recuperato TUTTO QUANTO :D
Domani finisco di installare i driver e sarò di nuovo operativo :)
Sono felice di annunciarvi che ho recuperato TUTTO QUANTO :D
Domani finisco di installare i driver e sarò di nuovo operativo :)
:cincin: :D
ciao ;)
La build è rossa... Come mai non vengono più ignorati i test in ignore ?
La build è rossa... Come mai non vengono più ignorati i test in ignore ?
Li puoi commentare per ora?
Ho visto che il file è in it.diamonds.tests.ignore...
La cartella che viene ignorata non it.diamonds.ignore ?
Ho visto che il file è in it.diamonds.tests.ignore...
La cartella che viene ignorata non it.diamonds.ignore ?
Devo guardare build.xml, mi sembra di ricordare che sia tests.ignore ma non ci giuro.
E' prioprio tests.ignore...
Guarda:
[junit] Testsuite: it.diamonds.tests.ignore.TestGemCrushing
[junit] Tests run: 22, Failures: 0, Errors: 0, Time elapsed: 0,731 sec
BUILD SUCCESSFUL
Total time: 44 seconds
Questo in locale... Fa la build anche di ignore... :eek:
E' prioprio tests.ignore...
Guarda:
[junit] Testsuite: it.diamonds.tests.ignore.TestGemCrushing
[junit] Tests run: 22, Failures: 0, Errors: 0, Time elapsed: 0,731 sec
BUILD SUCCESSFUL
Total time: 44 seconds
Questo in locale... Fa la build anche di ignore... :eek:
Hmmm... Vic, puoi dare un'occhiata a build.xml e sistemarlo per favore? Dovrebbe essere banale ma dall'ufficio non ho accesso a SVN come sempre.
Lo strano è che build.xml sembra che vada bene:
<javac
srcdir="${src}"
destdir="${build}/debug"
debug="on"
excludes="${src}/it/diamonds/tests/ignore/**">
<classpath refid="classpath.test" />
</javac>
Allora alzo bandiera bianca :(
Suggerimenti?
^TiGeRShArK^
17-03-2006, 17:55
Sono felice di annunciarvi che ho recuperato TUTTO QUANTO :D
Domani finisco di installare i driver e sarò di nuovo operativo :)
OLE'! :D
^TiGeRShArK^
17-03-2006, 17:58
Allora alzo bandiera bianca :(
Suggerimenti?
mmmm...
ora guardo un'attimo appena finisce l'update...
^TiGeRShArK^
17-03-2006, 18:35
risolto...
non doveva escludere ${src}/it/diamonds/tests/ignore/** ma semplicemente /it/diamonds/tests/ignore/** dato ke la base dir è già src.
risolto...
non doveva escludere ${src}/it/diamonds/tests/ignore/** ma semplicemente /it/diamonds/tests/ignore/** dato ke la base dir è già src.
Ottimo! :)
Segnalo che ho 2 warning lanciando JUnit da interfaccia di eclipse. Sono dovuti al fatto che GridTestCase e GemsPairTestCase non possiedono nessun test...
La build viene data per rossa.
Ottimo! :)
Segnalo che ho 2 warning lanciando JUnit da interfaccia di eclipse. Sono dovuti al fatto che GridTestCase e GemsPairTestCase non possiedono nessun test...
La build viene data per rossa.
Sono classi di appoggio quindi non hanno test e non devono.
ciao ;)
^TiGeRShArK^
17-03-2006, 20:36
Per quello il problema è eclipse...
e purtroppo non so se si possa fare niente....
cmq ho risolto un altro buggettino nel build.xml rimuovendo le prime due righe con la definizione dell'xml ke impedivano ad eclipse di visualizzare la colorazione della sintassi in maniera corretta....
ah... a proposito...
se vi dovessa capitare di aprire un file con wordpad perchè siete pigri e non volete usare eclipse RICORDATEVI che CTRL+S NON salva.
Ho perso mezz'ora per risolvere il primo bug xkè ero convinto di salvare e invece wordpad non faceva UNA MAZZA con CTRL+S! :muro:
Ho provato molto rapidamente l'ultima build, e ho notato che la coordinata X della png per le crush (nice, good, etc.) per il primo giocatore è sbagliata: dovrebbe essere -60 (quella per il secondo giocatore invece va benissimo) :)
^TiGeRShArK^
18-03-2006, 00:05
Ho provato molto rapidamente l'ultima build, e ho notato che la coordinata X della png per le crush (nice, good, etc.) per il primo giocatore è sbagliata: dovrebbe essere -60 (quella per il secondo giocatore invece va benissimo) :)
ah...allora non avevi sbagliato a scrivere... c'era proprio il segno - ....
provvedo subito.. anke se 'ste coordinate degli sprite onestamente non mi quadrano tanto :p
cmq ho guardato il post originale e c'è scritto -67...
dove la devo mettere a -67 o a -60?? :fiufiu:
cmq intanto la sposto a -67...:D
^TiGeRShArK^
18-03-2006, 00:14
fatto... prob risolto.. :fiufiu:
Posto anche qua per maggiore visibilità.
Non sono riuscito a fare un test. Ho committato del codice senza test...però è commentato :fiufiu:
qui è spiegato tutto :
http://www.hwupgrade.it/forum/showpost.php?p=11682251&postcount=95
Ti prego Fek...nonmi spezzare le ditine :ave: :ave:
ah...allora non avevi sbagliato a scrivere... c'era proprio il segno - ....
provvedo subito.. anke se 'ste coordinate degli sprite onestamente non mi quadrano tanto :p
cmq ho guardato il post originale e c'è scritto -67...
dove la devo mettere a -67 o a -60?? :fiufiu:
cmq intanto la sposto a -67...:D
Scusa, ricordavo male io :)
Era -67 :D
La coordinata è negativa perchè il file è fatto apposta per essere utilizzato sia dal primo che dal secondo giocatore (è double face insomma :stordita: ). Ora testo la nuova build ;)
Benissimo, ora le coordinate sono perfette ;)
Ho notato che le flashing gem saltano fuori piuttosto spesso, nonostante il misero 2% di probabilità. Quindi, probabilmente dovremo introdurre un qualche artificio per limitarle, e che non le renda al contempo TROPPO rare.
Altra cosa, mi è capitato (una sola volta) che le gemme cancellate da una flashing venissero considerate parte di una Crush, e non mi pare ci siano state altre cancellazioni sullo schermo. Potrei sbagliarmi io (e spero sia così), ma fate attenzione se dovesse capitare anche a voi, potrebbe saltare fuori un qualche bug da correggere.
P.S.: importante: ogni volta che sembra ci sia un errore nelle specifiche di storia e task, ditelo qui sul forum e verifichiamo. Questo perchè potremmo avere comportamenti non voluti, e potrebbe essere piuttosto difficile trovarne la causa.
BlueDragon
18-03-2006, 14:01
Ho notato che le flashing gem saltano fuori piuttosto spesso, nonostante il misero 2% di probabilità. Quindi, probabilmente dovremo introdurre un qualche artificio per limitarle, e che non le renda al contempo TROPPO rare.
Mi piace il calcolo delle probabilità..e quindi ho approfittato dell'occasione per dedicare un po' di tempo a Diamonds (che continuo a seguire ma era un sacco di tempo che non leggevo il codice).
Flashing Gems:
Innanzitutto le Flashing Gems hanno il 2% di probabilità di essere create singolarmente....e questo significa che si ha circa il 4% di possibilità di trovare almeno una Flashing Gem in una coppia di gemme. Significa che in media ogni 25 coppie di gemme una contiene una Flashing Gem....ecco perché sono molto meno rare del 2%! :)
Impostando il config ad 1% oppure modificando il codice affinché la percentuale del 2% sia intesa "per coppia di gemme", probabilmente otterremo il risultato voluto...a meno che anche 1 Flash su 50 coppie sia troppo! :)
Topazi rari:
Inoltre, nel leggere il codice delle probabilità ho notato delle strane condizioni che rendono il topazio meno probabile delle altre gemme, circa 13.6% di probabilità contro il 16.3% delle altre gemme su un totale di 800.000 gemme.
Il codice (in GemFactory) è il seguente:
public Gem createRandomGem()
{
int module = GEM_TYPES.length - 1;
if(firstGemExtraction)
{
module = GEM_TYPES.length;
firstGemExtraction = false;
}
int randomIndex = randomGenerator.extract(module);
if(randomIndex >= nextToLastGemIndex)
{
randomIndex = (randomIndex + 1) % GEM_TYPES.length;
}
nextToLastGemIndex = lastGemIndex;
lastGemIndex = randomIndex;
resetChestExtraction();
return create(GEM_TYPES[randomIndex]);
}
Rimuovendo la parte in grassetto, si ottiene una perfetta distribuzione delle probabilità tra le gemme.
Non ho ancora analizzato se la sua rimozione rompe qualche test....
Memory Leak:
Nel fare i test sulle probabilità ho avuto occasione di creare parecchie gemme, ed ho quindi notato un consumo di circa 1 GB di RAM per creare 10.000 gemme....si tratta di ben 100kb a gemma :)
Creavo le gemme con un questo codice:
for (int x= 0 ; x < 100000;x++)
{
Gem gemma = gemFactory.createRandomDroppable();
gemma.cleanup();
}
Chiamare .cleanup() non era sufficiente... Avevo provato anche a metterci un'invocazione al Garbage Collector ogni 1000 iterazioni ma non sembrava aver alcun effetto :)
Una volta raggiunto il limite della memoria RAM + swap su disco, Diamonds crashava con la finestrella di bugreport.. che appare 2 volte :)
Grandissimo, BD :)
Il problema della frequenza non è tanto nella percentuale, dato che a ridurla ulteriormente sarebbero TROPPO rare, quanto nel fatto che la randomizzazione dovrebbe essere controllata verso il basso (ovvero, ci vorrebbe un limite minimo per l'intervallo tra una flashing gem e l'altra).
Diluire ulteriormente la sua occorrenza significa che in diverse partite potrebbe non saltare mai fuori, ed avremmo il problema opposto.
Molto probabilmente ho scovato un altro paio di bug.
Giocando ho preparato una crush da 4-5x ammucchiando diverse gemme e bauli. Dopo averla innescata, però, il contatore è arrivato ad un assurdo 8x (Astounding).
Questo perchè molto probabilmente c'è un errore di fondo nell'implementazione del conteggio delle crush (e probabilmente è anche colpa di come abbiamo impostato storia e task): a rigor di logica, il contatore della lunghezza deve aumentare solo se l'evento scatenante di una cancellazione è stato un'altra cancellazione.
Allo stato attuale, invece, il gioco considera come crush anche quando, posizionando una coppia di bauli, vengono cancellate due gemme di colore diverso già ferme. Questo non ha senso, dato che la seconda cancellazione non è conseguenza della prima.
Quindi, bisogna vedere di sistemare il tutto in modo da considerare, per le crush, solo i pezzi che cadono per riempire i vuoti. Ne parlerò con Vicius, e probabilmente sarà uno dei task per il prossimo ciclo.
L'altro bug fondamentale riguarda il contatore mostrato sotto l'area di gioco dell'avversario: dopo la (lunga) combo di cui sopra, il contatore in questione segnava il valore di 5. Avevo già notato delle incoerenze, e questo evento ne è stato la conferma. Direi che bisogna dare un'occhiata al suo funzionamento ;)
BlueDragon
18-03-2006, 14:59
Topazi Rari:
Ho provato ad eliminare il codice in bold evidenziato nel mio post precedente, e l'unico test che fallisce è il seguente:
public void testRandomGemSequence()
{
Gem gem = factory.createRandomGem();
assertEquals("does not return Gem of type topaz", TOPAZ, gem.getType());
gem = factory.createRandomGem();
assertEquals("does not return Gem of type diamond", DIAMOND, gem
.getType());
gem = factory.createRandomGem();
assertEquals("does not return Gem of type diamond", DIAMOND, gem
.getType());
gem = factory.createRandomGem();
assertEquals("does not return Gem of type ruby", RUBY, gem.getType());
gem = factory.createRandomGem();
assertEquals("does not return Gem of type ruby", RUBY, gem.getType());
gem = factory.createRandomGem();
assertEquals("does not return Gem of type sapphire", SAPPHIRE, gem
.getType());
}*/
E' chiaro che fallisca visto che la factory è creata nel setup() con un MockRandomGenerator cui è stato fornito il seguente indice di valori:
private final int randomIntArray[] = { 4, 0, 4, 0, 0, 1 };
Questi valori corrispondono alla creazione in sequenza di un topazio, un diamante, un topazio, un diamante, un diamante, un rubino...basta modificare i tipi di gemme nel test e passa nuovamente.
Direi quindi che lo strano codice (forse rimasto da una precedente gestione in cui nello stesso array vi erano sia tipi di gemme che chest) può essere eliminato :)
EDIT: Ho eliminato il codice in bold ed anche il metodo resetGemExtraction(), che in pratica non serviva più a nulla eliminato quell'if nel createRandomGem().
Committato.
Memory Leak:
Nel fare i test sulle probabilità ho avuto occasione di creare parecchie gemme, ed ho quindi notato un consumo di circa 1 GB di RAM per creare 10.000 gemme....si tratta di ben 100kb a gemma :)
Creavo le gemme con un questo codice:
for (int x= 0 ; x < 100000;x++)
{
Gem gemma = gemFactory.createRandomDroppable();
gemma.cleanup();
}
Ho fatto partire una micro test sul profiler con circa 20000 gemme. Ed in effetti il leak è presente e anche mooolto evidente. Questa è la situazione dopo circa 3000 gemme.
http://img217.imageshack.us/img217/34/leak3ks.jpg (http://imageshack.us)
Non ho idea di dove sia il problema, anche perché sto profiler mi è totalmente nuovo, ma a naso penso sia dovuto dalle routine di log o qualcosa che ha a che fare con le stringhe. 142000 AbstractStringBuilder, 182000 String.
ciao ;)
Grandissimo, BD :)
Il problema della frequenza non è tanto nella percentuale, dato che a ridurla ulteriormente sarebbero TROPPO rare, quanto nel fatto che la randomizzazione dovrebbe essere controllata verso il basso (ovvero, ci vorrebbe un limite minimo per l'intervallo tra una flashing gem e l'altra).
Diluire ulteriormente la sua occorrenza significa che in diverse partite potrebbe non saltare mai fuori, ed avremmo il problema opposto.
è fattibile senza troppi problemi(basta mettere un contatore in gemFactory)
Ho fatto partire una micro test sul profiler con circa 20000 gemme. Ed in effetti il leak è presente e anche mooolto evidente. Questa è la situazione dopo circa 3000 gemme.
Non ho idea di dove sia il problema, anche perché sto profiler mi è totalmente nuovo, ma a naso penso sia dovuto dalle routine di log o qualcosa che ha a che fare con le stringhe. 142000 AbstractStringBuilder, 182000 String.
ciao ;)
le stringhe in java vengono passate per copia(l'ho scoperto meno di un mese fa, ed è da un anno che lavoro su java :asd:)
Allo stato attuale, invece, il gioco considera come crush anche quando, posizionando una coppia di bauli, vengono cancellate due gemme di colore diverso già ferme. Questo non ha senso, dato che la seconda cancellazione non è conseguenza della prima.
in teoria nn dovrebbe essere cosi, provo a scrivere un test(ma secondo me cè gia)
in teoria nn dovrebbe essere cosi, provo a scrivere un test(ma secondo me cè gia)
public void testDoubleCrush()
{
//int delayCrush = config.getInteger("DelayBetweenCrushes");
insertAndUpdate(createGem(DIAMOND), 13, 1);
insertAndUpdate(createGem(EMERALD), 13, 2);
insertAndUpdate(createGem(DIAMOND_CHEST), 12, 1);
insertAndUpdate(createGem(EMERALD_CHEST), 12, 2);
insertAndStopGemsPair();
makeAllGemsFall();
controller.update(timer);
assertEquals(2, grid.getNumberOfGems());
assertEquals(2, grid.getCrushedGemsCounter());
assertEquals(1, grid.getChainCounter());
}
fallisce sul getChainCounter, che infatti ritorna 2 :|
Trovata la magagna. Texture.cleanup non funziona.
public void cleanup()
{
if(texID != 0)
{
final IntBuffer textures = BufferUtils.createIntBuffer(16);
textures.put(texID);
glDeleteTextures(textures);
texID = 0;
System.out.println("cancellata!");
}
else
{
System.out.println("mierda!");
}
loaded = false;
}
Stampa sempre e solo l'imprecazione perchè texID è sempre 0.
ciao ;)
^TiGeRShArK^
18-03-2006, 18:11
mmm..
e km mai si ritrova texid sempre a zero?:mbe:
mmm..
e km mai si ritrova texid sempre a zero?:mbe:
Non ho mai scritto niente in opengl in vita mia. Dobbiamo aspettare qualche esperto. Anche perché questa parte del codice è stata scritta assolutamente non seguendo il TDD. :nonsifa:
ciao ;)
Topazi Rari:EDIT: Ho eliminato il codice in bold ed anche il metodo resetGemExtraction(), che in pratica non serviva più a nulla eliminato quell'if nel createRandomGem().
Committato.
Ottima analisi e ottimo lavoro :)
Mi piace che dopo molto tempo che non hai guardato il codice ti e' stato relativamente facile andare a scovare il problema delle probabilita' dei topazi.
fallisce sul getChainCounter, che infatti ritorna 2 :|
Bel test. Hai tempo di farlo passare entro oggi? Voglio prendere una tag del codice prima di partire.
Non ho mai scritto niente in opengl in vita mia. Dobbiamo aspettare qualche esperto. Anche perché questa parte del codice è stata scritta assolutamente non seguendo il TDD. :nonsifa:
ciao ;)
Hmmm provo a dargli un'occhiata io a meno che Raffaele non si faccia avanti.
Ecco cosa accade a non scrivere i test, si perde piu' tempo dopo :)
Bel test. Hai tempo di farlo passare entro oggi? Voglio prendere una tag del codice prima di partire.
entro oggi pome forse, entro sera sicuro.
Anche perche in quella zona ci starebbe bene un bel refactoring(fare una classe abstract Crush, e 2 implementazione, una per le crush da chest e una quelle da flash). Poi in grid si fa un metodo che itera sulla griglia, a cui si passa una di queste classi.
non penso sia complicato, il piu saranno i test da modificare e aggiungere.
Trovata la magagna. Texture.cleanup non funziona.
[...]
Stampa sempre e solo l'imprecazione perchè texID è sempre 0.
ciao ;)
Ok. La situazione non è cosi drammatica. La cleanup non va solo nei test perché non c'è nessun Display reale istanziato e opengl non funziona senza. Probabilmente la grande occupazione di ram dei test che ha cercato di risolvere cionci era dovuta a questo problema.
ciao ;)
Trovata la magagna. Texture.cleanup non funziona.
public void cleanup()
{
if(texID != 0)
{
final IntBuffer textures = BufferUtils.createIntBuffer(16);
textures.put(texID);
glDeleteTextures(textures);
texID = 0;
System.out.println("cancellata!");
}
else
{
System.out.println("mierda!");
}
loaded = false;
}
Stampa sempre e solo l'imprecazione perchè texID è sempre 0.
ciao ;)
Dov'è la cleanup...non la trovo :bimbo:
Ok. La situazione non è cosi drammatica. La cleanup non va solo nei test perché non c'è nessun Display reale istanziato e opengl non funziona senza. Probabilmente la grande occupazione di ram dei test che ha cercato di risolvere cionci era dovuta a questo problema.
ciao ;)
Si puo' fare un mock che non allochi fisicamente la texture nei test (tanto non serve).
Si puo' fare un mock che non allochi fisicamente la texture nei test (tanto non serve).
Si può fare. Chi ci pensa ? :)
ciao ;)
entro oggi pome forse, entro sera sicuro.
Anche perche in quella zona ci starebbe bene un bel refactoring(fare una classe abstract Crush, e 2 implementazione, una per le crush da chest e una quelle da flash). Poi in grid si fa un metodo che itera sulla griglia, a cui si passa una di queste classi.
non penso sia complicato, il piu saranno i test da modificare e aggiungere.
non so se ce la faccio per stasera...in TestCrushBox molti test erano sbagliati e passavano per culo o per l'errore che avevo risolto(ora nn passano piu).
ho il problema che in playField.updatePlayField(), cè
if(isForTesting)
{
gridController.getGrid().updateCrushes();
updateCrushBox();
}
else
{
gridController.update(timer);
}
}
Io sono in testing e dovrei eseguire gridController.update(per far scendere le gemme dopo una crush), ma quel codice me lo impedisce(e nn mi sembra neanche una bella scelta, al max si fa un mock)
Quell'"isForTesting" deve sparire prima del commit.
Io non mi faccio 15 ore di volo domani sapendo che quella cosa e' nel nostro repository, non ce la faccio psicologicamente :(
Quell'"isForTesting" deve sparire prima del commit.
Io non mi faccio 15 ore di volo domani sapendo che quella cosa e' nel nostro repository, non ce la faccio psicologicamente :(
:rotfl: :rotfl: :rotfl: :rotfl:
Hai ragione fek...imponiti :D :D
^TiGeRShArK^
19-03-2006, 21:54
non so se ce la faccio per stasera...in TestCrushBox molti test erano sbagliati e passavano per culo o per l'errore che avevo risolto(ora nn passano piu).
ho il problema che in playField.updatePlayField(), cè
if(isForTesting)
{
gridController.getGrid().updateCrushes();
updateCrushBox();
}
else
{
gridController.update(timer);
}
}
Io sono in testing e dovrei eseguire gridController.update(per far scendere le gemme dopo una crush), ma quel codice me lo impedisce(e nn mi sembra neanche una bella scelta, al max si fa un mock)
ehm..
l'avevo inserita io quella parte di codice xkè mi serviva fare direttamente l'update crushes perkè altrimenti richiamando playField.update richiamava sempre gridcontroller.update che non aggiornava le crushes.....
se ti serve quel metodo puoi sempre disabilitarlo settando playField.isForTesting(false);
l'alternativa per eliminarlo è cambiare la classe gridController in modo da testare correttamente anke le crushes quando siamo nei test...
Ma mi pare che anche lì la situazione sia abbastanza simile.. sempre se ho capito qualkosa del funzionamento di gridController....
ho risolto i problemi di testCrushBox, fatto i test nuovi(simili a quelli di testGemCrushing). Non so se riesco a far sparire quel isForTesting entro stanotte...e domani nn ci posso lavorare.
altra cosa, ho trovato forse un bug sulla sparizione delle crushbox:
le specifiche erano
Ogni volta che il valore del contatore interno a grid appena introdotto ha un valore è maggiore di uno il suo valore deve essere visualizzato usando le png apposite (non le texture dei font del punteggio!!!) alle coordinate x=-67 y=192 per il P1 e x=611 y=192 per il P2. La texture contenente il valore deve essere nascosta ogni volta che viene creata una nuova gemspair.
ora invece viene cancellata dopo che la successiva gemspair si blocca + il parametro crushBoxUpdateRate
ora ho commentato il test in testCrushBox testCrushBoxIsNotShownAfterTimeout, che falliva e poi bisogna vedere come testarlo.
Quell'"isForTesting" deve sparire prima del commit.
Io non mi faccio 15 ore di volo domani sapendo che quella cosa e' nel nostro repository, non ce la faccio psicologicamente :(
Vai e fatti onore al GDC che ha questi mascalzoni ci penso io. :D
ciao ;)
^TiGeRShArK^
19-03-2006, 23:05
ho risolto i problemi di testCrushBox, fatto i test nuovi(simili a quelli di testGemCrushing). Non so se riesco a far sparire quel isForTesting entro stanotte...e domani nn ci posso lavorare.
altra cosa, ho trovato forse un bug sulla sparizione delle crushbox:
le specifiche erano
ora invece viene cancellata dopo che la successiva gemspair si blocca + il parametro crushBoxUpdateRate
ora ho commentato il test in testCrushBox testCrushBoxIsNotShownAfterTimeout, che falliva e poi bisogna vedere come testarlo.
mmm...
a quanto avevo capito erano cambiate le specifiche.
Non andava bene ke sparissi dopo l'apparizione della nuova coppia di gemme, ma bisognava configurare un timeout da file di configurazione....
^TiGeRShArK^
19-03-2006, 23:12
mmm...
infatti ricordavo bene:
2. Le png delle combo vengono nascoste appena viene creata una nuova gemspair invece che essere mostrati per un tempo fisso
era nella sezione bugs della storia 12.1 quindi deve essere visualizzata x un tempo fisso anzikè essere nascosta alla nascita della nuova coppia.
mmm...
infatti ricordavo bene:
era nella sezione bugs della storia 12.1 quindi deve essere visualizzata x un tempo fisso anzikè essere nascosta alla nascita della nuova coppia.
ok, nn l'avevo trovato.
cmq il punto rimane da quale punto temporale far partire il tempo fisso.
Ora il timer parte da quando la gemspair successiva si ferma.
Io lo farei partire dall'ultimo aumento del CrushCounter(e fattibile mettendo una variabile dentro a crushBox che contiene il crushCounter, e controllando nel primo if del metodo updateCrushBox()(ci avevo gia provato come prova..)
cqm sono riuscito a toglie l'isForTesting, fra un po faccio tutto il commit
^TiGeRShArK^
19-03-2006, 23:27
ok, nn l'avevo trovato.
cmq il punto rimane da quale punto temporale far partire il tempo fisso.
Ora il timer parte da quando la gemspair successiva si ferma.
Io lo farei partire dall'ultimo aumento del CrushCounter(e fattibile mettendo una variabile dentro a crushBox che contiene il crushCounter, e controllando nel primo if del metodo updateCrushBox()(ci avevo gia provato come prova..)
cqm sono riuscito a toglie l'isForTesting, fra un po faccio tutto il commit
ah...allora avevo sbagliato io ad inserirlo...
ero convinto di averlo fatto partire dopo l'inserimento della successiva coppia di gemme che corrisponde alla fine della crush.....:fagiano:
segnalo un altra cosa.
Cè ancora da decidere il comportamento di CrushedGemsCounter nei confronti delle gemme crushate da una flash(influenza le incoming stone avversarie).
ah...allora avevo sbagliato io ad inserirlo...
ero convinto di averlo fatto partire dopo l'inserimento della successiva coppia di gemme che corrisponde alla fine della crush.....:fagiano:
il codice si basava su quando veniva azzerato il chaincounter, ma questo viene azzerato quando la gemsPair tocca "terra" (non avevo trovato altro posto in cui metterlo).
cmq ho sistemato tutto, rimane fuori il test sul delay del crushBox che è commentato.
Ora devo riuscire a far girare la build di ant per il checkstyle...cazzo nn mi va
fatto finalmente il commit.
fek puoi rilassarti in vista del GDC :cool:
^TiGeRShArK^
20-03-2006, 08:56
cmq ho sistemato tutto, rimane fuori il test sul delay del crushBox che è commentato.
ehm...
è proprio per quello ke ho inserito isForTesting... bisognerebbe trovare un modo x testarlo... ma mi sa ke si dovrebbe cambiare qualke cosa in gridController a okkio...
cmq non mi ricordo molto xkè quel maledetto task l'avevo finito alle 4 e 30 di notte e ho rimosso tutto dal cervello poi :p
Quell'"isForTesting" deve sparire prima del commit.
Io non mi faccio 15 ore di volo domani sapendo che quella cosa e' nel nostro repository, non ce la faccio psicologicamente :(
15 ore? :o
Oggi torno ufficialmente attivo :)
Ho trovato un bug (vedere allegato)
(come non detto tutto a posto :) )
segnalo un altra cosa.
Cè ancora da decidere il comportamento di CrushedGemsCounter nei confronti delle gemme crushate da una flash(influenza le incoming stone avversarie).
Le gemme cancellate da una flashing gem non devono influenzare le incoming stone del'avversario.
ciao ;)
Io lo farei partire dall'ultimo aumento del CrushCounter(e fattibile mettendo una variabile dentro a crushBox che contiene il crushCounter, e controllando nel primo if del metodo updateCrushBox()(ci avevo gia provato come prova..)
Questo è esattamente quello che voleva ottenere jocchan come comportamenteo finale. Visto che ci hai gia provato puoi pensarci tu? :)
ciao ;)
Oggi torno ufficialmente attivo :)
Quindi laureato ?!?!?
COMPLIMENTI .... :mano: :cincin: :mano: :cincin:
cdimauro
20-03-2006, 13:20
Ho appena effettuato l'update dal repository, ed eseguendo la build con Ant ottengo questo:
[junit] Testcase: testCrushAndFlashing(it.diamonds.tests.ignore.TestGemCrushing): FAILED
[junit] expected:<1> but was:<0>
[junit] junit.framework.AssertionFailedError: expected:<1> but was:<0>
[junit] at it.diamonds.tests.ignore.TestGemCrushing.testCrushAndFlashing(TestGemCrushing.java:30)
BUILD FAILED
C:\workspace\Diamonds\build.xml:97: Test it.diamonds.tests.ignore.TestGemCrushing failed
Quindi i test presenti in ignore vengono eseguiti (ma il problema non era stato risolto?).
Inoltre il gioco continua a darmi il problema di cui avevo parlato qualche giorno fa.
Mi studio un po' SDL e vedo se riesco a tirare fuori una versione di Diamonds che la usa al posto di lwjgl...
Cesare, io attulmente non ho nessun test in ignore :confused:
Ho provato anche a copiare un test in ignore, ma come previsto non viene eseguito :boh:
cdimauro
20-03-2006, 13:59
Grazie per l'informazione, Riccardo. Ho eseguito il checkout del progetto, e adesso la build con Ant funziona perfettamente.
In compenso provando ad eseguire Game.java mi dà sempre:
"java.lang.NoClassDefFoundError: and Exception in thread "main"" :muro:
Il path è impostato correttamente, e infatti è possibile lanciare java, javaw e javac. Ho provato pure da shell, ma niente; anche impostando
set CLASS_PATH="C:\Program Files (x86)\Java\jdk1.5.0_06"
come suggerito su alcune pagine trovate cercando con Google la possibile causa di questo problema. :(
Aggiungi la directory . al classpath...
cdimauro
20-03-2006, 14:46
Con:
set CLASS_PATH=".;C:\Program Files (x86)\Java\jdk1.5.0_06"
eseguito da dentro
C:\Documents and Settings\Cesare\workspace\Diamonds\bin\it\diamonds
non funziona ancora.
C'è un file .classpath dentro il workspace, e questo è il suo contenuto:
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="src" path="src"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="lib" path="lib/junit.jar"/>
<classpathentry kind="lib" path="lib/easymock.jar"/>
<classpathentry kind="lib" path="lib/jar/lwjgl.jar"/>
<classpathentry kind="lib" path="lib/jar/lwjgl_devil.jar"/>
<classpathentry kind="lib" path="lib/jar/lwjgl_util.jar"/>
<classpathentry kind="output" path="bin"/>
</classpath>
Ti riferisci a questo? E come dovrei cambiarlo, eventualmente?
^TiGeRShArK^
20-03-2006, 14:59
ma ti da semère class not found???
Per quanto riguarda il classpath dovresti settarlo anke a bin/debug...
in windows si setta nel file diamonds.bat... in linux nn ho idea e ora nn posso vedere ke sono al lavoro e nn ho accesso al repository...
cmq verifica la presenza di bin/debug in quello script e dovrebbe andare...
cdimauro
20-03-2006, 15:07
Lanciando diamonds.bat il problema è risolto. :)
Come dovrei cambiare il file .classpath per far funzionare Game.java da dentro Eclipse?
P.S. Anch'io sto usando Windows (XP x64). :D
^TiGeRShArK^
20-03-2006, 17:02
Lanciando diamonds.bat il problema è risolto. :)
Come dovrei cambiare il file .classpath per far funzionare Game.java da dentro Eclipse?
P.S. Anch'io sto usando Windows (XP x64). :D
ah buono :D
per lanciarlo da eclipse dovrebbe partire da solo se hai settato nel path la lib delle dll di lwgl e hai importato nel progetto tutte le librerie corrette se non erro...
Questo è esattamente quello che voleva ottenere jocchan come comportamenteo finale. Visto che ci hai gia provato puoi pensarci tu? :)
ciao ;)
Le gemme cancellate da una flashing gem non devono influenzare le incoming stone del'avversario.
roger per entrambe, mi ci metto domani sera
cdimauro
21-03-2006, 07:13
ah buono :D
per lanciarlo da eclipse dovrebbe partire da solo se hai settato nel path la lib delle dll di lwgl e hai importato nel progetto tutte le librerie corrette se non erro...
Niente da fare. Ho provato a:
- impostare VM arguments mettendo -cp e il classpath che si trova nel file batch;
- aggiungere tutte le entry (a parte ".": non c'è stato verso) nelle user entries del tab Classpath;
- creare la variabile d'ambiente CLASSPATH col valore preso dal file batch;
- settare le opzioni "Main class" del tab main;
- cercare informazioni su internet.
:(
Da Eclipse non posso né eseguire Game.java né tanto meno debuggarlo. :cry:
Come se non bastasse, anche da shell ho comunque il problema che il gioco mi genera l'eccezione di invalid pixel format. :muro: :muro: :muro:
roger per entrambe, mi ci metto domani sera
sistemati entrambi, e in mezzo ci ho messo un refactoring. Ho snellito grid togliendo la logica delle crush, e creando 2 action(flash e chest) che ereditano da una action abstract.
Ora il codice risulta:
public void updateCrushes()
{
forEachGem(new CrushByFlashAction(this));
CrushByChestAction crushByChestAction = new CrushByChestAction(this);
forEachGem(crushByChestAction);
crushedGemsCounter = crushByChestAction.getCrushedGemsCounter();
if(crushByChestAction.isCrushed())
{
chainCounter++;
}
}
tutti i test hanno continuato a passare(tranne alcuni coinvolti dalle modifiche di cui sopra), in grid ho dovuto solo esporre un metodo pubblico in piu getAllGemOfType().
In teoria tutto il codice è testato, ma devo aggiungere dei test per le nuove classi action (metodi pubblici e protected dell'abstract...)e il metodo divenuto pubblico, e penso di farlo domani(assieme al commit).
ho notato che anche il metodo applyon delle altre action non è sempre testato...
altra modifica, ho cambiato getAdiacentCrushableGem in modo che ritorni la lista di tutte le gemme da crushare in caso di chest(usando la ricorsione). Prima questo lavoro veniva fatto durante la cancellazione, che ora nn fa altro che prendere una lista di gemme da cancellare e le brasa via :)
Occhio che quella roba l'ho modificata col task 13.1.1... Appena trovo il tempo implemento le action per quello che rimane :)
mi appresto a fare sync e commit(spero nn sia un bagno di sangue, cmq ho creato una patch di sicurezza, se perdo tutto mi sparo :D )
non riesco a fare commit dal portatile....
vi lascio la patch delle modifiche che ho fatto, se qualcuno vuole provarla(e committarla)
cmq stasera vedo di risolvere tutto....
non riesco a fare commit dal portatile....
vi lascio la patch delle modifiche che ho fatto, se qualcuno vuole provarla(e committarla)
cmq stasera vedo di risolvere tutto....
Ho dato un occhiata alla patch ma sembra mancare qualche pezzo. I nuovi file non sono presenti.
ciao ;)
Ho dato un occhiata alla patch ma sembra mancare qualche pezzo. I nuovi file non sono presenti.
ciao ;)
mi sono salvato preventivamente il workspace :cool:
dopo cene faccio sync e committo.
committato tutto, il sync non è stato semplice ma direi di avere allineato tutto(i test passano tutti)
Cavolaccio !!! :muro: :muro::muro: :muro:
Perchè il checkstyle non mi fa passare in alcun modo questo??
private static final
:help:
Forse perchè lo devi mettere prima di tutte i membri privati...
BINGO!!!! :winner:
Grazie mille cionci!! :mano: :cincin:
Problema risolto ;)
cdimauro
24-03-2006, 13:24
Il motivo per cui appaiono 2 dialog box in caso di eccezioni è che ne vengono sollevate 2, una dentro Game.createGame() e una dentro game.startGame(); nel main.
In entrambi i metodi è presente una try / catch per intrappolare le eccezioni, visualizzare il dialog e creare il file di log.
Io direi di spostare questo try / catch soltanto nel main(), in modo che la prima eccezione venga intrappolata e non venga dato seguito all'esecuzione, terminandola.
D'altra parte non ha senso continuare eseguendo startGame(), quando già s'è verificata un'eccezione (grave) in createGame().
Che ne dite?
Il motivo per cui appaiono 2 dialog box in caso di eccezioni è che ne vengono sollevate 2, una dentro Game.createGame() e una dentro game.startGame(); nel main.
In entrambi i metodi è presente una try / catch per intrappolare le eccezioni, visualizzare il dialog e creare il file di log.
Io direi di spostare questo try / catch soltanto nel main(), in modo che la prima eccezione venga intrappolata e non venga dato seguito all'esecuzione, terminandola.
D'altra parte non ha senso continuare eseguendo startGame(), quando già s'è verificata un'eccezione (grave) in createGame().
Che ne dite?
Perfettamente d'accordo. :)
ciao ;)
cdimauro
24-03-2006, 13:34
Me ne occupo appena Spartacus ritorna in funzione.
Spero anche di risolvere il problema che ho con Eclipse, per tornare pienamente operativo.
cdimauro
24-03-2006, 14:50
Fatto. ;)
cdimauro
24-03-2006, 15:41
Doppio post. :(
cdimauro
24-03-2006, 15:42
Finalmente mi funziona anche Eclipse!!! :D
Rispetto a quanto riportato nei primi messaggi di questo thread, ho cambianto VM Arguments in
-Djava.library.path=lib/win32
e adesso va tutto alla perfezione. :p
Adesso devo "soltanto" risolvere il problema col pixel format errato, che non mi fa partire il gioco. :muro:
Adesso devo "soltanto" risolvere il problema col pixel format errato, che non mi fa partire il gioco. :muro:
Solo ?!!?!? :sofico:
Hai provato a cambiare i driver ?
DanieleC88
24-03-2006, 15:49
Adesso devo "soltanto" risolvere il problema col pixel format errato, che non mi fa partire il gioco. :muro:
Di preciso che errore da'? I pixel format erano il mio incubo su Windows... :(
cdimauro
24-03-2006, 16:02
Solo ?!!?!? :sofico:
Hai provato a cambiare i driver ?
GRRRRR :)
No, questo non l'ho fatto, perché richiederebbe il modding dei Catalyst (Ati non supporta le schede < Radeon 9500 per Windows XP x64).
E' un'operazione che ho già fatto io tempo addietro, e dovrei provare in effetti (richiede un po' di tempo di smanettamento).
Intanto mi sto studiando SDL per vedere se posso modificare Diamonds per usare questa libreria e vedere se il problema si risolve.
Altri programmi OpenGL o altri demo con la stessa combinazione di librerie che usiamo ti funzionano ?
cdimauro
24-03-2006, 16:09
Di preciso che errore da'? I pixel format erano il mio incubo su Windows... :(
A chi lo dici. :(
Ecco qua http://www.hwupgrade.it/forum/showpost.php?p=11657749&postcount=1014
cdimauro
24-03-2006, 16:12
Altri programmi OpenGL o altri demo con la stessa combinazione di librerie che usiamo ti funzionano ?
Mai provato e non ne conosco.
Intanto scarico qualche demo OpenGL, per vedere se funziona (difficile, con XP x64, ma ci provo lo stesso).
Così vedo se è un problema di OpenGL o soltanto di LWJGL. :cool:
cdimauro
24-03-2006, 16:56
Ho scaricato la demo di Quake 3 Arena e i demo Tirtanium e Stars e funzionano.
Il primo gira perfettamente ed è pure estremamente fluido (e vorrei ben vedere, visto che è un "rudere" :D), mentre gli altri sono un po' scattosi, ma comunque non presentano problemi.
Quindi non è un problema delle OpenGL.
A questo punto per esclusione dovrebbe essere un problema delle librerie LWJGL.
Appena ho un po' di tempo mi butto a capofitto sulle SDL e vedo cosa riesco a cavarne.
Prova questi: http://potatoland.com/code/gl/
questo test non passava:
public void testNotFormingBigGem()
{
insertBigGem(GemType.EMERALD_STONE, 12, 0, 13, 1);
grid.updateBigGems();
assertEquals(0, grid.numberOfBigGems());
}
L'ho fixato cambiando questo metodo:
private boolean isGemNotValidForBigGem(Gem gem)
{
if(gem == null)
{
return true;
}
if(grid.isCellInABigGem(gem.getCellRow(), gem.getCellColumn()))
{
return true;
}
if(gem.getType().isChest() || gem.getType().isStone())
{
return true;
}
return false;
}
questo test non passava:
public void testNotFormingBigGem()
{
insertBigGem(GemType.EMERALD_STONE, 12, 0, 13, 1);
grid.updateBigGems();
assertEquals(0, grid.numberOfBigGems());
}
L'ho fixato cambiando questo metodo:
private boolean isGemNotValidForBigGem(Gem gem)
{
if(gem == null)
{
return true;
}
if(grid.isCellInABigGem(gem.getCellRow(), gem.getCellColumn()))
{
return true;
}
if(gem.getType().isChest() || gem.getType().isStone())
{
return true;
}
return false;
}
direi che non passa manco creando una biggem di flash(anche se penso sia un evento impossibile in game).
cmq direi che si puo fare un metodo isGem e usare quello.
appena il server torna up lo faccio
direi che non passa manco creando una biggem di flash(anche se penso sia un evento impossibile in game).
cmq direi che si puo fare un metodo isGem e usare quello.
appena il server torna up lo faccio
Non può avvenire :)
Molto probabilmente ho scovato un altro paio di bug.
Giocando ho preparato una crush da 4-5x ammucchiando diverse gemme e bauli. Dopo averla innescata, però, il contatore è arrivato ad un assurdo 8x (Astounding).
Questo perchè molto probabilmente c'è un errore di fondo nell'implementazione del conteggio delle crush (e probabilmente è anche colpa di come abbiamo impostato storia e task): a rigor di logica, il contatore della lunghezza deve aumentare solo se l'evento scatenante di una cancellazione è stato un'altra cancellazione.
Allo stato attuale, invece, il gioco considera come crush anche quando, posizionando una coppia di bauli, vengono cancellate due gemme di colore diverso già ferme. Questo non ha senso, dato che la seconda cancellazione non è conseguenza della prima.
Quindi, bisogna vedere di sistemare il tutto in modo da considerare, per le crush, solo i pezzi che cadono per riempire i vuoti. Ne parlerò con Vicius, e probabilmente sarà uno dei task per il prossimo ciclo.
L'altro bug fondamentale riguarda il contatore mostrato sotto l'area di gioco dell'avversario: dopo la (lunga) combo di cui sopra, il contatore in questione segnava il valore di 5. Avevo già notato delle incoerenze, e questo evento ne è stato la conferma. Direi che bisogna dare un'occhiata al suo funzionamento ;)
Questi due bug sono ancora presenti?
Chi se ne occupa?
Joc puoi formalizzare il primo bug? Puoi postare la configurazione di gemme che hai testato?
Questi due bug sono ancora presenti?
Chi se ne occupa?
dovrei averli gia risolti, cerco i test.
dovrei averli gia risolti, cerco i test.
per il primo bug
public void testDoubleCrushInOneTurn()
{
insertAndUpdate(createGem(DIAMOND), 13, 1);
insertAndUpdate(createGem(EMERALD), 13, 2);
insertAndUpdate(createGem(DIAMOND_CHEST), 12, 1);
insertAndUpdate(createGem(EMERALD_CHEST), 12, 2);
insertAndStopGemsPair();
makeAllGemsFall();
controller.update(timer);
assertEquals(2, grid.getNumberOfGems());
assertEquals(2, grid.getCrushedGemsCounter());
assertEquals(1, grid.getChainCounter());
}
per il secondo bug, mi sa che la logica dei test segue proprio del bug, nel senso che dopo ogni crush il gemcrushed counter viene resettato.
questo test sembra dimostrarlo:
public void testCrushesDelay()
{
int delayCrush = config.getInteger("DelayBetweenCrushes");
insertAndUpdate(createGem(EMERALD), 13, 2);
insertAndUpdate(createGem(DIAMOND), 12, 2);
insertAndUpdate(createGem(EMERALD), 11, 2);
insertAndUpdate(createGem(DIAMOND), 10, 2);
insertAndUpdate(createGem(DIAMOND_CHEST), 9, 2);
insertAndUpdate(createGem(EMERALD_CHEST), 8, 2);
insertAndUpdate(createGem(DIAMOND_CHEST), 7, 2);
insertAndUpdate(createGem(EMERALD_CHEST), 6, 2);
insertAndStopGemsPair();
makeAllGemsFall();
controller.update(timer);
makeAllGemsFall();
oneStepForward();
for(int i = 1; i < delayCrush; i++)
{
checkCrush("at iteration:" + i, 8, 1, 1);
oneStepForward();
}
checkCrush("second crush:", 6, 1, 2);
makeAllGemsFall();
for(int i = 0; i < delayCrush; i++)
{
checkCrush("at iteration:" + i, 6, 1, 2);
oneStepForward();
}
checkCrush("third crush:", 4, 1, 3);
makeAllGemsFall();
for(int i = 0; i < delayCrush; i++)
{
checkCrush("at iteration:" + i, 4, 1, 3);
oneStepForward();
}
checkCrush("final update:", 2, 1, 4);
}
private void checkCrush(String string, int numberOfGems,
int crushedGemsCounter, int chainCounter)
{
assertEquals(string, numberOfGems, grid.getNumberOfGems());
assertEquals(string, crushedGemsCounter, grid.getCrushedGemsCounter());
assertEquals(string, chainCounter, grid.getChainCounter());
}
il crushedGemCounter viene aggiornato ogni volta con il numero di gem crushate dell'ultima crush, e non tiene conto di quelle precedenti della catena.
Sto iniziando a dare un'occhiata a GridController per effettuare del refactoring e sono già incappato in un problema:
Le condizioni in GameLoop per mostrare il messaggio di GameOver sono completamente non testate:
Cambiando il seguente metodo in questo modo:
private void checkAndShowGameOverMessage(PlayField field)
{
return;
}
La build continua ad essere verde!
Intanto ho aggiunto GameOverBox (testato)... Forse potrà aiutare :)
cdimauro
27-03-2006, 08:20
Prova questi: http://potatoland.com/code/gl/
Niente da fare:
C:\T\lwjgl_demos_win32>java -cp .;lwjgl.jar; GLApp_DemoModel
-- listing properties --
displayColorBits=32
displayWidth=1024
depthBufferBits=24
displayFrequency=60
fullScreen=yes
displayHeight=768
GLApp.initDisplay(): Current display mode is 1280 x 1024 x 32 @85Hz
GLApp.initDisplay(): Setting display mode to 1024 x 768 x 32 @60Hz with pixel depth = 24
GLApp.initDisplay(): Failed to create OpenGL window: org.lwjgl.LWJGLException: Could not find a valid pixel format
A LWJGL non piace molto XP x64. :(
C'è da dire che l'ho provato su due macchine, ma entrambe con schede video Ati (però una coi driver "standard" di XP x64 e l'altra coi miei Catalyst 5.7 modificati). Purtroppo non ho macchine con XP x64 e qualche GeForce per capire se è un problema della piattaforma Ati o di XP x64 in generale.
In ogni caso è un problema che devo risolvere in qualche modo.
Questo week-end mi sono studiato le librerie SDL e il porting per Java (SDLJava). Mi sembrano molto semplici da usare.
Vorrei realizzare un branch di Diamonds: c'è qualcuno che mi può dare qualche indicazione su come fare? Il mio obiettivo sarebbe quello di avere la maggior parte dei file di Diamonds in comune con il branch principale ("trunk". Prima avevo scritto "trunks": Diamonds versione Sayan :D :D :D), e quindi potendo usufruire dei file che vengono man mano revisionati, e cambiarne soltanto alcuni per il mio branch (da engine, engine.audio, engine.input ed engine.video). E' possibile farlo? Come potrei procedere?
Grazie anticipatamente. :)
Vorrei realizzare un branch di Diamonds: c'è qualcuno che mi può dare qualche indicazione su come fare? Il mio obiettivo sarebbe quello di avere la maggior parte dei file di Diamonds in comune con il branch principale ("trunk". Prima avevo scritto "trunks": Diamonds versione Sayan :D :D :D), e quindi potendo usufruire dei file che vengono man mano revisionati, e cambiarne soltanto alcuni per il mio branch (da engine, engine.audio, engine.input ed engine.video). E' possibile farlo? Come potrei procedere?
Grazie anticipatamente. :)
È piuttosto facile. Nella vista Svn repository in eclipse seleziona trunk. Clicca con il destro e poi Branch/Tag... Infine modifica To Url in modo che punti in /branches/qualcosa
ciao ;)
cdimauro
27-03-2006, 13:07
Tutto OK. Grazie!!! :)
cdimauro
28-03-2006, 15:15
public void drawQuad(Point position, float width, float height, Texture texture, Rectangle textureRect)
è un metodo pubblico di Engine, ma non è presente nessun test che ne faccia capire cosa dovrebbe fare.
Qualcuno potrebbe darmi una mano a capire la relazione fra position, width & height e Rectangle?
Da quel che ho capito, dovrebbe essere:
position - angolo in alto a sinistra dell'oggetto da tracciare;
width & height - dimensione dell'oggetto;
Rectangle - Porzione della texture da usare per tracciare l'oggetto (ma le coordinate di che tipo sono? Angolo in alto a sinistra + angolo in basso a destra rispetto alla texture?).
Se è così, in pratica la porzione di texture identificata dal rettangolo verrebbe "zoomata" (se width & height sono diversi da texture.width & texture.height) nello schermo a partire da position.
Per tutte le coordinate usate l'origine degli assi è sempre nell'angolo in alto a sinistra, e con l'asse delle y invertito rispetto al piano cartesiano (in pratica le classiche coordinate raster)?
ragazzi, sotto windows sul mio portatile diamonds lo vedo così :(
http://img74.imageshack.us/img74/3275/diamonds8ic.th.jpg (http://img74.imageshack.us/my.php?image=diamonds8ic.jpg)
appena ha finito Cesare potresti provare con il porting SDL :)
si, penso che la maggior parte di problemi siano dovuti a lwjgl......
cdimauro
29-03-2006, 11:49
Quando ci sarà qualcosa di funzionante (sotto Windows al momento) vi farò sapere. :)
DanieleC88
29-03-2006, 12:29
appena ha finito Cesare potresti provare con il porting SDL :)
Io l'avevo detto da subito di usare SDL... :p
cdimauro
29-03-2006, 12:41
LWJGL o SDL è indifferente: l'importante è trovare una soluzione che permetta di far funzionare Diamonds sulla maggior parte delle macchine. ;)
P.S. Per adesso ho creato soltanto il branch SDL, ma non ho effettuato nessun commit. Preferisco lavorare in locale ed eseguire il commit quando avrò qualcosa di funzionante.
Niente da fare:
C:\T\lwjgl_demos_win32>java -cp .;lwjgl.jar; GLApp_DemoModel
-- listing properties --
displayColorBits=32
displayWidth=1024
depthBufferBits=24
displayFrequency=60
fullScreen=yes
displayHeight=768
GLApp.initDisplay(): Current display mode is 1280 x 1024 x 32 @85Hz
GLApp.initDisplay(): Setting display mode to 1024 x 768 x 32 @60Hz with pixel depth = 24
GLApp.initDisplay(): Failed to create OpenGL window: org.lwjgl.LWJGLException: Could not find a valid pixel format
A LWJGL non piace molto XP x64. :(
C'è da dire che l'ho provato su due macchine, ma entrambe con schede video Ati (però una coi driver "standard" di XP x64 e l'altra coi miei Catalyst 5.7 modificati). Purtroppo non ho macchine con XP x64 e qualche GeForce per capire se è un problema della piattaforma Ati o di XP x64 in generale.
In ogni caso è un problema che devo risolvere in qualche modo.
Questo week-end mi sono studiato le librerie SDL e il porting per Java (SDLJava). Mi sembrano molto semplici da usare.
Vorrei realizzare un branch di Diamonds: c'è qualcuno che mi può dare qualche indicazione su come fare? Il mio obiettivo sarebbe quello di avere la maggior parte dei file di Diamonds in comune con il branch principale ("trunk". Prima avevo scritto "trunks": Diamonds versione Sayan :D :D :D), e quindi potendo usufruire dei file che vengono man mano revisionati, e cambiarne soltanto alcuni per il mio branch (da engine, engine.audio, engine.input ed engine.video). E' possibile farlo? Come potrei procedere?
Grazie anticipatamente. :)
Non c'è alcun problema con XP x64. Io lo uso da 1 anno e tutto funziona perfettamente. Al limite i problemi sono dovuti ai driver OpenGL, ma con schede ATI e NVIDIA non dovrebbero esserci problemi. Io le provo spesso e Diamonds non ha mai avuto problemi. Tra l'altro abbiamo reso Diamonds compatibile OpenGL 1.1, cioè per capirci dovrebbe funzionare sotto Windows anche senza installare un driver OpenGL ICD, ma semplicemente con quello software di Windows.
Se volete vi aiuto a risolvere questo problema, però ho bisogno che chi ha problemi faccia alcune prove.
P.S. Il problema, in ogni caso, non è LWJGL, ma al limite la configurazione OpenGL perché LWJGL è una banale conversioni da chiamate Java a chiamate C via JNI (Java Native Interface) a OpenGL.
ragazzi, sotto windows sul mio portatile diamonds lo vedo così :(
http://img74.imageshack.us/img74/3275/diamonds8ic.th.jpg (http://img74.imageshack.us/my.php?image=diamonds8ic.jpg)
Puoi dirmi che scheda video ha il tuo portatile?
cdimauro
29-03-2006, 12:56
Non c'è alcun problema con XP x64. Io lo uso da 1 anno e tutto funziona perfettamente. Al limite i problemi sono dovuti ai driver OpenGL, ma con schede ATI e NVIDIA non dovrebbero esserci problemi. Io le provo spesso e Diamonds non ha mai avuto problemi.
Purtroppo ho provato su 2 macchine con XP x64 e schede video Ati, ed entrambe presentano gli stessi problemi (che ho riportato).
Le schede sono una 8500BBA, coi Catalyst 5.7 da me modificati e una (Sapphire mi pare) 9250SE coi driver standard di XP x64.
Tra l'altro abbiamo reso Diamonds compatibile OpenGL 1.1, cioè per capirci dovrebbe funzionare sotto Windows anche senza installare un driver OpenGL ICD, ma semplicemente con quello software di Windows.
Quindi nel macchina coi Catalyst userebbe l'ICD e nell'altro no.
Se volete vi aiuto a risolvere questo problema, però ho bisogno che chi ha problemi faccia alcune prove.
A disposizione (non chiedevo altro :)).
Puoi dirmi che scheda video ha il tuo portatile?
geforce 6200 go tc 64 MB
Purtroppo ho provato su 2 macchine con XP x64 e schede video Ati, ed entrambe presentano gli stessi problemi (che ho riportato).
Le schede sono una 8500BBA, coi Catalyst 5.7 da me modificati e una (Sapphire mi pare) 9250SE coi driver standard di XP x64.
Quindi nel macchina coi Catalyst userebbe l'ICD e nell'altro no.
A disposizione (non chiedevo altro :)).
Ah ok, quindi si tratta di schede precedenti a R300.
Quando si avvia Diamonds in console vengono stampate i pixel format disponibili e il nome del driver.
Ad esempio a me con una X1800 XL esce:
Display Adapter: ati2dvag
List of available display modes:
512 x 384 x 16 @60Hz
848 x 480 x 32 @60Hz
640 x 480 x 16 @60Hz
720 x 480 x 32 @60Hz
640 x 400 x 32 @60Hz
720 x 576 x 16 @59Hz
400 x 300 x 16 @60Hz
1280 x 960 x 16 @60Hz
720 x 576 x 16 @60Hz
1024 x 768 x 16 @60Hz
1280 x 768 x 16 @60Hz
400 x 300 x 32 @60Hz
512 x 384 x 32 @60Hz
720 x 480 x 16 @60Hz
640 x 400 x 16 @60Hz
1280 x 1024 x 16 @60Hz
1280 x 720 x 16 @60Hz
1152 x 864 x 32 @60Hz
1024 x 768 x 32 @60Hz
848 x 480 x 16 @60Hz
720 x 576 x 32 @60Hz
320 x 240 x 16 @60Hz
800 x 600 x 32 @60Hz
1280 x 768 x 32 @60Hz
320 x 240 x 32 @60Hz
1280 x 1024 x 32 @60Hz
800 x 600 x 16 @60Hz
720 x 576 x 32 @59Hz
1280 x 720 x 32 @60Hz
1152 x 864 x 16 @60Hz
320 x 200 x 16 @60Hz
320 x 200 x 32 @60Hz
1280 x 960 x 32 @60Hz
640 x 480 x 32 @60Hz
Best mode: 800 x 600 x 32 @60Hz
Mi dici cosa stampa a te?
P.S. Vale anche per CISC
cdimauro
29-03-2006, 14:18
Ecco qui:
Display Adapter: ati2dvag
List of available display modes:
512 x 384 x 16 @60Hz
320 x 240 x 16 @75Hz
1024 x 768 x 16 @72Hz
1600 x 1200 x 32 @60Hz
640 x 400 x 32 @75Hz
1280 x 1024 x 16 @70Hz
640 x 480 x 16 @75Hz
1280 x 960 x 16 @72Hz
1024 x 768 x 32 @85Hz
1280 x 960 x 32 @75Hz
800 x 600 x 32 @70Hz
1280 x 960 x 16 @60Hz
800 x 600 x 16 @85Hz
1024 x 768 x 16 @75Hz
400 x 300 x 32 @60Hz
800 x 600 x 16 @72Hz
1280 x 1024 x 16 @75Hz
1280 x 960 x 16 @70Hz
800 x 600 x 32 @56Hz
1920 x 1200 x 16 @60Hz
640 x 400 x 16 @60Hz
1280 x 1024 x 32 @85Hz
1024 x 768 x 32 @60Hz
1920 x 1440 x 32 @60Hz
1856 x 1392 x 16 @60Hz
800 x 600 x 32 @60Hz
320 x 240 x 32 @60Hz
1280 x 1024 x 32 @60Hz
1800 x 1440 x 16 @60Hz
1280 x 960 x 32 @85Hz
1920 x 1080 x 32 @60Hz
800 x 600 x 16 @75Hz
640 x 480 x 16 @72Hz
1024 x 768 x 16 @70Hz
1152 x 864 x 32 @85Hz
512 x 384 x 32 @75Hz
1152 x 864 x 16 @60Hz
1152 x 864 x 16 @70Hz
320 x 200 x 16 @60Hz
800 x 600 x 16 @70Hz
1280 x 1024 x 32 @70Hz
1792 x 1344 x 16 @60Hz
800 x 600 x 32 @72Hz
1920 x 1440 x 16 @60Hz
1856 x 1392 x 32 @60Hz
1280 x 1024 x 32 @75Hz
640 x 480 x 16 @60Hz
800 x 600 x 16 @56Hz
1920 x 1200 x 32 @60Hz
1152 x 864 x 32 @70Hz
640 x 400 x 32 @60Hz
1024 x 768 x 32 @70Hz
1280 x 960 x 16 @85Hz
400 x 300 x 16 @60Hz
640 x 400 x 16 @75Hz
1152 x 864 x 16 @75Hz
640 x 480 x 32 @75Hz
1024 x 768 x 16 @60Hz
1280 x 960 x 16 @75Hz
512 x 384 x 32 @60Hz
320 x 240 x 32 @75Hz
1024 x 768 x 32 @75Hz
512 x 384 x 16 @75Hz
1280 x 1024 x 16 @60Hz
400 x 300 x 16 @75Hz
1152 x 864 x 32 @60Hz
640 x 480 x 32 @72Hz
320 x 240 x 16 @60Hz
640 x 480 x 16 @85Hz
1280 x 960 x 32 @72Hz
800 x 600 x 16 @60Hz
800 x 600 x 32 @85Hz
400 x 300 x 32 @75Hz
1024 x 768 x 16 @85Hz
1280 x 960 x 32 @70Hz
320 x 200 x 32 @75Hz
1920 x 1080 x 16 @60Hz
320 x 200 x 16 @75Hz
800 x 600 x 32 @75Hz
1152 x 864 x 32 @75Hz
1152 x 864 x 16 @85Hz
1792 x 1344 x 32 @60Hz
1600 x 1200 x 16 @60Hz
1800 x 1440 x 32 @60Hz
1024 x 768 x 32 @72Hz
640 x 480 x 32 @85Hz
1280 x 1024 x 16 @85Hz
320 x 200 x 32 @60Hz
1280 x 960 x 32 @60Hz
640 x 480 x 32 @60Hz
Best mode: 800 x 600 x 32 @85Hz
Ecco qui:
Display Adapter: ati2dvag
List of available display modes:
512 x 384 x 16 @60Hz
320 x 240 x 16 @75Hz
1024 x 768 x 16 @72Hz
1600 x 1200 x 32 @60Hz
640 x 400 x 32 @75Hz
1280 x 1024 x 16 @70Hz
640 x 480 x 16 @75Hz
1280 x 960 x 16 @72Hz
1024 x 768 x 32 @85Hz
1280 x 960 x 32 @75Hz
800 x 600 x 32 @70Hz
1280 x 960 x 16 @60Hz
800 x 600 x 16 @85Hz
1024 x 768 x 16 @75Hz
400 x 300 x 32 @60Hz
800 x 600 x 16 @72Hz
1280 x 1024 x 16 @75Hz
1280 x 960 x 16 @70Hz
800 x 600 x 32 @56Hz
1920 x 1200 x 16 @60Hz
640 x 400 x 16 @60Hz
1280 x 1024 x 32 @85Hz
1024 x 768 x 32 @60Hz
1920 x 1440 x 32 @60Hz
1856 x 1392 x 16 @60Hz
800 x 600 x 32 @60Hz
320 x 240 x 32 @60Hz
1280 x 1024 x 32 @60Hz
1800 x 1440 x 16 @60Hz
1280 x 960 x 32 @85Hz
1920 x 1080 x 32 @60Hz
800 x 600 x 16 @75Hz
640 x 480 x 16 @72Hz
1024 x 768 x 16 @70Hz
1152 x 864 x 32 @85Hz
512 x 384 x 32 @75Hz
1152 x 864 x 16 @60Hz
1152 x 864 x 16 @70Hz
320 x 200 x 16 @60Hz
800 x 600 x 16 @70Hz
1280 x 1024 x 32 @70Hz
1792 x 1344 x 16 @60Hz
800 x 600 x 32 @72Hz
1920 x 1440 x 16 @60Hz
1856 x 1392 x 32 @60Hz
1280 x 1024 x 32 @75Hz
640 x 480 x 16 @60Hz
800 x 600 x 16 @56Hz
1920 x 1200 x 32 @60Hz
1152 x 864 x 32 @70Hz
640 x 400 x 32 @60Hz
1024 x 768 x 32 @70Hz
1280 x 960 x 16 @85Hz
400 x 300 x 16 @60Hz
640 x 400 x 16 @75Hz
1152 x 864 x 16 @75Hz
640 x 480 x 32 @75Hz
1024 x 768 x 16 @60Hz
1280 x 960 x 16 @75Hz
512 x 384 x 32 @60Hz
320 x 240 x 32 @75Hz
1024 x 768 x 32 @75Hz
512 x 384 x 16 @75Hz
1280 x 1024 x 16 @60Hz
400 x 300 x 16 @75Hz
1152 x 864 x 32 @60Hz
640 x 480 x 32 @72Hz
320 x 240 x 16 @60Hz
640 x 480 x 16 @85Hz
1280 x 960 x 32 @72Hz
800 x 600 x 16 @60Hz
800 x 600 x 32 @85Hz
400 x 300 x 32 @75Hz
1024 x 768 x 16 @85Hz
1280 x 960 x 32 @70Hz
320 x 200 x 32 @75Hz
1920 x 1080 x 16 @60Hz
320 x 200 x 16 @75Hz
800 x 600 x 32 @75Hz
1152 x 864 x 32 @75Hz
1152 x 864 x 16 @85Hz
1792 x 1344 x 32 @60Hz
1600 x 1200 x 16 @60Hz
1800 x 1440 x 32 @60Hz
1024 x 768 x 32 @72Hz
640 x 480 x 32 @85Hz
1280 x 1024 x 16 @85Hz
320 x 200 x 32 @60Hz
1280 x 960 x 32 @60Hz
640 x 480 x 32 @60Hz
Best mode: 800 x 600 x 32 @85Hz
Mi puoi scrivere il messaggio di errore che ottieni con Diamonds?
cdimauro
29-03-2006, 17:01
org.lwjgl.LWJGLException: Could not find a valid pixel format
E' stata selezionata una modalità a 32 bit (24 come valore specificato nel pixel format, nel sorgente).
org.lwjgl.LWJGLException: Could not find a valid pixel format
E' stata selezionata una modalità a 32 bit (24 come valore specificato nel pixel format, nel sorgente).
Non ti dice la chiamata che ha dato errore? La riga di codice in Diamonds dove è crashato.
ecco per me:
Display Adapter: nv4_disp
List of available display modes:
512 x 384 x 16 @60Hz
640 x 480 x 16 @60Hz
720 x 480 x 32 @60Hz
640 x 400 x 32 @60Hz
400 x 300 x 16 @60Hz
1024 x 768 x 16 @60Hz
400 x 300 x 32 @60Hz
512 x 384 x 32 @60Hz
768 x 576 x 16 @60Hz
720 x 480 x 16 @60Hz
640 x 400 x 16 @60Hz
1024 x 768 x 32 @60Hz
480 x 360 x 32 @60Hz
320 x 240 x 16 @60Hz
800 x 600 x 32 @60Hz
320 x 200 x 16 @60Hz
320 x 240 x 32 @60Hz
768 x 576 x 32 @60Hz
480 x 360 x 16 @60Hz
320 x 200 x 32 @60Hz
800 x 600 x 16 @60Hz
640 x 480 x 32 @60Hz
Best mode: 800 x 600 x 32 @60Hz
inoltre, quando chiudo il gioco cliccando sulla x della finestram mi esce un errore dell'applicazione javaw.exe. "L'istruzione a "0x0acaa2323" ha fatto riferimento alla memoria a "0xaltronumeroesadecimale". La memoria non poteva essere "read". "
ecco per me:
Display Adapter: nv4_disp
List of available display modes:
512 x 384 x 16 @60Hz
640 x 480 x 16 @60Hz
720 x 480 x 32 @60Hz
640 x 400 x 32 @60Hz
400 x 300 x 16 @60Hz
1024 x 768 x 16 @60Hz
400 x 300 x 32 @60Hz
512 x 384 x 32 @60Hz
768 x 576 x 16 @60Hz
720 x 480 x 16 @60Hz
640 x 400 x 16 @60Hz
1024 x 768 x 32 @60Hz
480 x 360 x 32 @60Hz
320 x 240 x 16 @60Hz
800 x 600 x 32 @60Hz
320 x 200 x 16 @60Hz
320 x 240 x 32 @60Hz
768 x 576 x 32 @60Hz
480 x 360 x 16 @60Hz
320 x 200 x 32 @60Hz
800 x 600 x 16 @60Hz
640 x 480 x 32 @60Hz
Best mode: 800 x 600 x 32 @60Hz
inoltre, quando chiudo il gioco cliccando sulla x della finestram mi esce un errore dell'applicazione javaw.exe. "L'istruzione a "0x0acaa2323" ha fatto riferimento alla memoria a "0xaltronumeroesadecimale". La memoria non poteva essere "read". "
:eek:
Che versione dei driver hai?
Hai mai avuto occasione di giocare a giochi OpenGL? Ad esempio Doom 3. Funzionano bene?
P.S. Che versione della JVM hai installato?
cdimauro
30-03-2006, 07:13
Non ti dice la chiamata che ha dato errore? La riga di codice in Diamonds dove è crashato.
La riga di codice è questa:
Display.create(new PixelFormat(24, 0, 0, 0, 0));
In GameLoop:
// TODO:Make Test
// inputReactor.addHandler(KeyEvent.ESCAPE,new EscapeCommandHandler(this));
cosa significa questo? Non doveva essere stato risolto il bug di ESCAPE che non andava? Continua a non andare!
In GameLoop:
// TODO:Make Test
// inputReactor.addHandler(KeyEvent.ESCAPE,new EscapeCommandHandler(this));
cosa significa questo? Non doveva essere stato risolto il bug di ESCAPE che non andava? Continua a non andare!
Questa cosa e' da fissare immediatamente e voglio un test che lanci un game loop, produca la pressione del tasto escape e controlli che il loop sia terminato. Chi se ne occupa?
In GameLoop:
// TODO:Make Test
// inputReactor.addHandler(KeyEvent.ESCAPE,new EscapeCommandHandler(this));
cosa significa questo? Non doveva essere stato risolto il bug di ESCAPE che non andava? Continua a non andare!
L' ho risolto io il bug. :D
Quella riga di codice risolve il problema...ma il problema è che non sono riuscito a testare quella riga!!! :muro:
GameLoop è vermante poco Test-Friendly :D
L' ho risolto io il bug. :D
Quella riga di codice risolve il problema...ma il problema è che non sono riuscito a testare quella riga!!! :muro:
GameLoop è vermante poco Test-Friendly :D
Mandami un messaggio su MSN che vediamo come fare :)
GameLoop è vermante poco Test-Friendly :D
Allora rendiamolo Test-Friendly :)
Stasera ci mettiamo al lavoro su GameLoop :)
La riga di codice è questa:
Display.create(new PixelFormat(24, 0, 0, 0, 0));
Prova a cambiare il 24 in 32.
[junit] Testsuite: it.diamonds.tests.TestGrid$1
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0,063 sec
[junit] Testcase: warning(junit.framework.TestSuite$1): FAILED
[junit] Class it.diamonds.tests.TestGrid$1 has no public constructor TestCase(String name) or TestCase()
[junit] junit.framework.AssertionFailedError: Class it.diamonds.tests.TestGrid$1 has no public constructor TestCase(String name) or TestCase()
la build è rossa !!
ma più che altro il failure è stranissimo !!! :muro:
cdimauro
31-03-2006, 07:46
ragazzi, sotto windows sul mio portatile diamonds lo vedo così :(
http://img74.imageshack.us/img74/3275/diamonds8ic.th.jpg (http://img74.imageshack.us/my.php?image=diamonds8ic.jpg)
Puoi provare col porting di Diamonds per SDL che ho finito?
cdimauro
31-03-2006, 08:01
Prova a cambiare il 24 in 32.
Non è cambianto niente. :(
[junit] Testsuite: it.diamonds.tests.TestGrid$1
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0,063 sec
[junit] Testcase: warning(junit.framework.TestSuite$1): FAILED
[junit] Class it.diamonds.tests.TestGrid$1 has no public constructor TestCase(String name) or TestCase()
[junit] junit.framework.AssertionFailedError: Class it.diamonds.tests.TestGrid$1 has no public constructor TestCase(String name) or TestCase()
la build è rossa !!
ma più che altro il failure è stranissimo !!! :muro:
Che strano errore...eppure a parte l'aggiunta di altri test non è cambiato niente in TestGrid...
in locale passa !!! E' stato cambiato qualcosa nel build file ?
Commentando i nuovi test aggiunti la build torna verde... E' un bel problema...
Quali test son stati commentati?
Gli ultimi aggiunti da thebol...
Comuqnue li ho spostati in un altro file e puntualmente il problema si ripresenta nella nuova classe...
Credo però di aver capito qual'è il problema...
package it.diamonds.tests;
import static it.diamonds.gems.GemType.*;
import junit.framework.TestCase;
import it.diamonds.Grid;
import it.diamonds.gems.Gem;
import it.diamonds.GemAction;
public class TestGridGemAction extends TestCase
{
public void testForEachGem()
{
Grid grid = Grid.createForTesting();
Gem gem = null;
GemAction gemActionTest = new GemAction()
{
public void applyOn(Gem gem)
{
gem.stop();
};
};
for(int i = grid.getNumberOfRows() - 1; i >= 0; i--)
{
for(int k = grid.getNumberOfColumns()- 1; k >= 0; k--)
{
gem = Gem.create(DIAMOND, 3500);
gem.setCellPosition(i,k);
grid.addGemToGrid(gem);
}
}
for(int i = grid.getNumberOfRows() - 1; i >= 0; i--)
{
for(int k = grid.getNumberOfColumns()- 1; k >= 0; k--)
{
assertTrue(gem.isFalling());
}
}
grid.forEachGem(gemActionTest);
for(int i = grid.getNumberOfRows() - 1; i >= 0; i--)
{
for(int k = grid.getNumberOfColumns()- 1; k >= 0; k--)
{
assertFalse(gem.isFalling());
}
}
}
public void testForEachGemNull()
{
Grid grid = Grid.createForTesting();
GemAction gemActionTest = new GemAction()
{
public void applyOn(Gem gem)
{
gem.stop();
};
};
try
{
grid.forEachGem(gemActionTest);
}
catch(NullPointerException e)
{
fail("the forEachGem call action for null gem");
}
}
}
Il problema secondo me sono quelle classi locali alle funzioni che fanno un po' impazzire JUnit...
Penso sia meglio revertare il commit finchè non riesce a farli passare...
Abbiamo già del codice commentato che deve essere assolutamente rivisto ed è meglio non aggiungerne altro.
Faccio un ultima prova...
Credo di avere sistemato creando una classe privata nel TestCase...
Penso sia meglio revertare il commit finchè non riesce a farli passare...
Abbiamo già del codice commentato che deve essere assolutamente rivisto ed è meglio non aggiungerne altro.
Comunque è un problema che dobbiamo risolvere...
Il test in locale funzione, mentre sulla build machine non vuole funzionare...
Credo di avere sistemato creando una classe privata nel TestCase...
Ho appena committato acnhe io la stessa cosa...
Ho visto... Purtroppo continua ad essere rossa da me.
BlueDragon
31-03-2006, 09:29
Concordo, il problema sono le classi create "on the fly" senza costruttore pubblico.
E comunque a me la build fallisce anche in locale :)
continuo a riprovare ed è sempre rossa... Solo con ANT... Con JUnit integrato non da quel problema.
Ho messo l'azione in una classe esterna, ora funziona... Che errore strano...
Ho fatto update ma da me è ancora rossa :p
Strano, da me è verde:
BUILD SUCCESSFUL
Total time: 50 seconds
Anche per la build machine è verde ;)
Sì vero ANT andava in modalità test invece che dist e quindi non faceva il clean :)
Ma questo test non è errato?
public void testForEachGem()
{
Gem gem = null;
for(int i = grid.getNumberOfRows() - 1; i >= 0; i--)
{
for(int k = grid.getNumberOfColumns()- 1; k >= 0; k--)
{
gem = Gem.create(DIAMOND, 3500);
gem.setCellPosition(i,k);
grid.addGemToGrid(gem);
}
}
for(int i = grid.getNumberOfRows() - 1; i >= 0; i--)
{
for(int k = grid.getNumberOfColumns()- 1; k >= 0; k--)
{
assertTrue(gem.isFalling());
}
}
grid.forEachGem(actionForTesting);
for(int i = grid.getNumberOfRows() - 1; i >= 0; i--)
{
for(int k = grid.getNumberOfColumns()- 1; k >= 0; k--)
{
assertFalse(gem.isFalling());
}
}
}
All'interno degli ultimi 2 for assertTrue ed assertFalse agiscono tutti sulla stessa Gem!
Mi sentirei molto più tranquillo con un revert ed il task lo si rifa con calma
Intanto ho fixato i test :)
Sì, direi che così possa andare bene...
Non è cambianto niente. :(
Va bene, allora facciamo una cosa diversa. Evidentemente il driver di quelle schede non accetta un pixel format senza alpha buffer e/ stencil buffer e/o depth buffer.
Quindi per cortesia provami le seguenti configurazioni:
Display.create(new PixelFormat());
Display.create(new PixelFormat(16, 8, 16, 8, 0));
Display.create(new PixelFormat(24, 8, 24, 8, 0));
Display.create(new PixelFormat(32, 8, 24, 8, 0));
Metti queste al posto di quella in cui crasha e ricordati di verificare se continua a crashare allo stesso punto.
Ho dimenticato di scrivere il resto :D
Non si può mandare una mail agli sviluppatori delle LWJGL?
Ho dimenticato di scrivere il resto :D
Non si può mandare una mail agli sviluppatori delle LWJGL?
Ragazzi forse non vi è chiaro che LWJGL non ha problemi e non è buggata. Il problema esiste solo perché i driver di una scheda non riescono ad avviare un determinato pixel format che noi richiamiamo. Se richiami in C++ via OpenGL lo stesso pixel format che usiamo noi, ci sarebbe lo stesso problema.
Ora il discorso è che il nostro pixel format è anomalo per un'applicazione OpenGL perché usiamo solo il color buffer, quando come minimo normalmente è attivo anche lo z buffer e l'alpha buffer. Se il driver è fatto male (e quelli ATI, specie per quei prodotti più vecchi, sono fatti male) si hanno problemi.
Paradossalmente se cdimauro disinstallasse i driver della sua Radeon 8xxx / 9xxx (precedenti alle 9500), subentrebbe il driver software di Windows che è stato già testato come funzionante.
Aggiungo, in ogni caso, che si tratta di un problema sicuramente risolvibile e che è molto banale.
cdimauro
31-03-2006, 13:53
Va bene, allora facciamo una cosa diversa. Evidentemente il driver di quelle schede non accetta un pixel format senza alpha buffer e/ stencil buffer e/o depth buffer.
Quindi per cortesia provami le seguenti configurazioni:
Display.create(new PixelFormat());
Display.create(new PixelFormat(16, 8, 16, 8, 0));
Display.create(new PixelFormat(24, 8, 24, 8, 0));
Display.create(new PixelFormat(32, 8, 24, 8, 0));
Metti queste al posto di quella in cui crasha e ricordati di verificare se continua a crashare allo stesso punto.
Provati tutte e 4 le possibilità, ma va in crash sempre nello stesso punto (esattamente su quell'istruzione), generando sempre lo stesso log, che riporto:
OS: Windows 2003
Version: 5.2
Architecture: x86
VM Vendor: Sun Microsystems Inc.
Version: 1.5.0_06
Class Path: C:\Documents and Settings\Cesare\workspace\Diamonds\bin;C:\Documents and Settings\Cesare\workspace\Diamonds\lib\junit.jar;C:\Documents and Settings\Cesare\workspace\Diamonds\lib\easymock.jar;C:\Documents and Settings\Cesare\workspace\Diamonds\lib\jar\lwjgl.jar;C:\Documents and Settings\Cesare\workspace\Diamonds\lib\jar\lwjgl_devil.jar;C:\Documents and Settings\Cesare\workspace\Diamonds\lib\jar\lwjgl_util.jar
JNI Library Path: lib/win32
Exception: class it.diamonds.engine.video.DisplayException
Message: The current display mode is not available due to org.lwjgl.LWJGLException: Could not find a valid pixel format
Display Adapter Driver: ati2dvag null
Stacktrace:
it.diamonds.engine.video.DisplayException: The current display mode is not available due to org.lwjgl.LWJGLException: Could not find a valid pixel format
at it.diamonds.engine.video.DisplayImplementation.initDisplay(DisplayImplementation.java:163)
at it.diamonds.engine.video.DisplayImplementation.<init>(DisplayImplementation.java:40)
at it.diamonds.engine.Engine.create(Engine.java:37)
at it.diamonds.GameLoop.create(GameLoop.java:63)
at it.diamonds.Game.setUpGame(Game.java:42)
at it.diamonds.Game.createGame(Game.java:185)
at it.diamonds.Game.main(Game.java:113)
cdimauro
31-03-2006, 14:00
Paradossalmente se cdimauro disinstallasse i driver della sua Radeon 8xxx / 9xxx (precedenti alle 9500), subentrebbe il driver software di Windows che è stato già testato come funzionante.
Non ho mai installato i Catalyst su questa macchina in cui sto effettuando le prove: ci sono soltanto i driver "nativi" di Windows XP.
Riporto qualche informazione (dal panello di sistema):
Scheda video: Ati Radeon 9250 (Microsoft Corporation)
Fornitore driver: ATI Technologies Inc.
Data driver: 03/12/2004
Versione driver: 6.14.10.6508
Firma digitale: Microsoft Windows Publisher
Comunque lo stesso problema me lo dà su un altro PC con una 8500BBA e coi Catalyst 5.7 x86 modificati da me (altrimenti il PC usava la scheda come SuperVGA).
P.S. Fra poco dovrò andare via e per eventuali altre prove se ne parlerà lunedì.
Aggiungo, in ogni caso, che si tratta di un problema sicuramente risolvibile e che è molto banale.
Non c'entra. Non deve essere l'utente a dover cambiare drivers ma il software ad adeguarsi. Fondamentale regola di Usability... Dobbiamo risolverlo a livello Diamonds non a livello utente :)
Non ho mai installato i Catalyst su questa macchina in cui sto effettuando le prove: ci sono soltanto i driver "nativi" di Windows XP.
Puoi provare a installare i catalyst? Se il problema persiste, mandami un dxdiag della tua macchina, impacchetto una versione di Diamonds e la mando a Richard Huddy per farla testare al drivers team di ATI. Che bello, anche Diamonds trova i bug nei driver ATI :D
Non c'entra. Non deve essere l'utente a dover cambiare drivers ma il software ad adeguarsi. Fondamentale regola di Usability... Dobbiamo risolverlo a livello Diamonds non a livello utente :)
Se riusciamo a trovare un workaround noi tantissimo di guadagnato. Se non ci riusciamo, purtroppo i casi in cui i driver sono fallati sono rari, ma esistono ed e' quasi matematicamente impossibile assicurare la compatibilita' di un'applicazione grafica con tutte le combinazioni di hardware e driver. E allora scattano le mail a Richard :D
Se riusciamo a trovare un workaround noi tantissimo di guadagnato. Se non ci riusciamo, purtroppo i casi in cui i driver sono fallati sono rari, ma esistono ed e' quasi matematicamente impossibile assicurare la compatibilita' di un'applicazione grafica con tutte le combinazioni di hardware e driver. E allora scattano le mail a Richard :D
Certamente ma nel team siamo una decina e già 2 hanno problemi :P
Effettivamente comunque si vedrà meglio con i feedback delle prime release sperando di avere un buon giro di betatesting :P
Non so se avete notato tutti, ma Cesare ha XP64...
Non so se avete notato tutti, ma Cesare ha XP64...
sìsì :)
cdimauro
31-03-2006, 15:04
Puoi provare a installare i catalyst?
Preferisco di no: non vorrei fottere questa macchina, se qualcosa non va. :fiufiu:
Ne ho un'altra, sempre con XP x64, dove ho installato i miei Catalyst moddati per x64: proverò con quella. :)
Se il problema persiste, mandami un dxdiag della tua macchina, impacchetto una versione di Diamonds e la mando a Richard Huddy per farla testare al drivers team di ATI.
Non c'è problema, lo faccio sulla macchina di cui sopra. ;)
Che bello, anche Diamonds trova i bug nei driver ATI :D
Già. Ma ce ne sono molti? :fiufiu: :sofico: :D
DanieleC88
31-03-2006, 16:01
Non so se avete notato tutti, ma Cesare ha XP64...
Non vorrei sbagliare, ma anche cisc ha dei problemi con Diamonds (su AMD64, mi pare). :mbe:
Non vorrei sbagliare, ma anche cisc ha dei problemi con Diamonds (su AMD64, mi pare). :mbe:
Si, sul desktop, debian 64bit non sono riuscito a far andare lwjgl, l'ho compilato dai sorgenti, con il supporto di vifani, ma non mi caricava le png (le jpg si), e quindi uso il portatile per diamonds.....
Causa Pentium4 defunto, probabilmente al più presto (spero già domani, ma non ci conterei più di tanto) sarò anche io su Athlon64 (ma sempre su WinXP "normale").
Speriamo non ci siano problemi ;)
Il problema non è Windows XP 64 bit che io uso da un anno e sul quale ho sviluppato diversi progetti Java + OpenGL, tra cui alcuni task di Diamonds.
A proposito, spero che la JVM installata sotto Windows XP x64 sia comunque quella a 32 bit perché altrimenti il problema potrebbe essere questo: lwjgl per Win64 non esiste così come non esistono ancora la maggioranza delle librerie di questo mondo per questa piattaforma.
Riguardo AMD64 sotto Linux, il problema è che attualmente se non erro Devil non esiste AMD64 e lo stesso LWJGL non lo supporta al momento, ma questo è un problema del tutto risolvibile utilizzando, esattamente come per Windows, sotto Linux AMD64 la JVM a 32 bit grazie alla quale tutte le librerie a 32 bit funzionano perfettamente.
Se il problema non è questo, allora è semplicemente un problema di ricerca della display mode e del pixel format supportato. Non è una cosa grave.
Se non sono stati installati i driver ATI o NVIDIA, viene usato il driver software Microsoft o quello di X sotto Linux. Il primo è compatibile OpenGL 1.1 ed il secondo OpenGL 1.3 se non erro. In ogni caso non ricordo chi provò Diamonds su un sistema senza driver ICD sotto Windows e scheda integrata SiS e andava senza problemi.
Per quanto riguarda cisc il suo è un problema diverso perché il gioco non crasha, ma si vede male quindi bisognerà studiarlo diversamente.
Riguardo cdimauro secondo me il problema potrebbe non essere il pixel format, ma la display mode. Dal log che hai riportato non mi sembra ci sia riferimento specifico a quella riga di codice dove crea il pixel format, ma sembra riferito a tutto il try catch. Puoi provare a cambiare la risoluzione ed il refresh?
Il metodo quit() di GameLoop e tutti gli shutdown() da esso chiamati non sono testati!!!
Puccio il naso e non so se dovrei. In caso, insulto libero :).
cdmauro ha già fatto il porting del motore di rendering da LwGL a SDL.
Potreste approfittarne (di cdmauro) e fare un passo oltre, usando la pipeline di Java2D. Non dico che sia esente da problemi quandi si abiliti l'uso di OpenGL (-Dsun.java2d.opengl=True) o la manipolazione delle immagini via directdraw et similia (-Dsun.java2d.ddscale=True, -Dsun.java2d.transaccel=true) ma Java2D è ormai un vegliardo testato da tutti quelli che abbiano scritto una qualche applicazione grafica in Java, il che dovrebbe renderlo un po' più stabile.
E' già incluso nel JRE, per l'utente non c'è niente da configurare, per voi non c'è niente da configurare salvo provare dei parametri diversi nei file JNLP. Al minimo è un software rendering che funziona anche sott'acqua. Mediamente fa del suo meglio per sfruttare l'hardware disponibile. Al massimo si può giocare con dei parametri d'avvio per osare un po' di più.
Non rende la vita più semplice a voi e soprattutto ai vostri utenti?
Puccio il naso e non so se dovrei. In caso, insulto libero :).
cdmauro ha già fatto il porting del motore di rendering da LwGL a SDL.
Potreste approfittarne (di cdmauro) e fare un passo oltre, usando la pipeline di Java2D. Non dico che sia esente da problemi quandi si abiliti l'uso di OpenGL (-Dsun.java2d.opengl=True) o la manipolazione delle immagini via directdraw et similia (-Dsun.java2d.ddscale=True, -Dsun.java2d.transaccel=true) ma Java2D è ormai un vegliardo testato da tutti quelli che abbiano scritto una qualche applicazione grafica in Java, il che dovrebbe renderlo un po' più stabile.
E' già incluso nel JRE, per l'utente non c'è niente da configurare, per voi non c'è niente da configurare salvo provare dei parametri diversi nei file JNLP. Al minimo è un software rendering che funziona anche sott'acqua. Mediamente fa del suo meglio per sfruttare l'hardware disponibile. Al massimo si può giocare con dei parametri d'avvio per osare un po' di più.
Non rende la vita più semplice a voi e soprattutto ai vostri utenti?
Ti offriresti volontario per fare un porting di prova? :D
Comunque forse Vifani ne sa qualcosa di più sul motivo per cui non sono state usate le Java2D :)
commitato un po di refactoring:
tolto riferimento a config in grid
aggiunto Config nel costruttore di gridController al posto di newGemDelay(che prelevo dal config).
tolto metodo setNewGemDelay da gridController
spostato updateStone() in Grid che fa forEachGem(updateStoneAction).
aggiunto a ActionForTesting il metodo isPassedOnGem(Gem gem) da usare nei test.
Ti offriresti volontario per fare un porting di prova? :D
Comunque forse Vifani ne sa qualcosa di più sul motivo per cui non sono state usate le Java2D :)
Io personalmente non comprendo e non condivido questa smania di cambiare libreria ad ogni problema che si riscontra. I problemi si risolvono, non si aggirano cercando ogni volta di fare porting ad un'altra libreria. Se i problemi li vogliamo risolvere, ci si mette e li si risolve così come stiamo tendando di fare con OpenGL e la configurazione di cdimauro, altrimenti avviamo N porting dove N è il numero di librerie candidate e poi facciamo una sorta di gara d'appalto.
Personalmente penso che sia meglio impiegare risorse nel fare i task e nel risolvere i problemi che non nel fare porting da una libreria ad un'altra.
Java2D se non erro non era hardware accelerated fino ad una cerca versione della JVM, poi è diventata accelerata però cmq è molto più lenta di OpenGL e LWJGL.
Java2D se non erro non era hardware accelerated fino ad una cerca versione della JVM, poi è diventata accelerata però cmq è molto più lenta di OpenGL e LWJGL.
Uno spike se avanza del tempo (ricordo che PGI-bis non è ufficialmente nel progetto per fare dei task quindi non sarebbe una risorsa portata via al progetto se mai decidesse di provare) a mio parere può valere la pena farlo.
In ogni caso abbiamo due persone in meno sul progetto a causa di questi problemi.
Secondo me valutare le alternative può essere una buona scelta :)
Uno spike se avanza del tempo (ricordo che PGI-bis non è ufficialmente nel progetto per fare dei task quindi non sarebbe una risorsa portata via al progetto se mai decidesse di provare) a mio parere può valere la pena farlo.
In ogni caso abbiamo due persone in meno sul progetto a causa di questi problemi.
Secondo me valutare le alternative può essere una buona scelta :)
Chiunque può scaricarsi il codice e fare quello che vuole. Tuttavia se permettete io mi sto attrezzando per tentare di risolvere il problema, mentre mi sembra che gli altri scappino a trovare soluzioni alternative drastiche. Niente di male in questo per carità, ma non è un approccio che mi piace. Su un problema preferisco sbatterci la testa e gestirlo, così di solito lo risolvo.
Comunque se c'è la volontà di risolverlo, continuo a vedere di trovare una soluzione. Altrimenti ditemelo che mi occupo di altro.
A questo punto ci sarebbe da chiedersi perché fu scelto all'inizio OpenGL. Era chiaro (almeno a me conoscendo questa API) fin dall'inizio che trattandosi di un'API accelerata in hardware avrebbe richiesto un minimo di testing e di lavoro per il corretto funzionamento su tutto. Se l'accelerazione in hardware non è una priorità e le funzionalità che avrà Diamonds non richiedono OpenGL, perché non è stato proposto fin da subito un qualche motore software e amen? Io ricordo che si parlò di qualche idea di uso di shaders o di qualche altro effetto 3D-like.
P.S: Ho provato oggi Diamonds sul sistema di mia sorella che ha una grafica integrata su motherboard Radeon IGP320, cioè una Radeon 7000 e funziona senza alcun problema. Idem su un notebook con grafica integrata Intel. Rinnovo quindi la domanda: chi lo usa sotto Windows XP x64 ha installato la JVM a 32 bit ?
Spartacus è down :( :cry:
Comunque se c'è la volontà di risolverlo, continuo a vedere di trovare una soluzione. Altrimenti ditemelo che mi occupo di altro.
Tranquillo, la volontà c'è tutta :D
Grazie per l'impegno :)
Spartacus è down :( :cry:
Ora è up ;)
Ecco una cosa strana che mi ha capitata nel fare un test.
Questo era quello che volevo fare
playField.getGridController().insertNewGemsPair();
ma ho dovuto fare questo
Gem gem = playField.getGridController().getGrid().getGemAt(0,4);
playField.getGridController().getGrid().removeGemFromGrid(gem);
playField.getGridController().insertNewGemsPair();
altrimneti mi beccavo un eccezione :
java.lang.IllegalArgumentException: Cell occupied: 0,4
:eekk: :eekk: :eekk:
Per chi volesse aggincersi nel capire il test è in TestIncomingStones ed è testWarningBoxIsHideAfterPairGemsInsert.
Quando ne farò il commit ;)
EDIT: risolto...era semplicemente il mockGenerator che aggiungeva una gemmain automatico ;)
cdimauro
03-04-2006, 08:34
Riguardo cdimauro secondo me il problema potrebbe non essere il pixel format, ma la display mode. Dal log che hai riportato non mi sembra ci sia riferimento specifico a quella riga di codice dove crea il pixel format, ma sembra riferito a tutto il try catch.
Eseguendo Diamonds in modalità debug e piazzando un breakpoint sulla riga
if(currentMode != null)
ed eseguendo passo passo, sulla riga
Display.create(new PixelFormat(32, 8, 24, 8, 0));
(che è quella con l'ultima prova effettuata su tuo suggerimento) viene sollevata sempre la stessa eccezione (invalid pixel format).
Puoi provare a cambiare la risoluzione ed il refresh?
Ho appena provato con l'ultima build di Diamonds, passando da 1280x1024x32@85 a 1024x768x32@60, ma il problema permane.
cdimauro
03-04-2006, 08:46
Io personalmente non comprendo e non condivido questa smania di cambiare libreria ad ogni problema che si riscontra. I problemi si risolvono, non si aggirano cercando ogni volta di fare porting ad un'altra libreria. Se i problemi li vogliamo risolvere, ci si mette e li si risolve così come stiamo tendando di fare con OpenGL e la configurazione di cdimauro, altrimenti avviamo N porting dove N è il numero di librerie candidate e poi facciamo una sorta di gara d'appalto.
Personalmente penso che sia meglio impiegare risorse nel fare i task e nel risolvere i problemi che non nel fare porting da una libreria ad un'altra.
Java2D se non erro non era hardware accelerated fino ad una cerca versione della JVM, poi è diventata accelerata però cmq è molto più lenta di OpenGL e LWJGL.
Personalmente il mio problema è che Diamonds non mi girava e continua a non girarmi. Ho chiesto aiuto un bel po' di tempo fa, ma nessuno è stato in grado di darmi un mano.
Avevo 2 possibilità:
1) studiarmi OpenGL e LWJGL cercando di capire come funzionano e quindi provare a risalire alla causa delle mie rogne;
2) studiarmi SDL.
Poiché la prima era, a mio avviso, una strada che mi avrebbe richiesto molto più tempo, ho scelto la seconda, che mi ha portato nel giro di 3 giorni ad avere Diamonds funzionante.
Non credo che il lavoro che ho fatto sia stato tempo perso. Tutt'altro. Questo perché:
- ho risolto il MIO problema, che era quello di far funzionare Diamonds; non quello di far funzionare le LWJGL, OpenGL, i driver di sistema o quale che sia la causa di tutto ciò;
- ho rispolverato il codice di Diamonds (ero fermo da tempo);
- ho trovato alcuni problemi del codice di Diamonds, che ci serviranno per migliorarne il design, la solidità e la compatibilità con un maggior numero di piattaforme.
D'altra parte, in queste condizioni, per me era, è e sarà impossibile impiegare il mio tempo per fare qualche task di Diamonds, per ovvi motivi.
Quanto a Java2D, con il refactoring a cui sto lavorando si potrebbe anche pensare di farlo diventare un'altra possibilità, se qualcuno ritenesse opportuno dedicarci del tempo.
Non trovo, quindi, scandalosa la possibilità di avere diversi "render target", specialmente se con ciò si possono risolvere dei problemi: da tempo immemore esistono giochi che offrono la possibilità di farlo.
cdimauro
03-04-2006, 08:54
Chiunque può scaricarsi il codice e fare quello che vuole. Tuttavia se permettete io mi sto attrezzando per tentare di risolvere il problema, mentre mi sembra che gli altri scappino a trovare soluzioni alternative drastiche. Niente di male in questo per carità, ma non è un approccio che mi piace. Su un problema preferisco sbatterci la testa e gestirlo, così di solito lo risolvo.
Bisogna anche vedere cosa s'intender per "problema". Per me il problema era ed è quello che Diamonds non funziona. Col branch SDL, invece, funziona.
Comunque se c'è la volontà di risolverlo, continuo a vedere di trovare una soluzione. Altrimenti ditemelo che mi occupo di altro.
La volontà e la disponibilità da parte mia ci sono.
A questo punto ci sarebbe da chiedersi perché fu scelto all'inizio OpenGL. Era chiaro (almeno a me conoscendo questa API) fin dall'inizio che trattandosi di un'API accelerata in hardware avrebbe richiesto un minimo di testing e di lavoro per il corretto funzionamento su tutto. Se l'accelerazione in hardware non è una priorità e le funzionalità che avrà Diamonds non richiedono OpenGL, perché non è stato proposto fin da subito un qualche motore software e amen? Io ricordo che si parlò di qualche idea di uso di shaders o di qualche altro effetto 3D-like.
Lo ricordo anch'io. OpenGL è un'API solida, multipiattaforma, e che avrebbe potuto anche portare dei vantaggi, come quello che tu hai citato, ma che rimanevano comunque nel campo delle ipotesi ("si potrebbe anche fare").
Forti di ciò, e del fatto che tu le conoscessi e c'avevi già lavorato, abbiamo scelto LWJGL (anziché JOGL, che era l'altra possibilità, se ricordi): in poco tempo siamo arrivati a un prodotto funzionante. Non privo di problemi, ma questo è normale nella programmazione.
E nella programmazione è noto che per un problema non esiste sempre un'unica soluzione.
P.S: Ho provato oggi Diamonds sul sistema di mia sorella che ha una grafica integrata su motherboard Radeon IGP320, cioè una Radeon 7000 e funziona senza alcun problema. Idem su un notebook con grafica integrata Intel. Rinnovo quindi la domanda: chi lo usa sotto Windows XP x64 ha installato la JVM a 32 bit ?
Nell'altro thread ho riportato le configurazioni delle macchine su cui non funziona Diamonds.
Io personalmente non comprendo e non condivido questa smania di cambiare libreria ad ogni problema che si riscontra. I problemi si risolvono, non si aggirano cercando ogni volta di fare porting ad un'altra libreria. Se i problemi li vogliamo risolvere, ci si mette e li si risolve così come stiamo tendando di fare con OpenGL e la configurazione di cdimauro, altrimenti avviamo N porting dove N è il numero di librerie candidate e poi facciamo una sorta di gara d'appalto.
E quando N e' maggiore di 1 significa supportare piu' code path differenti che fanno la stessa cosa ed e' una chiara violazione di DRY (Don't Repeat Yourself).
D'altro canto abbiamo due persone che non possono lavorare per i problemi che stiamo incontrando con la librerira grafica corrente e questi problemi vanno risolti in un modo o nell'altro.
Secondo me la cosa migliore da fare e' insistere ancora per questo Ciclo cercando di risolvere il problema di OGL, e se non dovessimo riuscirci, inutile insistere: cerchiamo una libreria alternativa, ma non ne supportiamo due.
Un'ultima cosa: ragazzi, un po' di fantasia, per la maggior parte dei task non serve neppure lanciare il gioco, basta avere i test che passano, poi Jocchan si occupa di testare l'integrazione nel gioco. Mentre attendete la soluzione al problema, cercate di prendervi i task che non hanno bisogno del gioco (e ci sono).
Uno spike se avanza del tempo (ricordo che PGI-bis non è ufficialmente nel progetto per fare dei task quindi non sarebbe una risorsa portata via al progetto se mai decidesse di provare) a mio parere può valere la pena farlo.
Ora pero lo e': abile e arruolato :D
Preferisco anch'io si occupi dei task. Ne abbiamo gia' saltato uno questo Ciclo e non voglio che la cosa si ripeta.
Non trovo, quindi, scandalosa la possibilità di avere diversi "render target", specialmente se con ciò si possono risolvere dei problemi: da tempo immemore esistono giochi che offrono la possibilità di farlo.
Ed esistono molti piu' giochi che non vengono finiti ;)
Preferisco un solo code path di rendering e che possibilmente funzioni e sia stabile. Sono poco interessato a quale, mi basta che funzioni per tutti e ci faccia risparmiare tempo.
Un'ultima cosa: ragazzi, un po' di fantasia, per la maggior parte dei task non serve neppure lanciare il gioco, basta avere i test che passano, poi Jocchan si occupa di testare l'integrazione nel gioco. Mentre attendete la soluzione al problema, cercate di prendervi i task che non hanno bisogno del gioco (e ci sono).
In effetti nessuno dei task dell'ultimo ciclo ha cambiato il gioco di una virgola da quel punto di vista :)
cdimauro
03-04-2006, 10:31
Ed esistono molti piu' giochi che non vengono finiti ;)
OK, ma ormai la "frittata" è fatta: sfruttiamo almeno quello che abbiamo. :)
Preferisco un solo code path di rendering e che possibilmente funzioni e sia stabile. Sono poco interessato a quale, mi basta che funzioni per tutti e ci faccia risparmiare tempo.
Benissimo. Per quanto mi riguarda è stato molto utile, perché non solo mi ha permesso di vedere Diamonds in azione (era da tempo che non sapevo nemmeno come fosse fatto), ma anche e soprattutto il codice. ;)
cdimauro
03-04-2006, 10:31
In effetti nessuno dei task dell'ultimo ciclo ha cambiato il gioco di una virgola da quel punto di vista :)
Beato tu che l'avevi visto prima. :p
Per ciò che rigurada il task "saltato" mi sento quasi in colpa... :cry:
...mi ero proposto io di farlo e no ci siamo riusciti.
Posso assicurarvi però che il refactoring che ho fatto in playfield porterà a fare il task nella metà del tempo...e poi mi sa di aver testato molto più profondamente quella porzione di codice :sofico:
Ora venedo ai task: è vero prima facevamo 3 storie da 5 task in 2 settimane...ora non riusciamo a fare 1 storia da 4 task :(
Però la gente che collabora c'è ed è tanta. :D :D
Forse il problema è proprio del codice...ovvero siamo arrivati al punto che gestirlo è più faticoso che aggiungerne...basta pensare a questi porting e gli imminenti ENORMI refactoring che ci attendono.
Punto a cui non si doveva fare. :O
P.S.:Cerchiamo di dare una mano a Vifani: se scopriamo cosme risolvere con LWGL abbiamo già tutto pronto ;)
SPARTACUS DOWN.... :doh: :muro:
Cesare come mai hai aggiunto quei membri di tipo Audio ? Sinceramente non ho capito :stordita:
Jocchan...io ho fatto il refactoring su updateWarningBox in playfield.
Mi è venuta una domanda.
Ma (gem, gem, chest) scatena il warningBox nel campo avversario se non ci sono crush nel campo avversario??
Scusate la ripetizione ma è per essere chiaro al massimo ;)
Jocchan...io ho fatto il refactoring su updateWarningBox in playfield.
Mi è venuta una domanda.
Ma (gem, gem, chest) scatena il warningBox nel campo avversario se non ci sono crush nel campo avversario??
Scusate la ripetizione ma è per essere chiaro al massimo ;)
Il warning viene mostrato per avvisare l'altro giocatore che, nel prossimo turno, riceverà un bel carico di pietre.
Con i task che stiamo introducendo in questo ciclo, daremo la possibilità alla "vittima" (mediante una Crush minore) di limitare i danni, o addirittura di azzerarli (Crush uguale) o rispedire al mittente le pietre in questione (mediante una Crush migliore) ;)
Potete aspettare a fare il commit sul server ? Ho fatto un refactoring sui tipi...
Fatto...potete continuare...ma fate un update ;)
cdimauro
05-04-2006, 07:45
La build è rotta!
[junit] Testcase: testDifferentMappingIfNewIstance(it.diamonds.tests.gems.TestPattern): FAILED
[junit] Colors must be different expected not same
[junit] junit.framework.AssertionFailedError: Colors must be different expected not same
[junit] at it.diamonds.tests.gems.TestPattern.testDifferentMappingIfNewIstance(TestPattern.java:97)
BUILD FAILED
C:\Documents and Settings\Cesare\workspace\Diamonds\build.xml:97: Test it.diamonds.tests.gems.TestPattern failed
cdimauro
05-04-2006, 08:00
Cesare come mai hai aggiunto quei membri di tipo Audio ? Sinceramente non ho capito :stordita:
Certamente, ci mancherebbe. :)
In realtà, come avrai già capito dal fatto che questa parte sia commentata come TODO, è una cosa "in divenire".
La motivazione che inizialmente mi ha portato a ciò è quella che avrei voluto disaccoppiare entità come engine, texture, audio, sound, ecc. dalla loro implementazione legata a una particolare libreria.
Questo è venuto fuori lavorando al porting di SDL, ovviamente, ma nel corso di quest'opera sono saltati fuori dei problemi legati ai test e quindi al codice che attualmente non separa nettamente la logica del gioco da quella dei test.
In particolare, m'è capitato che i test legati a Texture, ma in particolare a Sound, non funzionassero senza un oggetto Engine o Audio istanziato (e che quindi aveva inizializzato correttamente l'opportuna libreria).
In buona sostanza, quando sto testando un oggetto Sound non dovrei neppure aprire la libreria audio, ma simulare in qualche modo (mock o codice ad hoc) la presenza di un dispositivo audio, cosa che non avviene attualmente in parte dei test.
Tutto ciò mi ha portato a pensare (complici anche le sedute al gabinetto :D) che Engine e Texture non dovrebbero essere trattate come entità a sé stanti, ma dovrebbero essere sostanzialmente "legate" (in particolare, la seconda dovrebbe dipendere strettamente); idem per Audio / Sound e per Keyboard e KeyMappings. In particolare, dovrebbe essere l'oggetto Engine a creare e restituire istanze di Texture, e così via per gli altri casi.
Questo permette due cose:
1) disaccoppiare più facilmente queste entità dalla loro particolare implementazione (rafforzandone il legame, tra l'altro);
2) propagare lo "status" dall'oggetto "padre" ai figli.
Il punto 1) è una semplice conseguenza di questa scelta di design.
Il punto 2), invece, permette che, ad esempio, se un Engine viene creato "for testing", quando gli verrà richiesto di creare una Texture, provvederà lui stesso a crearla "for testing".
D'altra parte non vedo quale senso avrebbe creare un Engine "for testing" e non fare altrettanto con una Texture.
Un'altra conseguenza di ciò è che vorrei far sparire il passaggio dell'oggetto engine a tutti gli oggetti che attualmente lo usano per il "draw". Roba come Sprite.draw(engine) vorrei che diventasse semplicemente Sprite.draw().
Tutto questo comporterà un notevole refactoring del codice e l'introduzione di diverse altre interfacce (Engine restituirà una TextureInterface al chiamante, ad esempio, e non un'oggetto Texture, e così via).
Che ne pensate?
Dicevo questo solo perchè audio viene segnalato come variabile non usata...e quindi vengono generati N-mila warning ;)
La build è rotta!
A me passa tutto...sia da ant che da Eclipse...
cdimauro
05-04-2006, 10:15
Dicevo questo solo perchè audio viene segnalato come variabile non usata...e quindi vengono generati N-mila warning ;)
Capito. Pensavo peggio. :D
Che ne pensi di quanto sopra?
A me passa tutto...sia da ant che da Eclipse...
Anche a qualcun altro fallisce. Il che è anche peggio: i bug "intermittenti" sono fra quelli più rognosi da stanare. :(
Un'altra conseguenza di ciò è che vorrei far sparire il passaggio dell'oggetto engine a tutti gli oggetti che attualmente lo usano per il "draw". Roba come Sprite.draw(engine) vorrei che diventasse semplicemente Sprite.draw().
Tutto questo comporterà un notevole refactoring del codice e l'introduzione di diverse altre interfacce (Engine restituirà una TextureInterface al chiamante, ad esempio, e non un'oggetto Texture, e così via).
Che ne pensate?
Hmmmm.... hmmm... draw(engine) invece semplicemente di draw() e' stata una mia scelta perche' se non c'e' un motivo molto ma molto buono, l'idea di memorizzare un handle all'engine in ogni singolo sprite (o texture o quant'altro) proprio non mi piace. E se non c'e' davvero un ottimo preferirei che le cose rimanessero cosi'.
Mi sta invece relativamente bene che sia Engine a creare Texture e Sprite, come avviene nelle D3D ad esempio, ma questo vorrebbe dire che Engine va modificato ogni volta che aggiungiamo una nuova primitiva e l'idea non mi stuzzicava molto, per questo ho tenuto i due oggetti disaccoppiati. Pero' e' anche vero che creare un Engine in test e una Texture non in test non ha molto senso.
Insomma, non e' una scelta facile e bisogna decidere una policy e seguirla accettandone i compromessi..
cdimauro
05-04-2006, 11:46
Hmmmm.... hmmm... draw(engine) invece semplicemente di draw() e' stata una mia scelta perche' se non c'e' un motivo molto ma molto buono, l'idea di memorizzare un handle all'engine in ogni singolo sprite (o texture o quant'altro) proprio non mi piace. E se non c'e' davvero un ottimo preferirei che le cose rimanessero cosi'.
Ho capito. Con SDL m'è capitato che la Texture ha l'esigenza di accedere al framebuffer di Engine, per effettuare il blitting del suo framebuffer. Si tratta però di un'operazione specifica dell'implementazione che si è scelta, per cui se Texture avesse a disposizione soltanto un riferimento all'interfaccia Engine da cui è stato generato, non potrebbe comunque procedere.
Vediamo se riesco a trovare un'altra soluzione a questo problema.
Mi sta invece relativamente bene che sia Engine a creare Texture e Sprite, come avviene nelle D3D ad esempio, ma questo vorrebbe dire che Engine va modificato ogni volta che aggiungiamo una nuova primitiva e l'idea non mi stuzzicava molto, per questo ho tenuto i due oggetti disaccoppiati. Pero' e' anche vero che creare un Engine in test e una Texture non in test non ha molto senso.
Insomma, non e' una scelta facile e bisogna decidere una policy e seguirla accettandone i compromessi..
E' chiaro. Magari potremmo far sì che Engine crei soltanto Texture. Questo perché Texture rappresenta una superficie / immagine caricata e "blittabile", che poi oggetti come Sprite & co. possono usare a loro piacimento.
In questo modo limiteremmo soltanto a Engine e Texture tutto il codice della specifica implementazione / libreria, e al contempo gestiremmo in maniera migliore la suddivisione del codice di produzione da quello di testing, che adesso crea qualche problema (un Engine "for testing" creerebbe soltanto Texture "for testing").
Lo stesso ragionamento ovviamente vale per Audio / Sound e Keyboard / KeyMappings.
E' chiaro. Magari potremmo far sì che Engine crei soltanto Texture. Questo perché Texture rappresenta una superficie / immagine caricata e "blittabile", che poi oggetti come Sprite & co. possono usare a loro piacimento.
In questo modo limiteremmo soltanto a Engine e Texture tutto il codice della specifica implementazione / libreria, e al contempo gestiremmo in maniera migliore la suddivisione del codice di produzione da quello di testing, che adesso crea qualche problema (un Engine "for testing" creerebbe soltanto Texture "for testing").
Lo stesso ragionamento ovviamente vale per Audio / Sound e Keyboard / KeyMappings.
Si puo' fare.
La build è rotta!
[junit] Testcase: testDifferentMappingIfNewIstance(it.diamonds.tests.gems.TestPattern): FAILED
[junit] Colors must be different expected not same
[junit] junit.framework.AssertionFailedError: Colors must be different expected not same
[junit] at it.diamonds.tests.gems.TestPattern.testDifferentMappingIfNewIstance(TestPattern.java:97)
BUILD FAILED
C:\Documents and Settings\Cesare\workspace\Diamonds\build.xml:97: Test it.diamonds.tests.gems.TestPattern failed
E' un test che fallisce random...lo metto a posto ;)
Ragazzi è pieno di codice commentato e warnings!
cdimauro
05-04-2006, 15:14
I warning male non fanno. :fiufiu: :p
I commenti mi servono per ricordarmi dove andare a mettere mano quando dovrò provare le modifiche ad Audio e Sound.
Se provate adesso a toglierli (eliminando o commentando la riga con "audio = null;") vedrete che alcuni test saltano perché OpenAL viene aperto due volte (e devo ancora capire dove e come ciò avviene). ;)
La build è di nuovo rotta.
cdimauro
05-04-2006, 15:47
E Spartacus è giù. :(
cdimauro
05-04-2006, 16:10
Checkstyle addomesticato e build nuovamente verde. ;)
I warning male non fanno. :fiufiu: :p
Ma non averli e' molto meglio ;)
Toglieteli subito pls.
Ho preso il tag del Ciclo 13.
cdimauro
06-04-2006, 07:15
Ma non averli e' molto meglio ;)
Toglieteli subito pls.
Appena Spartacus ritorna in vita ci penso io, se non l'ha fatto nessuno.
Comunque tecnicamente sono degli hint e non dei warning. :Prrr:
Ho preso il tag del Ciclo 13.
What's forfora? :confused:
Ultimamente Spartacus si "addormenta" piuttosto spesso :eek:
Ho appena provveduto a svegliarlo di nuovo :fagiano:
cdimauro
06-04-2006, 08:49
Niente da fare: è ancora morto. :(
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.