View Full Version : Thread dei Problemi
Questo per evitare che al rilascio dei due tasti la gemma si muova istantaneamente verso l'ultimo tasto rilasciato, ma con buona possibilità (a seconda del momento del rilascio rispetto al timer) la gemma resta ferma...
Non per correggere il tuo codice, ma per far capire la soluzione al problema che spiegavo nell'ultimo post della pagina precedente...
Per quanto riguarda update...non ce la faccio devo andare fra pochi minuti...
Ma correggi pure il mio codice, e' li' a posta :)
Solo una cosa, quando fai il commit puoi mettere il tuo nome ed una breve descrizione? Cosi' vedo subito che cosa succede dalla mail della build machine.
C'è ancora il solito casino nel repository !!! Prima del mio commit ho notato che ci sono nuovamente tutti i .java all'interno di bin/ !!!
Solo una cosa, quando fai il commit puoi mettere il tuo nome ed una breve descrizione? Cosi' vedo subito che cosa succede dalla mail della build machine.
La descrizione l'ho sempre messa, meno questa volta :muro: Il nome me lo sono sempre scordato...
C'è ancora il solito casino nel repository !!! Prima del mio commit ho notato che ci sono nuovamente tutti i .java all'interno di bin/ !!!
Grrr... ma si puo' sapere da dove esce questo problema?
La descrizione l'ho sempre messa, meno questa volta :muro: Il nome me lo sono sempre scordato...
Nessun problema, ne approfittavo per ricordarlo a tutti :)
Il bug e' risolto e' tutto funziona a meraviglia. E la code base e' sempre molto in ordine. Molto, ma molto bene, sono proprio contento.
Quando hai tempo ci posti il test che mostra il bug per curiosita' di tutti? Grazie.
Questo era il test che non passava:
public void testNoMovementOnRightAndLeft()
{
grid.insertGem(2, 4, gem);
grid.setGemUnderControl(gem);
input.generateKey(KeyCode.vk_Right);
input.generateKey(KeyCode.vk_Left);
grid.reactToInput(input, timer);
assertTrue("gem reacts erroneously to vk_Right and vk_Left pressed at the same time", grid.isGemAt(2, 4));
}
Grrr... ma si puo' sapere da dove esce questo problema? secondo me è un problema di Eclipse, a volte lo fa anche a me; comunque si può evitare: ogni volta che faccio il commit a me mostra l'elenco delle copie dei sorgenti presenti in bin, ma io le lascio sempre deselezionate e non le committa ;)
a proposito, può anche darsi che in realtà il repository sia perfettamente in ordine e che il problema sia solo da voi in locale...
^TiGeRShArK^
04-11-2005, 00:03
Grrr... ma si puo' sapere da dove esce questo problema?
ma il bello è ke sto guardando ora nel repository browser e nn riesco a trovare quei dannati files sotto bin...:muro:
ma il bello è ke sto guardando ora nel repository browser e nn riesco a trovare quei dannati files sotto bin...:muro: leggi il mio precedente post ;)
^TiGeRShArK^
04-11-2005, 09:36
boh... io il committ lo faccio sempre da tortoise... non mi fido tanto di eclipse..
per quanto riguarda i files fantasma nel repository non li ho visti col repository browser...però non ho provato a fare l'update.. non mi fido.....
Stavo pensando al ciclo principale del gioco...e non mi piacevano diverse cose:
1 - il gioco occupa il 100% del processore quando in esecuzione
2 - la reazione ai tasti mi sembrava strana (non chiedetemi perchè)
3 - la pressione di un tasto spesso generava comunque più di un movimento
4 - il movimento verticale mi sembrava comunque altalenante
5 - non mi piacciono le attese attive
Ho pensato a questo main loop:
while(!finished)
{
long timeStamp = timer.getTime();
if(timeStamp - lastUpdate >= config.getIntProperty("frameRate"))
{
lastUpdate = timeStamp;
grid.update();
}
timeStamp = timer.getTime();
if(timeStamp - lastRender >= config.getIntProperty("frameRate"))
{
lastRender = timeStamp;
render();
update();
}
processInput();
processWindow();
try
{
Thread.sleep(1);
}
catch(InterruptedException e)
{
}
}
Mi sembra che abbia risolto praticamente tutti i problemi che avevo rilevato...
La sleep libera il processore...i tasti non reagiscono in ritardo perchè gli input vengono processati sempre...e sia il movimento verticale che quello orizzontale mi sembrano nettamente migliori...
Per farlo funzionare bisogna togliere update da reactToInput in Grid...e rendere update pubblico...
Ovviamente questa sarebbe la versione di "prova" scritta senza badare allo stile...
L'unica cosa da verificare sarebbe la "costanza" del framerate su macchine più o meno potenti... Fate conto che occupa il 7% della CPU, ma con un Atlhon64 che sta a 1200 Mhz...
Datemi una vostra opinione...
Mi sembra che abbia risolto praticamente tutti i problemi che avevo rilevato...
La sleep libera il processore...i tasti non reagiscono in ritardo perchè gli input vengono processati sempre...e sia il movimento verticale che quello orizzontale mi sembrano nettamente migliori...
Per farlo funzionare bisogna togliere update da reactToInput in Grid...e rendere update pubblico...
Ovviamente questa sarebbe la versione di "prova" scritta senza badare allo stile...
Mi sembra ottimo. Hai provato con Sleep(0) che invece libera solo il resto del timeslice per thread alla stessa priorita'? In realta' a noi quel millisecondo in piu' o in meno non interessa molto.
Ah...altra cosa... Maari un DELAYINPUT più alto sarebbe più opportuno... Che so, 200...
No, ora provo Sleep(0)...
Con sleep(0) ho nuovamente il 100% di cpu...
Allora che ne dici fek ? Passo alla modifica dei test di grid per farli passare nuovamente ? Ovviamente togliendo update ho un bel po' di test che non passano...
while(!finished)
{
long timeStamp = timer.getTime();
if(timeStamp - lastUpdate >= config.getIntProperty("frameRate"))
[...]
Che ne dici di fare cosi. Ci evitiamo due chiamate a config per ciclo. Ed è pure piu chiaro :)
int frameRate = config.getIntProperty("frameRate");
while(!finished)
{
long timeStamp = timer.getTime();
if(timeStamp - lastUpdate >= frameRate)
{
lastUpdate = timeStamp;
grid.update();
}
timeStamp = timer.getTime();
if(timeStamp - lastRender >= frameRate)
{
lastRender = timeStamp;
render();
update();
}
processInput();
processWindow();
try
{
Thread.sleep(1);
}
catch(InterruptedException e)
{
}
}
ciao ;)
Tanto ho refactorizzato tutto...
Ora il main loop è così:
while(!finished)
{
updateGrid();
render();
processInput();
processWindow();
}
Non mi riesce trovare il nome per il metodo che incorpora il codice per la sleep...
SleepOneMilliSecond ? :stordita:
VICIUS: visto che era oggetto di task chiedo a te, posso aumentare da 100 a 200 il tempo che deve trascorrere fra due input ? Funziona tutto molto meglio...
Con sleep(0) ho nuovamente il 100% di cpu...
Si', perche' e' l'unico thread a quella priorita' essendo in foreground e viene rischedulato lui. Noi ci possiamo permettere Sleep(1). Ad esempio in BW2 non ce lo potevamo permettere.
Che ne dici di fare cosi. Ci evitiamo due chiamate a config per ciclo. Ed è pure piu chiaro :)
Martin Fowler non sarebbe d'accordo ed ha pure scritto un Refactoring chiamato "Remove temporary variable" proprio per passare dalla tua forma a quella di cionci :D
(Io non sono d'accordo con Fowler su questo punto, preferisco la variabile temporanea)
Tanto ho refactorizzato tutto...
Ora il main loop è così:
while(!finished)
{
updateGrid();
render();
processInput();
processWindow();
}
Non mi riesce trovare il nome per il metodo che incorpora il codice per la sleep...
SleepOneMilliSecond ? :stordita:
Ottimo! Ecco un bel "Template Method" Pattern da manuale :)
SleepOneMilliSecond e' ok per me.
VICIUS: visto che era oggetto di task chiedo a te, posso aumentare da 100 a 200 il tempo che deve trascorrere fra due input ? Funziona tutto molto meglio...
Domanda per Jocchan questa. Facciamo cosi', mettilo nel config cosi' Jocchan puo' editarlo e trovare il valore che piu' lo aggrada.
Stavo cercando di eliminare contemporaneamente al commit anche i file .java in bin (me li dava cme missing e quindi lia vrebbe eliminati)...ecco l'errore che appare...
Sembra che per lui sia quelli in source che quelli in bin corrispondano allo stesso file... Una specie di link simbolico che di fatto viene usato per inviare ai client gli stessi file in più cartelle...
Stavo cercando di eliminare contemporaneamente al commit anche i file .java in bin (me li dava cme missing e quindi lia vrebbe eliminati)...ecco l'errore che appare...
Sembra che per lui sia quelli in source che quelli in bin corrispondano allo stesso file... Una specie di link simbolico che di fatto viene usato per inviare ai client gli stessi file in più cartelle...
Tortoise deve avere alcuni problemi. bin/it è una cartella sotto ignore e dovrebbe ignorare cambiamenti e commit. prova con subclipse.
ciao ;)
comunque cionci io non sono mai riuscito a vedere sul mio pc il mvimento altalenante di cui tutti parlate, anche se ho capito perfettamente cosa intendete: in pratica la velocità di caduta è incostante, giusto? da me è sempre stata perfettamente costante... :mbe:
miracoli dell'hyperthreading!!! :sofico: :sofico: :cool:
edit: e infatti da me il gioco occupa solo il 52% LOOOL :D :D :Prrr:
Martin Fowler non sarebbe d'accordo ed ha pure scritto un Refactoring chiamato "Remove temporary variable" proprio per passare dalla tua forma a quella di cionci :D
(Io non sono d'accordo con Fowler su questo punto, preferisco la variabile temporanea)
Se la variabile temporanea è usata due o tre volte ok, posso essere d'accordo con lui. Ma in un ciclo eseguito milioni di volte no. Sono sicuro che dopo un rapida misura sarebbe arrivato anche lui alla mia soluzione :)
ciao ;)
Domanda per Jocchan questa. Facciamo cosi', mettilo nel config cosi' Jocchan puo' editarlo e trovare il valore che piu' lo aggrada.
Per ora l'ho rimesso a 100...
Gente come si fa ritornare alla revisione 506 ? Ho fatto un po' di casino (mi ero scordato i commenti :muro:...
Gente come si fa ritornare alla 506 ? fai il revert alla revision 506 e poi il commit; non ho mai provato ma dovrebbe andare...
comunque cionci io non sono mai riuscito a vedere sul mio pc il mvimento altalenante di cui tutti parlate, anche se ho capito perfettamente cosa intendete: in pratica la velocità di caduta è incostante, giusto? da me è sempre stata perfettamente costante... :mbe:
miracoli dell'hyperthreading!!! :sofico: :sofico: :cool:
edit: e infatti da me il gioco occupa solo il 52% LOOOL :D :D :Prrr:
Infatti l'HT spara qualche processo a bassa priorita' sul secondo hardware thread ed e' una manna dal cielo in queste situazione, per mantenere il framerate costante. Su AMD vedi che sbalzi!
Se la variabile temporanea è usata due o tre volte ok, posso essere d'accordo con lui. Ma in un ciclo eseguito milioni di volte no. Sono sicuro che dopo un rapida misura sarebbe arrivato anche lui alla mia soluzione :)
ciao ;)
Martin ti avrebbe risposto: "Prima mostra con un profiler che quella chiamata a funzione e' un collo di bottiglia e poi inserisci una variabile temporanea per eliminarlo".
Faccio l'avvocato del Diavolo perche' io preferisco le variabili temporanee in genere.
Vabbè...ho fatto un altro commit con il commento... Avevo modificato timer, ma ora l'ho rimesso com'era prima...
Molto bene, un altro problema risolto. Possiamo passare alla prossima Storia.
Domanda per Jocchan questa. Facciamo cosi', mettilo nel config cosi' Jocchan puo' editarlo e trovare il valore che piu' lo aggrada.
Benissimo, soluzione ideale direi.
Benissimo, soluzione ideale direi.
Lo faccio, ma volevo capire meglio... Si crea un file di configurazione o semplicemente si aggiunge una entry a Config da Game ?
Lo faccio, ma volevo capire meglio... Si crea un file di configurazione o semplicemente si aggiunge una entry a Config da Game ?
L'idea è proprio di creare un file .ini (o similari), in modo da poter testare autonomamente i vari settaggi, e decidere quali lasciare come definitivi ;)
La possibilità c'è già, vai a vedere i file XML in Data...basta che tu mi dica quale informazioni vuoi sotto controllo...
UpdateRate (tempo in ms con cui aggiornare il movimento delle gemme e suppongo degli sprite in genere, attualmente 20)
FrameRate (sempre in ms, attualmente 20)
GridInputDelay (è l'intervallo di cui si parlava prima, ora è 100)
Poi se ne servono altri dimmi...
Purtroppo per un pò non potrò accedere al repository.
Per ora comunque bastano e avanzano quelli che hai elencato, grazie ;)
Ok...allora faccio le modifiche e ti metto a disposizione il file GameConfig.xml dentro data/...
Ok... E' tutto pronto... Fatto il commit...
Ho cercato di cambiare il meno possibile in Grid mettendo a disposizione due metodi per leggere e settare l'inputDelay...
Questo test non ha senso:
package it.diamonds.tests;
import it.diamonds.engine.AbstractTimer;
import it.diamonds.engine.Timer;
import junit.framework.TestCase;
public class TestTimer extends TestCase
{
public void testTimer() throws InterruptedException
{
AbstractTimer timer = new Timer();
Thread.sleep(500);
assertEquals(500, timer.getTime(), 20);
}
}
Una volta è fallito perchè stavo facendo altre cose con il PC... Se il timeslice del processo che esegue la vm lanciata da ant finisce subito dopo la sleep e riprende successivamente dalla assertEquals il test fallisce...
Quindi questo test fallisce casualmente...
Questo test non ha senso:
package it.diamonds.tests;
import it.diamonds.engine.AbstractTimer;
import it.diamonds.engine.Timer;
import junit.framework.TestCase;
public class TestTimer extends TestCase
{
public void testTimer() throws InterruptedException
{
AbstractTimer timer = new Timer();
Thread.sleep(500);
assertEquals(500, timer.getTime(), 20);
}
}
Una volta è fallito perchè stavo facendo altre cose con il PC... Se il timeslice del processo che esegue la vm lanciata da ant finisce subito dopo la sleep e riprende successivamente dalla assertEquals il test fallisce...
Quindi questo test fallisce casualmente...
Uccidi quel test.
Quando si preme due volte di fila un tasto freccia, il gioco perde la seconda pressione (ovviamente). E' una sensazione un po' frustrante, come se il gioco non rispondesse ai comandi; immagino in un'azione concitata.
Secondo me dovrebbe registrare anche la seconda pressione ed eseguire il comando allo scadere del tempo di attesa. Jocchan, che ne pensi?
Quando si preme due volte di fila un tasto freccia, il gioco perde la seconda pressione (ovviamente). E' una sensazione un po' frustrante, come se il gioco non rispondesse ai comandi; immagino in un'azione concitata.
Secondo me dovrebbe registrare anche la seconda pressione ed eseguire il comando allo scadere del tempo di attesa. Jocchan, che ne pensi?
Sono d'accordissimo.
Situazioni concitate ce ne saranno, e anche tante, quindi consideriamo anche questo dettaglio ;)
Però dobbiamo evitare come la peste situazioni che prevedono due mosse con al stessa pressione di tasto...che con delay basso tutt'ora avvengono...
Quindi imho prima di fare la cosa sopra (cioè registrare i tasti), bisogna rilevare il rilascio del tasto... Dopo basta fare una lista...
Se si registrano i tasti bisogna attuare una politica di movimento con un delay molto basso, altrimenti sarà anche più frustrante di adesso...
Però dobbiamo evitare come la peste situazioni che prevedono due mosse con al stessa pressione di tasto...che con delay basso tutt'ora avvengono...
Quindi imho prima di fare la cosa sopra (cioè registrare i tasti), bisogna rilevare il rilascio del tasto... Dopo basta fare una lista...
Se si registrano i tasti bisogna attuare una politica di movimento con un delay molto basso, altrimenti sarà anche più frustrante di adesso...
Sostanzialmente serializzare gli eventi in una coda di input da consumare in reactToInput. E' materia buona per la prossima Storia se Jocchan e' d'accordo.
Sostanzialmente serializzare gli eventi in una coda di input da consumare in reactToInput. E' materia buona per la prossima Storia se Jocchan e' d'accordo.
Intendi come aggiunta alla storia 2, che dovremmo iniziare a momenti, oppure rinviamo questo dettaglio al prossimo ciclo?
Intendi come aggiunta alla storia 2, che dovremmo iniziare a momenti, oppure rinviamo questo dettaglio al prossimo ciclo?
Ce lo devi dire tu :)
Ce lo devi dire tu :)
Se il tutto rientra in un task, o al massimo due, allora ben venga come aggiunta nella storia che stiamo per iniziare.
Se la faccenda è più complicata e richiede svariati refactoring (ma dubito fortemente sia così), se ne riparla per il prossimo ciclo :)
EDIT: Ops, doppio post...
Se il tutto rientra in un task, o al massimo due, allora ben venga come aggiunta nella storia che stiamo per iniziare.
Se la faccenda è più complicata e richiede svariati refactoring (ma dubito fortemente sia così), se ne riparla per il prossimo ciclo :)
Un paio di task, ma sicuramente non c'e' tempo di aggiungerli alla Storia corrente. Ci devi dire tu che cosa preferisci fatto per primo.
Un paio di task, ma sicuramente non c'e' tempo di aggiungerli alla Storia corrente. Ci devi dire tu che cosa preferisci fatto per primo.
Bene, allora visto che è sempre una buona norma sistemare i problemi che già abbiamo prima di aggiungere altra carne al fuoco, modificherò la Storia 2.
Non ci sarà più la creazione di una nuova gemma, quando la precedente collide con il fondo dell'area di gioco (elemento che sarebbe - tra l'altro - incompleto, dato che delle collisioni ci saremmo occupati nel prossimo ciclo), ma ci occuperemo di questo.
Provvedo on the fly ad apportare alla storia le modifiche necessarie ;)
Informazione di servizio: ho messo su l'home server. Ora la build machine gira li' invece di girare sul tablet.
Fra poco installo anche un web server per pubblicare le build e i log e un mail server per mandarvi eventuali build rotte.
Eventualmente possiamo migrare in futuro anche il server subversion.
Mi potete testare questi due server per favore?
HTTP:
http://fcarucci.homeip.net:80
TOMCAT (per i build report):
http://fcarucci.homeip.net:8080
Fate i bravi che sono ancora alle prime armi come sysadmin :D
Primo server:
Funziona! Il Server Web Apache è stato installato su questo sito Web!
Secondo server:
If you're seeing this page via a web browser, it means you've setup Tomcat successfully. Congratulations!
:p
P.S.: fek per favore potresti passare un secondo su MSN?
Grazie!
Ora metto qualche build online e provo a configurare i report.
Build folder:
http://fcarucci.homeip.net/diamonds/
Spartano, ma per ora questo passa il convento. In futuro troverete sempre qui l'ultima build.
Funziona!!! :D
Guardate qui:
http://fcarucci.homeip.net:8080/cruisecontrol/
E navigateci. Per ogni build (siamo alla 190) trovate se e' passata, chi ha fatto il commit e i suoi commenti, relativi errori e test falliti, lo zip prodotto che potete scaricare e testare.
E poi guardate qui:
http://fcarucci.homeip.net:8080/cruisecontrol/buildresults/diamonds?tab=metrics
E qui c'e' l'RSS feed per essere sempre informati quando si rompe la build:
http://fcarucci.homeip.net:8080/cruisecontrol/rss/diamonds
E non e' mica finita qui:
http://fcarucci.homeip.net:8080/xwiki/bin/view/Main/WebHome
Lo useremo come Knowledge Base di Diamonds.
DanieleC88
07-11-2005, 13:43
E non e' mica finita qui:
http://fcarucci.homeip.net:8080/xwiki/bin/view/Main/WebHome
Lo useremo come Knowledge Base di Diamonds.
Grandioso! :)
Ottimo, ho messo il feed RSS su Thunderbird...
La build è rotta !!! :D
http://fcarucci.homeip.net:8080/cruisecontrol/buildresults/diamonds?log=log20051107121328
Cosa è successo ? Secondo me è il solito errore di inzializzazione/shutdown dell'audio nei test...
Sembra più un problema della build machine con l'hardware...
http://fcarucci.homeip.net:8080/cruisecontrol/buildresults/diamonds?log=log20051107121328&tab=testResults
Dal commento sembra che sia stato solo cambiato il delay per i comandi... mistero!
Sembra più un problema della build machine con l'hardware...
http://fcarucci.homeip.net:8080/cruisecontrol/buildresults/diamonds?log=log20051107121328&tab=testResults
La nuova build machine non ha una scheda audio. Il problema potrebbe essere quello. Potete disabilitare questi test finche non controllo? Grazie.
La nuova build machine non ha una scheda audio. Il problema potrebbe essere quello. Potete disabilitare questi test finche non controllo? Grazie.
E' sicuramente quello il problema...
Ma come si disabilitano i test ? Si mettono in ignore ?
E' sicuramente quello il problema...
Ma come si disabilitano i test ? Si mettono in ignore ?
Commentali per ora :)
E' un casotto, non basta commentare quei test... Qualunque test usi un file audio è destinato a fallire... Questo perchè Sound non si appoggia a Audio per testare se l'audio è attivo...
Ora che mi viene in mente potremmo anche modificare Sound per non verificare che l'audio sia inizializzato se è stato creato per testing...
Ovviamente va fatto un createForTesting anche per Audio...
E' un casotto, non basta commentare quei test... Qualunque test usi un file audio è destinato a fallire... Questo perchè Sound non si appoggia a Audio per testare se l'audio è attivo...
Ora che mi viene in mente potremmo anche modificare Sound per non verificare che l'audio sia inizializzato se è stato creato per testing...
Ovviamente va fatto un createForTesting anche per Audio...
Si', va bene. Procedi pure.
Oggi non ce la faccio... Lo posso fare solo domani mattina...
Oggi non ce la faccio... Lo posso fare solo domani mattina...
Fatto io. La build e' verde.
Inoltre adesso ci sono anche i sorgenti fra gli Artifacts, assieme allo zip che contiene il gioco. Ora in ogni momento potete andare a recuperare facilmente il codice di una vecchia build in caso di problemi oppure se fosse necessario il revert di uno o piu' file.
Ottimo, volevo giusto chiederti se era possibile inserire anche i sorgenti nelle varie build ;)
Altra cosa...come gestiammo la possibile mancanza di una scheda audio sul sistema ?
Ci sono diverse possibilità... Si fa comunque fallire l'inizializzazione dell'audio, si prende l'eccezione e si imposta la classe Audio con un flag...però a questo punto bisogna passare la classe audio ad ogni Sound che NON deve fallire con la classe audio impostata con quel flag.
Oppure per ogni sound si mette un if prima dell'instanziazione di ogni sound...
Altra possibilità...una classe con una funzione statica che si occupa di allocare i vari Sound... Se l'inizializzazione di Audio è fallita (bisogna passargli anche l'istanza di audio) alloca un Sound con createForTesting altrimenti alloca un Sound normale...
Altra cosa...come gestiammo la possibile mancanza di una scheda audio sul sistema ?
Ci sono diverse possibilità... Si fa comunque fallire l'inizializzazione dell'audio, si prende l'eccezione e si imposta la classe Audio con un flag...però a questo punto bisogna passare la classe audio ad ogni Sound che NON deve fallire con la classe audio impostata con quel flag.
Oppure per ogni sound si mette un if prima dell'instanziazione di ogni sound...
Altra possibilità...una classe con una funzione statica che si occupa di allocare i vari Sound... Se l'inizializzazione di Audio è fallita (bisogna passargli anche l'istanza di audio) alloca un Sound con createForTesting altrimenti alloca un Sound normale...
Jocchan?
Questo è un dettaglio puramente implementativo, quindi in teoria io non dovrei immischiarmi ;)
Però credo che la cosa migliore sia testare all'esecuzione dell'exe se è presente una periferica audio, impostare di conseguenza una variabile booleana, e andare avanti con gli if prima dell'esecuzione di ogni suono.
L'if ovviamente va incorporato in una funzione, così non bisogna riscriverlo sempre... poi fate voi ;)
Questo è un dettaglio puramente implementativo, quindi in teoria io non dovrei immischiarmi ;)
Però credo che la cosa migliore sia testare all'esecuzione dell'exe se è presente una periferica audio, impostare di conseguenza una variabile booleana, e andare avanti con gli if prima dell'esecuzione di ogni suono.
L'if ovviamente va incorporato in una funzione, così non bisogna riscriverlo sempre... poi fate voi ;)
Ah no, mi interessa sapere se quando non c'e' audio vuoi comunque eseguire il gioco senza oppure vuoi uscire con un errore.
All'implementazione ci pensiamo noi :)
cionci: Null Object Pattern e passa la paura. E' perfetto in questo caso.
Ah no, mi interessa sapere se quando non c'e' audio vuoi comunque eseguire il gioco senza oppure vuoi uscire con un errore.
All'implementazione ci pensiamo noi :)
cionci: Null Object Pattern e passa la paura. E' perfetto in questo caso.
Ah ho capito male ^^
Si potrebbe fare una via di mezzo, ossia lanciare un messaggio che avvisi l'utente dell'impossibilità di riprodurre suoni, e continuare lo stesso l'esecuzione del gioco senza?
In questo modo l'utente è informato del fatto che comunque i suoni ESISTONO :p
Se la cosa fosse troppo complicata (ne dubito) allora continueremo semplicemente l'esecuzione senza audio ;)
DanieleC88
08-11-2005, 15:57
Se la cosa fosse troppo complicata (ne dubito) allora continueremo semplicemente l'esecuzione senza audio ;)
Non dovrebbe. Anzi, si potrebbe pure fare una finestra di dialogo tipo: "Non riesco a trovare una scheda audio, non sarà possibile usufruire del sonoro. Vuoi giocare ugualmente?", che in caso di risposta negativa, esce senza continuare, altrimenti avvia il gioco e disabilita il sonoro.
Non dovrebbe. Anzi, si potrebbe pure fare una finestra di dialogo tipo: "Non riesco a trovare una scheda audio, non sarà possibile usufruire del sonoro. Vuoi giocare ugualmente?", che in caso di risposta negativa, esce senza continuare, altrimenti avvia il gioco e disabilita il sonoro.
Ecco, meglio ancora :)
Non dovrebbe. Anzi, si potrebbe pure fare una finestra di dialogo tipo: "Non riesco a trovare una scheda audio, non sarà possibile usufruire del sonoro. Vuoi giocare ugualmente?", che in caso di risposta negativa, esce senza continuare, altrimenti avvia il gioco e disabilita il sonoro.
Per la realizzazione della finestra di dialogo posso proporre SWT? Non mi dite che volete usare Swing o AWT che sono bruttissimi :D
Perchè la finestra di dialogo non si fa in OpenGL ? Mi sembra la soluzione più logica ;)
Perchè la finestra di dialogo non si fa in OpenGL ? Mi sembra la soluzione più logica ;) io direi addirittura di "pre-disegnarla", disegnando i pulsanti in due files a parte; così in runtime dobbiamo solo disegnare 3 textures e magari fare un effetto luminescenza quando il mouse passa sopra un pulsante.
direi anche di fare la stessa cosa per tutti i messaggi mostrati dal gioco, ad esempio la vittoria, i punteggi, ecc.
Perchè la finestra di dialogo non si fa in OpenGL ? Mi sembra la soluzione più logica ;)
Perche' non stampiamo un messaggio in console per ora? Poi in futuro vedremo.
Jocchan?
io direi addirittura di "pre-disegnarla", disegnando i pulsanti in due files a parte; così in runtime dobbiamo solo disegnare 3 textures e magari fare un effetto luminescenza quando il mouse passa sopra un pulsante.
direi anche di fare la stessa cosa per tutti i messaggi mostrati dal gioco, ad esempio la vittoria, i punteggi, ecc.
Concordo...
Usare della grafica integrata con quella del resto del gioco di sicuro ha un impatto migliore rispetto alle classiche e odiose finestre di errore.
Apprezzo molto la cosa, ed useremo questo stile per il messaggio in questione, e per gli altri similari (integrando il tutto con i vari menu del gioco).
Per le altre cose che avete citato (messaggi di vittoria, punteggi, etc.) invece useremo delle semplici png con grafica fatta appositamente, niente odiosi box ;)
La build è ancora rotta: chi provvede?
Ho appena notato che fallisce anche TestBackground, e non mi spiego il perchè (il file dovrebbe essere identico al precedente).
Fallisce per l'upload del nuovo file, anche se non capisco perchè...
Ora provo a rimettere quello vecchio...
Dovrebbe essere tutto in ordine ora.
BlackQuasar
18-11-2005, 02:14
Grande lavoro ragazzi, il gioco promette veramente bene... ;)
Forse ho trovato un bug, quando si tenta di muovere una gemma a dx o sx e un'altra gemma e' in quella direzione, mi crasha col seguente errore:
Exception in thread "main" java.lang.IllegalArgumentException
at it.diamonds.Grid.insertGem(Grid.java:136)
at it.diamonds.Grid.updateGemAfterInput(Grid.java:413)
at it.diamonds.Grid.handleLeftKey(Grid.java:211)
at it.diamonds.Grid.reactToInput(Grid.java:245)
at it.diamonds.Game.processInput(Game.java:194)
at it.diamonds.Game.main(Game.java:76)
Replicabile tutte le volte.
Succede anche a qualcun'altro ?
si, succede anche a me, confermo; ragazzi, colgo l'occasione per informarvi che in questo periodo ho veramente **TROPPE** cose da fare O__O :cry:
il mio task di conseguenza è in fenomenale ritardo, so che è stato detto di non preoccuparcisi di questi aspetti e che l'importante è fare le cose bene e non in fretta, ma a un certo punto io me ne preoccupo lo stesso perché anche i ritardi hanno una misura. domani cercherò di committare questo benedetto task (che fortunatamente era inipendente dagli altri, quindi al limite il ritardo non dovrebbe creare problemi), sennò se non ce la faccio nemmeno domani vi faccio sapere e casomai lo assegnate a qualcun altro.
SORRY!! :cry:
ma perché il mio cervello non è HT come il mio processore? T__T
^TiGeRShArK^
18-11-2005, 09:28
minkia!
ma non avete niente da fare alle 3? :Prrr:
comunque il bug dovrebbe essere normale in quanto non stiamo gestendo ancora le collisioni correttamente, quindi quando una gemma viene spostata in una cella della griglia già occupata viene lanciata un'eccezione...
se non sbaglio c'era già un task in questa storia per correggere il problema...
o no? :fagiano:
^TiGeRShArK^
18-11-2005, 09:30
si confermo è il task 5.2.3 che dovrebbe risolvere il problema...
ma .... 71104 .... il task di vifani non è dipendente dal tuo??? :fagiano:
Qualche statistica:
- 3700 righe di codice (test compresi)
- 1300 righe di codice nei test
- 61 classi (25 nei test)
- 394 metodi
Visto il numero di concetti che siamo riusciti a esprimere fino ad ora, direi che sono pochissime. Meno righe di codice, meno righe da mantenere e debuggare :)
Ho completato lo spike su SoundBank... Per i risultati: http://www.hwupgrade.it/forum/showthread.php?t=1066095
piccolo problema: gli scores devono essere (da quanto ho capito) da massimo 8 cifre, ma nei due spazi degli scores ce ne entrano solo 5 e mezza... :fagiano:
se volete posso fare un commit con una parte di codice commentata in Game.java: se la decommentate disegna uno score di 8 cifre (8 8 :p) nello spazio viola del giocatore di sinistra.
Veramente abbiamo 378-219=159 pixel, e dato che i numeri dovrebbero essere spaziati tra di loro di 11 px ciascuno, direi che lo spazio basta e avanza... anzi, a voler essere precisi avremmo anche potuto lasciare un pò più di spazio ogni tre ordini di grandezza (per distinguere chiaramente migliaia, e milioni) ;)
Ma quanti pixel sono per cicfra ? 159 / 8 fa circa 20 pixel - 11, quindi le cifre dovrebbero essere di 8 pixel, invece mi sembra che siano di 16 !!! :)
Io e 71104 abbiamo chiarito su MSN, in pratica anche se le caselle sono di 16px, bisogna considerare come se fossero composte da 11, ed overlappare la parte in eccesso (sovrapponendole insomma).
C'è comunque un errore nelle coordinate in alto a sx della casella score (di ascissa 291, non 219), ora vedo di provvedere ;)
Il problema è comunque risolto :D
nel reppo c'è il solito casino dei sorgenti in bin... colgo l'occasione per ribadire che secondo me quello è un problema di Eclipse che mette i sorgenti anche nella directory dei .class, e che quando fate un commit non dovete committare i file non-versioned che si trovano in bin! (se non altro per non occupare inutilmente spazio sul server :p)
71104: lancia sempre ANT prima di fare un commit... E' giò syue volte che rompi la build :ciapet:
71104: lancia sempre ANT prima di fare un commit... E' giò syue volte che rompi la build :ciapet:
E lo sapete che ho tutte le statistiche su chi rompe le build, quando e anche gli orari :D
In BW2 avevamo la regola che chi rompeva la build pagava una sterlina. Nell'arco del progetto mi hanno dissanguato...
però poi l'ho fixata :Prrr:
non me ne sono accorto subito solo perché ieri avevo chiuso il Gmail Notifier; ora l'ho rimesso :p
In BW2 avevamo la regola che chi rompeva la build pagava una sterlina. Nell'arco del progetto mi hanno dissanguato...
Basta che non metti anche questa regola in diamonds per rifarti di quanto perso con BW2 :Prrr: :Prrr:
DanieleC88
01-12-2005, 15:11
O.o'
^^'
Uomo di poche parole. :D
DanieleC88
03-12-2005, 15:10
SVN giu'?
Pare di si, anche io cercavo di fare l'update e mi rifiutava la connessione. :(
Ho lasciato un messaggio ad antares su msn. Speriamo bene :)
ciao ;)
Provando un pò ho notato una cosa... il punteggio viene aggiornato appena la gemma viene inserita nella griglia, non sarebbe meglio aggiornarlo quando la gemma si ferma (quindi poco prima che viene inserita una nuova)?
ragazzi, facendo oggi l'update e avviando il gioco ho notato che è successo un casino ai punteggi: le view area degli sprites dei caratteri sono tutte strane...
ragazzi, facendo oggi l'update e avviando il gioco ho notato che è successo un casino ai punteggi: le view area degli sprites dei caratteri sono tutte strane...
Allora sono stato io...ho fatto un refactoring notevole... Ho messo Rectangle da float a int... Leggi la knowledge base per capire meglio... Comunque mi metto a controllare meglio...
Ehm...ma come diavolo ho fatto a non notarlo... Prova a darci un'occhiata anche te se puoi...
Ehm...ma come diavolo ho fatto a non notarlo... Prova a darci un'occhiata anche te se puoi... non capisco, l'unica differenza che vedo tra le due revisions in Rectangle.java è un +1... basta quello a sballare di così tanto? :D
se non era quello non venirmi a chiedere di guardarmi TUTTO il codice! :Prrr:
Prima per allocare un rectangle 32x32 facevamo così: new Rectangle(0.0f, 0.0f, 32.0f, 32.0f);
Secondo me (e secondo anche fek) era logicamente sbagliato...
Vedessi che casino poi...con quelle poche modifiche, una volta tolti i vari errori di compilazione, non si vedeva più niente del gioco...e c'erano almeno una 15ina di test che non passavano...
Visto che la conosci bene controlla createDigits...
Ricordati che ora per creare un Rectangle 16x24 devi fare così: new Rectangle(0, 0, 15, 23)
lo immaginavo quando ho scritto "Refactoring moment?" :p
Non capisco, la createDigits mi sembra corretta... Allora provo a vedere se è la drawQuad che non funziona...
Risolto... Mancava una conversione in float in drawQuad...
No casting no party :p
Come si fanno a vedere le modifiche di un update rispetto al precedente?
^TiGeRShArK^
06-12-2005, 20:43
basta usare il diff...
e puoi vedere le modifiche rispetto a qualsiasi versione precedente non solo l'ultima ;)
basta usare il diff...
e puoi vedere le modifiche rispetto a qualsiasi versione precedente non solo l'ultima ;)
dove è il diff? :p
ma non dirai diff di linux
Tasto destro sul file...Compare with -> Revision e scegli la revisione...
BlackQuasar
07-12-2005, 04:37
Se si mettono le gemme una sopra l'altra fino a riempire tutta la grid si ha un eccezione.
E' un task per il futuro o un bug ?
Exception in thread "main" java.lang.IllegalArgumentException
at it.diamonds.Grid.insertGem(Grid.java:141)
at it.diamonds.Grid.insertGemIntoColumn(Grid.java:161)
at it.diamonds.Grid.insertNewGem(Grid.java:109)
at it.diamonds.Grid.update(Grid.java:284)
at it.diamonds.Game.updateGrid(Game.java:181)
at it.diamonds.Game.main(Game.java:77)
ciao ;)
E' un task per il futuro o un bug ?
E' normale... Ancora non gestiamo quella situazione ;)
ragazzi, come faccio a far funzionare lwjgl sotto linux amd64?
Se si mettono le gemme una sopra l'altra fino a riempire tutta la grid si ha un eccezione.
E' un task per il futuro o un bug ?
E' un task per la Storia di Natale :)
Chi ha messo GravityMultiplier a 22 nel repository ?!?!?
Mi rispondo da solo Vic...
Ne abbiamo discusso insieme, e gli ho dato l'ok io (in effetti il multiplier andava aumentato, e di parecchio).
Ah...ok..ho capito cosa intendete fare... Però a questo punto credo che con il multiplier premuto debbano essere disabilitati i tasti laterali...
secondo me no e manco in SPF2 è così mi pare
forse ho trovato qualcosa, stasera vi faccio sapere (dopo aver postato i tests;)):
http://lwjgl.org/forum/viewtopic.php?p=7886&sid=d63cb1bc20d4ccb1904447d50e73e750
P.S: Vifani...sei tu?:D
ragazzi, ho fatto provare il programma a un mio amico dell'università: ha un'ATI Radeon 9200 (mi sembra) e il gioco parte ma si chiude subito dopo aver mostrato la lista delle modalità video disponibili con una eccezione. il problema maggiore secondo me è il fatto che la console si chiude immediatamente senza dare il tempo di leggere il nome del file e la riga a cui avviene l'eccezione, quindi che ne direste voi di mettere un try-catch nella main che cattura *qualsiasi* eccezione avvenga nel gioco e blocca la console se il flusso del programma arriva dentro il catch?
in futuro poi potremmo mettere all'interno del catch del codice che invii ad uno degli indirizzi @diamondcrush.net una segnalazione errori se è disponibile una connessione a Internet...
^TiGeRShArK^
13-12-2005, 23:13
ma fare partire il .bat da una sessione dos, no eh? :mbe:
ammesso ke ho capito quale sia il problema.. :fagiano:
ma fare partire il .bat da una sessione dos, no eh? :mbe:
ammesso ke ho capito quale sia il problema.. :fagiano: lol hai ragione ^^'
però l'idea dell'invio segnalazione errori mi sembra comunque buona... abbiamo fatto apposta uno degli alias @diamondcrush.net
Oltre che leggere solo il codice ogni tanto mi rendo anche utile ^^
Provando un pò ho notato una brutta cosa, che penso sia dovuta all'aggiunta del delay nella creazione della nuova gemma...
Dopo che la gemma ha toccato e si è fermata (in pratica...dopo il beep), se si prova a spostarla....si sposta..e questo non lo vogliamo immagino, anche perchè il risultato potrebbe diventare una cosa simile...che penso sia un pò "anormale" ^^
http://img446.imageshack.us/img446/1742/snapshot37op.th.jpg (http://img446.imageshack.us/my.php?image=snapshot37op.jpg)
^TiGeRShArK^
14-12-2005, 22:24
non ho capito...:mbe:
se è atterrata e ha fatto bip non è già comparsa la nuova ke è quella ke sarà sotto controllo???
o m sono perso qualkosa in questi ultimi giorni??? :mbe:
è stato aggiunto un delay (per ora temporaneo di un secondo) alla creazione. Dopo che si è fermata una gemma, passa un secondo e viene creata quella nuova
ragazzi, la gestione dell'input durante il delay ancora non l'abbiamo fatta;)
Deve essere ancora terminato il task ;)
ok :Prrr: :Prrr:
Mi ero sentito utile per un attimo... :nono: :nono:
BlueDragon
14-12-2005, 23:32
Ieri sera ho giocato un po' con il codice per lo spike di Natale, e sono incappato in un problema di occupazione della memoria..
Praticamente avevo necessità di creare delle gemme, farle vedere, e poi scartarle per ricreare nuovamente la griglia con nuove gemme....questo molte volte al secondo :)
Dopo pochi secondi tutto diventava molto lento..perché Diamonds era arrivato ad occupare 1,8 GB di memoria, ed era in continua espansione :D
Ho rifatto una prova stasera mettendo nel ciclo principale la creazione ed il cleanup di una gemma:
while(!finished)
{
updateGrid();
Gem gem = new Gem("ruby");
gem.cleanup();
render();
processInput();
processWindow();
sleepOneMillisecond();
}
Ebbene anche in queste condizioni il programma si mangia memoria all'infinito (o almeno fino ad 2,0 GB poi ho chiuso :))
La cleanup non era stata messa proprio per i problemi di RAM? O no?
Cmq credo che il problema sia lì su OpenGL, visto che solitamente la JVM da Out of Memory Error ben prima di aver raggiunto tali grandezze. A meno che Eclipse non avvii il programma in maniera particolare... :)
Sicuramente è un problema di texture... Ogni volta che viene creata una nuova gemma viene allocato un buffer per la texture... Oltre che ad un SoundBank (che già ho implementato), dovremo anche pensare ad un TextureBank, in modo da lavorare ogni volta sulle stesse texture (o almeno sugli stessi buffer)...
sentite, piccola parentesi: io ieri avevo messo il delay dell'inserzione di una nuova gemma a 1000 ms (1 secondo) per evidenziarlo meglio e vedere se funzionava effettivamente; adesso possiamo anche ridurlo, no? :p
quanto chiedeva il task? dobbiamo mettere il valore in Config?
dobbiamo mettere il valore in Config?
Credo sia la cosa migliore ;)
@Cionci: è complicato creare questa TextureBank? Credo sia il caso di limitare un pò questo immane consumo di memoria :stordita:
Credo sia la cosa migliore ;) allora lo chiamo "newGemDelay" ?
allora lo chiamo "newGemDelay" ?
Approvato :)
E per favore, già che ci sei, setta il GravityMultiplier a 8, thanks ;)
Piccolo suggerimento... Sarebbe bello se, tenendo premuto il tasto in giù dopo che la gemma è stata "droppata", alla creazione della nuova la pressione non venisse ignorata :p
Secondo me è giusto che venga ignorata...anche perchè darebbe risultati imprevedibili... al massimo si potrebbe fare che venga lasciato nella coda solo l'ultimo tast premuo...
I tasti premuti durante la pausa tra una gemma e l'altra devono essere ignorati, e questo perchè darebbero degli effetti impossibili da prevedere sulla successiva.
Pensate a quando, in Fifa 99, premevate il tasto per il passaggio in corsa.
Orbene, visto che bisognava aspettare il termine dell'animazione, c'era un ritardo netto tra la pressione del tasto ed il passaggio vero e proprio: questo portava l'utente (specie se inesperto) a pigiare come un forsennato su quel tasto.
Quando poi l'animazione finiva, visto che il gioco ricordava tutti quei comandi, accadeva che, involontariamente, si passassero la palla anche altri giocatori (e la si perdeva).
Era una cosa odiosa in termini di giocabilità, e sarete d'accordo con me sul fatto che dobbiamo evitarla come la peste ;)
Secondo me è giusto che venga ignorata...anche perchè darebbe risultati imprevedibili... al massimo si potrebbe fare che venga lasciato nella coda solo l'ultimo tast premuo...
In realta` non proprio il tasto premuto ma l'evento (premuto o rilasciato.
La situazione attuale e` la seguente:
la gemma viene droppata e sto attendendo la prossima. Tengo premuto il tasto sinistra. Quando la gemma viene generata non tiene conto dell'ultima pressione quindi non vede l'evento "tasto premuto" quindi devo rilasciare il tasto e rischiacciarlo. Questo a mio avviso non e` corretto.
Inoltre questo causa un altro problema:
Premetto che ho committato ieri sera quindi magari hanno risolto...
Provate a droppare una gemma mentre state tenendo premuto i tasti freccia sinistra o freccia destra. Anche se lo rilasciate prima della creazione della prossima gemma, essa continuera` a seguire quella direzione.
Per correggere il problema durante il tempo di attesa deve essere possibile tenere un input in coda (uno solo basta).
Farei volentieri il fix ma non posso mettere mano al repository fino a stasera :)
Jocchan: quello che intendo io non e` un buffering dei comandi ma proprio un fix che migliorerebbe la giocabilita`. Considera che pure in SPF2T e` cosi` :p
Ipotizza il caso in cui so gia` che la prox coppia vorro` buttarla tutta a sx.
Se sei un videogiocatore sai benissimo che terrai premuto SX prima della creazione della stessa. Tenendo nella coda di input la pressione quando la gemma sara` creata essa andra` dove vorrai tu.
Metti il caso in cui premi sx per sbaglio e lo rilasci subito. Nessun problema xke nella coda rimarra solo il rilascio del tasto :)
In realta` non proprio il tasto premuto ma l'evento (premuto o rilasciato.
La situazione attuale e` la seguente:
la gemma viene droppata e sto attendendo la prossima. Tengo premuto il tasto sinistra. Quando la gemma viene generata non tiene conto dell'ultima pressione quindi non vede l'evento "tasto premuto" quindi devo rilasciare il tasto e rischiacciarlo. Questo a mio avviso non e` corretto.
Inoltre questo causa un altro problema:
Premetto che ho committato ieri sera quindi magari hanno risolto...
Provate a droppare una gemma mentre state tenendo premuto i tasti freccia sinistra o freccia destra. Anche se lo rilasciate prima della creazione della prossima gemma, essa continuera` a seguire quella direzione.
Per correggere il problema durante il tempo di attesa deve essere possibile tenere un input in coda (uno solo basta).
Farei volentieri il fix ma non posso mettere mano al repository fino a stasera :)
Ok, non avevo capito io... in questi termini è sacrosanto fare in modo che (se il tasto resta premuto) venga considerato ;)
Questa cosa è giustissima... Bisogna mantenere aggiornato lo stato dei tasti all'interno di InputReactor, ma non bisogna fare alcuna azione... Avrei una soluzione semplice semplice per questo, da applicare purtroppo in Grid...
Anzi, la applico agli handler...
Problema risolto... Molto meglio così... Lo stato dei tasti viene aggiornato anche durante l'attesa, ma non viene fatto alcun movimento perchè la gemma sotto controllo è null...
public void handleRepetition(InputReactor inputReactor)
{
if(hasBeenRepeated(inputReactor.getLastInputTimeStamp(), inputReactor.getRepeatDelay()))
{
inputReactor.setRepeatDelay(50);
execute(inputReactor);
}
}
Questo setRepeatDelay(50) modificato cosi' di soppiatto non mi convince neanche un po'. Qualcuno puo' giustificarlo?
public void handleRepetition(InputReactor inputReactor)
{
if(hasBeenRepeated(inputReactor.getLastInputTimeStamp(), inputReactor.getRepeatDelay()))
{
inputReactor.setRepeatDelay(50);
execute(inputReactor);
}
}
Questo setRepeatDelay(50) modificato cosi' di soppiatto non mi convince neanche un po'. Qualcuno puo' giustificarlo?
task xmas.1.4 :p
Ho fatto un piccolo refactoring... Ora vado a nanna.. domani vedo se si può migliorare ancora un po' di roba da quelle parti :)
Ho fatto un refactoring di inputReactor per renderlo indipendente dai tasti contenuti nel map... Inoltre ora ogni eventHandler ha un repeatDelay indipendente dagli altri...
La cosa dei repeatDelay indipendenti non mi piace... Il task non richiedeva questa cosa... ora faccio un po' di refactoring e mi dici cosa ne pensi :)
Non lo richiedeva, ma è implicita la cosa...
Se ci pensi bene ogni tasto a quel punto deve avere lo stesso comportamento... Supponendo di premere il tasto per girare la coppia di gemme a destra...le gemme dopo il primo repeat cominciano a girare ogni 50 ms... Dopo premi il movimento verso destra pensando che la gemma si muova normalmente...invece non lo fa e ti si muove di due caselle invece di una sola (perchè il repeatDelay di tutti i tasti è a 50)...
ho capito cosa vuoi dire... avevo capito valori di delay differenti nel senso di (il tasto destra 200 il tasto sinistra 100 :p)
Comunque la gestione delle ripetizioni/delay va spostata o tutta nei KeyEventHandler o tutta in inputReactor... Ora come ora è molto complicata la gestione... Tra poco faccio commit
Infatti è tutto in InputReactor...negli EventHendler c'è solo il valore attuale del delay...
Hmmmm visto che non sono tanto sicuro su come si possa rendere tutto + comprensibile ho commitato solo la parte per l'aggiunta della proprietà FastRepeatDelay :)
D'accordissmo sull'aggiunta... currentRepeatDelay a che serve ?
PS: ho notato ora che Eclipse permette di mettere automaticamente i setter e i getter su una variabile privata... Ottima cosa...
non serve a niente nel game però serve per non far fallire una miriade di test :)
credo si possa togliere con un adeguato refactoring
ho capito... ora sistemo tutto :)
Non c'è già normalRepeatDelay che esprime lo stesso concetto ?
Non c'è già normalRepeatDelay che esprime lo stesso concetto ?
Si infatti ho appena sistemato la cosa, controlla :p
Ok...
Sto provando puzzle fighter !!! :sborone:
ottima scelta, è bellissimo :D
non sarebbe una buona idea aprire un thread dei refactoring? stiamo forse un po' abusando di quello dei problemi :p
Ufo13: quella che hai tolto non era una ripetizione, ma una cosa necessaria...
Tra l'altro avrebbe dovuto fallire qualche test, invece non sono falliti quindi significa che qualcosa è andato storto...
Nel modo in cui hai messo hasBeenRepeated ritorna sempre vero quando il tasto è stato ripetuto almeno una volta... Invece prima ritornava vero solo se era passato il RepeatDelay dall'ultima ripetizione... Infatti prova a mette l'InputRate a 10 e vedrai come si comporta la gemma...
Quindi devo fare il revert...anzi, prima faccio un test che fallisce in questa situazione...
hmmm allora bisogna scovare un'altra soluzione per gestire le pressioni contemporanee perchè la gestione fatta in questo modo è assai confusionaria ed ambigua...
Edit: Ma poi per quanto ho visto nel codice così dovrebbe funzionare!
Come ti ho detto prova mettere l'inputRate a 10 e vedrai che ritornando sempre true si muova ad ogni aggiornamento dell'input...invece dovrebbe muoversi dopo 50ms...
public void testKeyRightNotRepeatedAfterFirstDelay()
{
grid.insertGem(2, 3, gem);
grid.setGemUnderControl(gem);
input.generateKey(KeyCode.vk_Right, timer.getTime());
inputReactor.reactToInput(timer);
timer.advance(inputReactor.getNormalRepeatDelay() + 1);
inputReactor.reactToInput(timer);
timer.advance(1);
inputReactor.reactToInput(timer);
assertTrue("Gem isn't moving according to the correct delay with Right Key being pressed",
grid.isGemAt(2, 5));
}
Questo test fallisce...invece dovrebbe passare...
hmmmm ok ti credo sulla parola... Reverta pure quella parte... ci guarderò quando torno :)
public void testKeyRightNotRepeatedAfterFirstDelay()
{
grid.insertGem(2, 3, gem);
grid.setGemUnderControl(gem);
input.generateKey(KeyCode.vk_Right, timer.getTime());
inputReactor.reactToInput(timer);
timer.advance(inputReactor.getNormalRepeatDelay() + 1);
inputReactor.reactToInput(timer);
timer.advance(1);
inputReactor.reactToInput(timer);
assertTrue("Gem isn't moving according to the correct delay with Right Key being pressed",
grid.isGemAt(2, 5));
}
Questo test fallisce...invece dovrebbe passare...
Ma quanto e' comodo lavorare con i test? :)
Aspetta un attimo a revertare:
public void handleRepetition(InputReactor inputReactor)
{
if(hasBeenRepeated(inputReactor.getLastInputTimeStamp()))
Secondo me basta aggiungere un controllo qui dentro per ovviare al problema... Risulterebbero ancora i vantaggi del refactoring e dovresti risolvere il problema con quel test... Se non hai voglia provo io stasera! A dopo, ciao!
Ma quanto e' comodo lavorare con i test? :)
Mi sento in dovere di rispondere "davvero tanto" :)
Ormai ho fatto il commit... Comunque serve un ulteriore stato... hasBeenRepeated non può riuscire a segnalare sia che il tasto deve essere ripetuto sia che è già stato ripetuto almeno una volta (che è quello che fa wasRepeated)...
Ma quanto e' comodo lavorare con i test? :)
E' fantastico :)
Ormai ho fatto il commit... Comunque serve un ulteriore stato... hasBeenRepeated non può riuscire a segnalare sia che il tasto deve essere ripetuto sia che è già stato ripetuto almeno una volta (che è quello che fa wasRepeated)...
Dunque, vi do' le linee guida per questo refactoring:
- L'interfaccia KeyEventHanlder deve contenere il minor numero possibile di metodi e possibilmente intuitivi; non e' il caso ora dove wasRepeated e hasBeenRepeated non sono particolarmente intuitivi.
- Idealmente InputReactor non dovrebbe contenere alcun codice che dipenda fortemente dalla particolare implementazione di Diamonds (sicuramente NON deve dipendere da classi del gioco tipo Grid): come potete vedere si sta trasformando sempre piu' in un componente molto astratto, generico e coeso, e questo e' un bene perche' lo rende piu' semplice da mantenere in futuro.
bene bene ora vediamo :)
cionci: il test di prima lo hai tenuto nel commit?
Allora ho fatto un piccolo commit che poi però ho revertato perchè non sono sicurissimo e preferisco pensare prima ad un test che possa far fallire la versione senza wasRepeated() ed ora non ho tempo per lavorarci :)
Buon weekend a tutti
Il test sopra l'ho messo nel repository... Togliendo wasRepeated ci sarebbe dovto essere un test che falliva... Entrambe le condizioni dell'if mi sono venute da due test distinti...
Comunque ho qualcosa in mente per il refactoring...
Che ne dite di rinominare KeyEventHandler in KeyHandler ? E poi togliamo la parola Event da tutte le interfacce che implementano KeyHandler...
E poi togliamo la parola Event da tutte le interfacce che implementano KeyHandler...
hmmm non ho ben capito quali intendi di preciso :p
Bello il refactoring, mi hai letto nel pensiero :D
tutte le interfacce = tutte le classi... Ho messo interfacce al posto di classi :)
Sì non volevo fare il pignolo :p... Intendevo dire che ci sarebbero solo AbstractKeyEventHandler e KeyEventHandler da cambiare...
Io propongo anche di rendere indipendente il nome di LeftKeyHandler Right... e Down... dal tasto a cui sono assegnati ma bensì identificarli come bind del tasto (MoveLeft, MoveRight, DropGem per esempio)...
Altrimenti adesso che mettiamo Z, X e C diventano ZKeyHandler, XKeyHandler e CKeyHandler, mentre è molto meglio RotateLeftKeyHandler, RotateRight... e SwitchGems (o qualcos'altro)
Sì...d'accordo, anche perchè presuppongo che in un secondo tempo i tasti saranno configurabili...
Sì non volevo fare il pignolo :p... Intendevo dire che ci sarebbero solo AbstractKeyEventHandler e KeyEventHandler da cambiare...
Io propongo anche di rendere indipendente il nome di LeftKeyHandler Right... e Down... dal tasto a cui sono assegnati ma bensì identificarli come bind del tasto (MoveLeft, MoveRight, DropGem per esempio)...
Altrimenti adesso che mettiamo Z, X e C diventano ZKeyHandler, XKeyHandler e CKeyHandler, mentre è molto meglio RotateLeftKeyHandler, RotateRight... e SwitchGems (o qualcos'altro)
Questa e' un'ottima idea.
Io però ripensandoci lascerei il postfisso KeyHandler, perchè di fatto è un KeyHandler...
Io però ripensandoci lascerei il postfisso KeyHandler, perchè di fatto è un KeyHandler...
Pero' se lo guardi bene sta diventando un Command Pattern :)
Io toglierei Key e lo renderei un'astrazione a livello piu' alto.
hmmm quindi tipo EventHandler?
In effetti sto studiando RMI e noto che potrebbero tranquillamente essere eventi generati da un NetworkEvent e non solo KeyEvent... Non so come spiegare... Forse non essendo ancora un task non dovrei ragionare così però ci sto lavorando sopra :p
Problemino:
se aggiungo/cancello/modifico qualche valore nella classe Config l'azione non si ripercuote nel file di configurazione... Inoltre perchè InputRate compare solo nel file XML e non nella classe?
Inoltre perchè InputRate compare solo nel file XML e non nella classe?
Perchè nei test l'input rate non serve...
Ufo: io lascerei wasRepeated... Ritorna vero se il tasto è stato ripetuto almeno una volta...al massimo la potremmo chiamare hasBeenRepeated...
secondo me è ambiguo nel senso che wasRepeated vuol dire "in passato è stato ripetuto". In realtà no perchè è true solo se sta ancora ripetendosi.
Visto che stiamo cercando di tenere una certa semantica rispetto alla lingua inglese secondo me è più corretto così...
Torna vero se il tasto è stato ripetuto fra la pressione del tasto e timeStamp...quindi non mi torna molto isRepeating...
diamo un significato diverso alla parola isRepeating:
tu per isRepeating intendi dire che in questo stesso istante il tasto sta per essere aggiornato in stato di "ripetizione".
io per isRepeating intendo dire che in questo stesso istante il tasto si trova in stato di "ripetizione".
Secondo me non è importante che sia l'inputrate a determinare che in questo istante il tasto sia ripremuto. Il fatto è che il tasto che è entrato in stato di "ripetizione" ci resta finchè non viene rilasciato quindi isRepeating è sempre valido anche se viene controllato tra 2 "aggiornamenti".
italiano rulez :p
capisco che isRepeating() non ti piaccia... Però sarai d'accordo sul fatto che anche wasRepeating() non è il massimo...
Per me un metodo wasRepeating ritorna true anche se il tasto ha avuto una ripetizione 10 secondi fa :)
ho una ripetizione, rilascio il tasto e dopo 10 secondi mi chiedo: in passato ha ripetuto? la risposta è "si". Questo non è quello che fa il metodo :)
io per isRepeating intendo dire che in questo stesso istante il tasto si trova in stato di "ripetizione".
Appunto...in quell'istante il tasto non si trova in stato "ripetizione"...perchè se ritorna true non è detto che il tasto stia per essere ripetuto adesso, ma può essere anche che sia stato ripetuto in passato...e non è detto che stia per essere ripetuto...
Allora semmai isRepeated...che indica che il tasto è in stato "ripetuto"...
ho una ripetizione, rilascio il tasto e dopo 10 secondi mi chiedo: in passato ha ripetuto? la risposta è "si". Questo non è quello che fa il metodo :)
Allora wasRepeatedAfterLastPressure...o hasBeenRepeatedAfterLastPressure...
direi che isRepeated() è più immediato
commitato :)
Cosa ne pensi dei nomi che ho dato a LeftKey etc?
Ho trovato un bug:
Quando le gemme scendono in coppia possono essere separate cercando di sorpassare un ostacolo solo con la gemma di sotto... viene anche generata un'eccezione e la gemma di sopra rileva una collisione a mezz'aria....
Altra cosa:
riempiendo la colonna normalmente appare "game over"
Provate a mettere una gemma (sfruttando il bug di prima spostatene subito dopo aver toccato il fondo) e poi continuate normalmente. Arrivati in cima....eccezione...
prima o poi dovremo anche risolvere il problema che il gioco impegna la CPU al 100%...
prima o poi dovremo anche risolvere il problema che il gioco impegna la CPU al 100%...
Veramente l'avevo risolto qualche mese fa...infatti a me occupa fra 0 e 25% di un Athlon64 @1474 Mhz...
Ho visto ora ed è il GameOver a occupare il 100%...forse quello che ha fatto il GameOver non ha messo nel ciclo il waitstate :ciapet:
Ho visto ora ed è il GameOver a occupare il 100%...forse quello che ha fatto il GameOver non ha messo nel ciclo il waitstate :ciapet: problema risolto: qualcuno aveva tolto il flag gameOver che io avevo APPOSITAMENTE usato in Game, e di conseguenza ad ogni ciclo veniva aggiunto un nuovo sprite "Game Over" :D
non lo togliete più per favore ;)
ora committo.
PS: avrei fatto un test, solo che il codice si trova in Game, e Game non ha test...
Piccolo problema con ant :(
Ho provato a impostarlo sotto eclipse, eseguo e...
test:
BUILD FAILED
/home/cover/.eclipse/Diamonds/build.xml:58: Could not create task or type of type: junit.
Ant could not find the task or a class this task relies upon.
This is common and has a number of causes; the usual
solutions are to read the manual pages then download and
install needed JAR files, or fix the build file:
- You have misspelt 'junit'.
Fix: check your spelling.
- The task needs an external JAR file to execute
and this is not found at the right place in the classpath.
Fix: check the documentation for dependencies.
Fix: declare the task.
- The task is an Ant optional task and the JAR file and/or libraries
implementing the functionality were not found at the time you
yourself built your installation of Ant from the Ant sources.
Fix: Look in the ANT_HOME/lib for the 'ant-' JAR corresponding to the
task and make sure it contains more than merely a META-INF/MANIFEST.MF.
If all it contains is the manifest, then rebuild Ant with the needed
libraries present in ${ant.home}/lib/optional/ , or alternatively,
download a pre-built release version from apache.org
- The build file was written for a later version of Ant
Fix: upgrade to at least the latest release version of Ant
- The task is not an Ant core or optional task
and needs to be declared using <taskdef>.
- You are attempting to use a task defined using
<presetdef> or <macrodef> but have spelt wrong or not
defined it at the point of use
Remember that for JAR files to be visible to Ant tasks implemented
in ANT_HOME/lib, the files must be in the same directory or on the
classpath
Please neither file bug reports on this problem, nor email the
Ant mailing lists, until all of these causes have been explored,
as this is not an Ant bug.
:stordita: :stordita: :stordita: :stordita:
problema risolto: qualcuno aveva tolto il flag gameOver che io avevo APPOSITAMENTE usato in Game, e di conseguenza ad ogni ciclo veniva aggiunto un nuovo sprite "Game Over" :D
non lo togliete più per favore ;)
ora committo.
PS: avrei fatto un test, solo che il codice si trova in Game, e Game non ha test...
Porta quel codice fuori da Game e aggiungi un test.
Piccolo problema con ant :(
Ho provato a impostarlo sotto eclipse, eseguo e...
:stordita: :stordita: :stordita: :stordita:
Clicca con il tasto destro sul buil.xml e in Run clicca su "Ant build...". In questo modo ti si apre la pagina delle proprietà. In Classpath clicca su Add Jars e seleziona junit dal elenco. Ora dovrebbe andare.
ciao ;)
L'SVN è di nuovo in down?
Verifico subito.
EDIT: Ora dovrebbe essere apposto ;)
Porta quel codice fuori da Game e aggiungi un test. fatto; il nome della funzione che ho creato però non mi sembra un granché: "mustShowGameOver".
qualcuno me ne propone un altro? :stordita:
Lo lascerei così:
if(controller.isGameOver() && !contoller.wasGameOverMessageShowed())
{
showGameOverMessage();
}
o qualcosa del genere...
C'era un bug in gemsAroundOfSameType, ecco il test che falliva:
public void testGemOfSameTypeWhenOnZeroColumn()
{
grid.insertGem(1, 5, gem1);
grid.insertGem(0, 5, gem2);
assertTrue("gems are not detected as having the same type", grid.gemsAroundOfSameType(gem1, 0, -1));
}
L'ho notato grazie ad un refactoring...
non so se voi ci fate caso, ma mi sembra che ci sia un bug del suono: a me sembra che la prima volta venga playato due volte quasi contemporaneamente (sento un leggero sdoppiamento all'inizio) mentre le volte successive tutto regolare... risulta anche a voi?
No...tanto c'è sempre in attesa la classe SoundBank che prealloca i suoni...così vediamo di risolvere tutti questi problemi...
Secondo me la build machine è down... Ci sono state diversi commit dopo la build corrente (per altro rotta)...ma non sono state fatte build...
DanieleC88
30-12-2005, 10:33
Secondo me la build machine è down... Ci sono state diversi commit dopo la build corrente (per altro rotta)...ma non sono state fatte build...
In effetti l'ultimo log che ho ricevuto e' stato di sabato... io pensavo di essere stato rimosso dalla mailing list per errore, vedo invece che non sono il solo. Boh! :wtf:
DanieleC88
30-12-2005, 10:35
Altra cosa:
riempiendo la colonna normalmente appare "game over"
Provate a mettere una gemma (sfruttando il bug di prima spostatene subito dopo aver toccato il fondo) e poi continuate normalmente. Arrivati in cima....eccezione...
Ah, allora l'aveva notato anche qualcun'altro... be', io nel fare il mio task ho notato la stessa cosa e ho provveduto (ho scritto il test e corretto il codice, appena committo il mio task committo anche la correzione). :)
Secondo me la build machine è down... Ci sono state diversi commit dopo la build corrente (per altro rotta)...ma non sono state fatte build... già, confermo, non arriva più nulla neanche a me.
già, confermo, non arriva più nulla neanche a me.
Non è che non arriva nulla...non fa proprio più le build...
Ho appena fatto l'update dal repository e ho un sacco di test che falliscono...è normale??
Sappiate che non hop ancora avuto la pazianza di buttarmi nel codice a capirci qualcosa....
Strano, a me funziona perfettamente ;)
fek, ma che build machine hai messo su...se poi non funziona? :asd: :asd: :asd:
è colpa di una finestra blu della morte :Prrr:
comunque non va nemmeno a me :(
fek, ma che build machine hai messo su...se poi non funziona? :asd: :asd: :asd:
è colpa di una finestra blu della morte :Prrr:
comunque non va nemmeno a me :(
La build machine non va, ma il codice nel repository passa tutti i test...
La build machine non va, ma il codice nel repository passa tutti i test...
Purtroppo e' caduta mentre ero via. Ora rifaccio il boot.
Avete ragione!!
I test sono passati tutti...ma quando faccio eseguire il task ant ad Eclipse mi dice che falliscono...si è ammalato Eclipse??? :mc: :mc:
:cry: :cry: :help:
Avete ragione!!
I test sono passati tutti...ma quando faccio eseguire il task ant ad Eclipse mi dice che falliscono...si è ammalato Eclipse??? :mc: :mc:
:cry: :cry: :help:
Che messaggio ti da di preciso eclipse nella console?
ciao ;)
Nemmeno a me ant è mai funzionato da Eclipse...ormai ci ho rinunciato... Mi completa il checkstyle e dopo si ferma...
VICIUS: ottimo refactoring il tuo ultimo ;)
VICIUS: ottimo refactoring il tuo ultimo ;)
Infatti mi hai ispirato un refactoring di Grid che mi ha permesso di togliere 8 metodi ed aggiungerne due... Grande !!!
Comunque non so se ve ne siete accorti, ma le gemme una volta che hanno colliso reagisconoa cnora all'input !!! :D
Corretto... Credo inoltre che quando una gemma collide l'altra debba scendere accelerata...magari potrebbe fare parte di un nuovo task...
Nemmeno a me ant è mai funzionato da Eclipse...ormai ci ho rinunciato... Mi completa il checkstyle e dopo si ferma...
prova reinstallare eclipse da un altra parte(mantenendo cmq la versione che gia hai), con me ha funzionato ;)
io ho la versione:
Version: 3.1.1
Build id: M20050929-0840
Proverò, ma mi va bene anche così, tanto mi basta vedere il risultato di checkstyle...i risultati dei test già li conosco...
Nemmeno a me ant è mai funzionato da Eclipse...ormai ci ho rinunciato... Mi completa il checkstyle e dopo si ferma...
ti dice per caso questo?
BUILD FAILED
/home/cover/.eclipse/Diamonds/build.xml:58: Could not create task or type of type: junit.
Clicca con il tasto destro sul buil.xml e in Run clicca su "Ant build...". In questo modo ti si apre la pagina delle proprietà. In Classpath clicca su Add Jars e seleziona junit dal elenco. Ora dovrebbe andare.
Clicca con il tasto destro sul buil.xml e in Run clicca su "Ant build...". In questo modo ti si apre la pagina delle proprietà. In Classpath clicca su Add Jars e seleziona junit dal elenco. Ora dovrebbe andare.
:ave: :stordita:
VICIUS: ottimo refactoring il tuo ultimo ;)
Troppo buono :D
ciao ;)
La build machine sembra non dare segni di vita. Oggi pomeriggio la prendo a calci e vi dico qualcosa.
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.