[CICLO 4] Storia 2

[cionci]

71104: hai rifatto il commit, ma erano i tuoi sorgenti ad essere indietro rispetto al mio aggiornamento...

[^TiGeRShArK^]

ehm...
colgo l'occasione per ricordare di fare SEMPRE l'update prima di fare il commit....
in questo modo potremmo fare eventuali merge e quindi committare il codice corretto...

[BlueDragon]

Originariamente inviato da fek

Ragazzi, i task sono perfettamente chiari prima di cominciare? Nessun dubbio?

Dopo aver "giocato" un po' con il task 4.2.2 mi sono reso conto che i task non sono chiari..chiedo scusa per non averlo detto prima.
Anzi, per la verità leggendo la storia non è chiaro quali funzionalità si vogliano aggiungere (a parte la gravità aumentata) e perché stiamo implementando una coda per ottenerle.
E' chiaro che conoscendo il gioco ed il codice io ho un'idea di cosa manchi alla gestione di input per raggiungere un certo livello di risposta, ma questa mancanza non è stata esplicitata chiaramente (secondo me) né nella storia né nei task..anzi, seguendo l'idea che ho in mente mi viene da pensare che il task 4.2.3 non sia nemmeno giusto rispetto a quello che io penso Jocchan voglia ottenere, ma che sia stato scelto su supposizioni a livello di codice attuale.

Per chiarire, vi esprimo sotto forma di test come penso dovrebbe essere la gestione dell'input.

Queste sono due cose che già siamo capaci di gestire con il vecchio codice:

1) Mentre il tasto rimane premuto, non ripetere il movimento prima che sia passato il delay:

grid.insertGem(2, 5, gem);
grid.setGemUnderControl(gem);
input.generateKeyEvent(KeyCode.vk_Left, KeyState.Pressed);
grid.reactToInput(input, timer);
timer.setTime(timer.getTime() + grid.getInputDelay() - 1);
grid.reactToInput(input, timer);
assertTrue( "Gem has moved more than once with Left being pressed for less than Delay",
grid.isGemAt(2, 4));

2) Il tasto rimane premuto, ripetere il movimento ogni tot millisecondi:

grid.insertGem(2, 5, gem);
grid.setGemUnderControl(gem);
input.generateKeyEvent(KeyCode.vk_Left, KeyState.Pressed);
grid.reactToInput(input, timer);
timer.setTime(timer.getTime() + grid.getInputDelay()+1);
grid.reactToInput(input, timer);
assertTrue( "Gem isn't moving according to the correct delay with Left Key being pressed",
grid.isGemAt(2, 3));

3) Se teniamo il tasto premuto a lungo, comunque la gemma deve smettere di muoversi appena lasciamo il tasto:

(stesso test di prima con una aggiunta)
grid.insertGem(2, 5, gem);
grid.setGemUnderControl(gem);
input.generateKeyEvent(KeyCode.vk_Left, KeyState.Pressed);
grid.reactToInput(input, timer);
timer.setTime(timer.getTime() + grid.getInputDelay()+1);
grid.reactToInput(input, timer);
assertTrue( "Gem isn't moving according to the correct delay with Left Key being pressed",
grid.isGemAt(2, 3));
input.generateKeyEvent(KeyCode.vk_Left, KeyState.Released);
timer.setTime(timer.getTime() + grid.getInputDelay()+1);
grid.reactToInput(input, timer);
assertTrue( "Gem didn't stop moving after Key being released",
grid.isGemAt(2, 3));

Queste invece sono delle cose che non siamo capaci di gestire con il codice vecchio, e che secondo me sono richieste da Jocchan nella sua descrizione della storia:

4) Se l'utente preme due volte nella stessa direzione rapidamente, il gioco deve rispondere due volte, non deve attendere il delay (qui ci serve la gestione degli eventi per distinguere due pressioni successive):

grid.insertGem(2, 5, gem);
grid.setGemUnderControl(gem);
input.generateKeyEvent(KeyCode.vk_Left, KeyState.Pressed);
input.generateKeyEvent(KeyCode.vk_Left, KeyState.Released);
input.generateKeyEvent(KeyCode.vk_Left, KeyState.Pressed);
input.generateKeyEvent(KeyCode.vk_Left, KeyState.Released);
grid.reactToInput(input, timer);
assertTrue( "Gem didn't move twice with left pressed twice by user.",
grid.isGemAt(2, 3));

Perché non deve attendere il delay? Perché il gioco deve rispondere prontamente, ed il delay a mio parere è stato introdotto *solo* per evitare che la gemma non si muovesse troppo velocemente tenendo premuto il tasto, non per imporre lag al giocatore


5) Se l'utente preme rapidamente due volte verso sinistra e poi a destra, il gioco deve riprodurre correttamente tutta la sequenza (ed ecco che ci serve la coda):

grid.insertGem(2, 5, gem);
grid.setGemUnderControl(gem);
input.generateKeyEvent(KeyCode.vk_Left, KeyState.Pressed);
input.generateKeyEvent(KeyCode.vk_Left, KeyState.Released);
input.generateKeyEvent(KeyCode.vk_Left, KeyState.Pressed);
input.generateKeyEvent(KeyCode.vk_Left, KeyState.Released);
input.generateKeyEvent(KeyCode.vk_Right, KeyState.Pressed);
input.generateKeyEvent(KeyCode.vk_Right, KeyState.Released);
grid.reactToInput(input, timer);
assertTrue( "Grid didn't react correctly to fast sequence.",
grid.isGemAt(2, 4));

Non mi ricordo se volevo aggiungere anche un altro test, ma mi ci è voluto un po' per fare tutto questo, quindi mi fermo qui..spero sia venuto abbastanza chiaro

Dragoblu

PS: Avevo provato a dire tutto a parole ma era un incubo scrivere un post decente...meno male che ci sono i test..

[fek]

Perché non deve attendere il delay? Perché il gioco deve rispondere prontamente, ed il delay a mio parere è stato introdotto *solo* per evitare che la gemma non si muovesse troppo velocemente tenendo premuto il tasto, non per imporre lag al giocatore

Jocchan, un commento su questo?

[cionci]

Originariamente inviato da fek

Jocchan, un commento su questo?

Ne ho già parlato con VICIUS e Jocchan e la modifica che ho fatto io punta proprio a questo... Eliminare il delay e spostare la generazione di eventi per il tasto ripetuto in un'altra classe...
VISIUS mi ha detto di trasporta il tutto nel main branch, ma sto trovando qualche difficoltà, anche perchè la cosa diventa abbastanza complessa se deve funzionare per tutti i tasti e non solo per destra e sinistra (come avevo fatto in InputTest)...

[fek]

Originariamente inviato da cionci

Ne ho già parlato con VICIUS e Jocchan e la modifica che ho fatto io punta proprio a questo... Eliminare il delay e spostare la generazione di eventi per il tasto ripetuto in un'altra classe...
VISIUS mi ha detto di trasporta il tutto nel main branch, ma sto trovando qualche difficoltà, anche perchè la cosa diventa abbastanza complessa se deve funzionare per tutti i tasti e non solo per destra e sinistra (come avevo fatto in InputTest)...

Esatto, per questo sono ancora convinto che la soluzione della coda di input sia la migliore, perche' ci permette di analizzare in reactToInput gli eventi e gestirli di conseguenza.

[cionci]

Ma la coda rimane... L'unica cosa che cambia è che al posto del BitSet c'è la classe che sto mettendo a punto... Ed è questa stessa classe che può generare gli eventi e metterli in coda...

[fek]

Originariamente inviato da cionci

Ma la coda rimane... L'unica cosa che cambia è che al posto del BitSet c'è la classe che sto mettendo a punto... Ed è questa stessa classe che può generare gli eventi e metterli in coda...

Perfetto
La stai scrivendo TestDriven? O meglio, consideriamo il tuo come uno spike e la riscriviamo TestDriven io e te nel main branch domani pomeriggio?

[BlueDragon]

Originariamente inviato da cionci

Ne ho già parlato con VICIUS e Jocchan e la modifica che ho fatto io punta proprio a questo... Eliminare il delay e spostare la generazione di eventi per il tasto ripetuto in un'altra classe...
VISIUS mi ha detto di trasporta il tutto nel main branch, ma sto trovando qualche difficoltà, anche perchè la cosa diventa abbastanza complessa se deve funzionare per tutti i tasti e non solo per destra e sinistra (come avevo fatto in InputTest)...

Facendo delle prove sul codice io penso di essere riuscito ad implementare il necessario per passare i test di cui sopra e non è troppo ingarbugliato, anzi.
Ho usato la coda fornita dal Task 4.2.2, semplicemente aggiungendo la parte in KeyboardImplementation affinché venga eseguito un input.generaKeyInput per ogni evento della tastiera LWJGL (che ha anch'essa una coda e segnala 1 evento per la pressione ed 1 evento per il rilascio, non ci sono eventi di "tastoTenutoPremuto" per la Keyboard di LWJGL).
Dopodiché, nel reactToInput di Grid estraggo tutti gli eventi dalla nostra coda ed eseguo le seguenti attività:
1) Per ogni evento su KeyDown, moltiplico o riporto a normale la gravità (a seconda se l'evento è pressed o released).
2) Se ci sono eventi di Pressed su Left o Right, li eseguo tutti immediatamente, non importa il delay. Però mi segno il timestamp di quando li eseguo.
3) Se "isLeftKeyPressed()" (o isRightKeyPressed()) è true ed è passato abbastanza tempo dall'ultima volta che mi sono mosso, ripeto il movimento.

Dovrebbe soddisfare i test che ho elencato..non ne sono sicuro perché ho scritto il codice "tanto per giocare" e solo dopo, quando ho avuto la necessità di postare e spiegarmi, ho creato i test.
Ora provo ad applicarli per vedere se il codice passa...

PS: Sono loggato sul nostro canale IRC:
Canale: #diamond_crush
Server: irc.azzurra.org
Porte: 6665-6667

[cionci]

Domani non ci sono...e non l'ho scritta testDriven
Visto lo spike credevo di fare poche modifche per farne un'altro... Invece non sono poi poche

Ti posso dare quello che ho scritto fino ad adesso, il funzionamento è davvero elementare... Certo, i test ci vorrebbero, ma ora non ho tempo di farli...

Il problema principale è questo, io credevo che venissero ripetuti gli eventi di tasto giù fino a quando il tasto rimane premuto...invece LJWGL non li ripete...

Quindi mi trovo in difficoltà perchè lo stato dei tasti della mia classe dovrebbe essere aggiornato ogni volta, per generare gli eventuali tasti ripetuti...

Io ti posto il codice, caso mai servisse... Purtroppo mi devo fermare...

package it.diamonds.engine.input;

import java.util.Map;
import java.util.HashMap;
import it.diamonds.engine.input.Input.KeyCode;


public class KeyboardState
{ 
    private Map<Integer, KeyState> keysState;
    
    private class KeyState
    {
        private boolean isPressed = false;
        private long timeStamp = 0;

        public KeyState()
        {
        }

        
        public void update(boolean isPressed, long timeStamp)
        {
            if(this.isPressed != isPressed)
            {
                this.timeStamp = timeStamp;
                this.isPressed = isPressed;
                //qui potrebbe essere generato un evento da mettere in coda
            }
            else if(this.isPressed && timeStamp - this.timeStamp > 200)
            {
               this.timeStamp = timeStamp;
               //qui ptorebbe essere generato un evento da mettere in coda
            }
            
        }
        
        
        public boolean isPressed()
        {
            return isPressed;
        }

        
        public long getTimeStamp()
        {
            return timeStamp;
        }
        
    
        public boolean isStateChanged(long timeStamp)
        {
            return timeStamp <= this.timeStamp;
        }

    }
    
    
    public KeyboardState()
    {
        keysState = new HashMap<Integer, KeyState>();
    }
    
    
    public void updateKey(int key, boolean state, long timeStamp)
    {
        if(!keysState.containsKey(key))
            keysState.put(key, new KeyState());
        
        keysState.get(key).update(state, timeStamp);
    }

    
    public boolean isKeyPressed(int key)
    {
        if(!keysState.containsKey(key))
            return false;
            
        return keysState.get(key).isPressed();
    }

    
    public long getTimeStamp(KeyCode key)
    {
        if(!keysState.containsKey(key))
            return 0;

        return keysState.get(key).getTimeStamp();
    }
    
    
    public boolean isStateChanged(int key, long timeStamp)
    {
        if(!keysState.containsKey(key))
            return false;

        return keysState.get(key).isStateChanged(timeStamp);
    }
    
}

[cionci]

Originariamente inviato da BlueDragon

3) Se "isLeftKeyPressed()" (o isRightKeyPressed()) è true ed è passato abbastanza tempo dall'ultima volta che mi sono mosso, ripeto il movimento.

Se memorizzi due timeStamp distinti e azzeri i timeStamp se il tasto viene rilasciato allora è ok... Ed è anche una buona soluzione...anzi sicuramente più semplice della mia...

[BlueDragon]

Originariamente inviato da cionci

Se memorizzi due timeStamp distinti e azzeri i timeStamp se il tasto viene rilasciato allora è ok... Ed è anche una buona soluzione...anzi sicuramente più semplice della mia...

Sì, ogni volta che "ripeto il movimento" aggiorno il timeStamp, affinché sia necessario un altro intervallo di delay prima di ripetere ancora.
Per quanto riguarda la separazione in due timeStamp, uno per il tasto destro ed uno per sinistro, in teoria sembra necessario (io avrei voluto farlo già qualche task fa) ma nella pratica non lo è.
Se c'è un solo tasto premuto, usa lui la variabile del timestamp.
Se ce ne sono due premuti assieme, la possono comunque condividere, anzi è anche meglio.

Se ci fossero due timestamp infatti la sequenza sarebbe questa:
Time/Action
0.000 L'utente preme Left, la gemma si sposta a sinistra
0.007 L'utente preme Right, la gemma ritorna a destra
0.010 Delay passato per Left, la gemma si sposta a sinistra
0.017 Delay passato per Right, la gemma ritorna a destra
0.020 Delay passato per Left, la gemma si sposta a sinistra
0.027 Delay passato per Right, la gemma ritorna a destra
[etc etc]
Quindi la gemma fa avanti ed indietro continuamente..

Con un solo timestamp:
Time/Action
0.000 L'utente preme Left, la gemma si sposta a sinistra
0.007 L'utente preme Right, la gemma ritorna a destra
0.017 Delay passato per Left & Right, Grid applica un avanti ed indietro ma quando viene chiamato il render(), la gemma sembra non essersi mossa
0.027 Delay passato per Left & Right, Grid applica un avanti ed indietro ma quando viene chiamato il render(), la gemma sembra non essersi mossa
0.037 Delay passato per Left & Right, Grid applica un avanti ed indietro ma quando viene chiamato il render(), la gemma sembra non essersi mossa
[etc etc]

Per quanto riguarda il momento del rilascio, credo che in entrambe le implementazioni ci sia il rischio che venga riprodotto un singolo movimento a sinistra o a destra, a seconda della sua rapidità nel sollevare le dita. Comunque testando visivamente il codice non sembra capitare così spesso come accadeva con il codice precedente. Da vedere con Jocchan quanta precisione vuole...in fondo nel gioco non vedo perché qualcuno debba tenere a lungo premuti entrambi i tasti

Ora ceno dopo metto il codice che ho scritto sotto test

[fek]

Originariamente inviato da cionci

Domani non ci sono...e non l'ho scritta testDriven
Visto lo spike credevo di fare poche modifche per farne un'altro... Invece non sono poi poche

Ti posso dare quello che ho scritto fino ad adesso, il funzionamento è davvero elementare... Certo, i test ci vorrebbero, ma ora non ho tempo di farli...

Ok, allora Jocchan puo' testare l'idea nel branch e darci il suo parere. Se accetta l'idea la riscrivi daccapo Test Driven. Adesso preferisco imporre che tutto il codice di produzione senza eccezioni sia Test Driven.

[cionci]

Jocchan l'ha già testata...ha detto che gli piace...

[cionci]

Originariamente inviato da BlueDragon

Se ci fossero due timestamp infatti la sequenza sarebbe questa:
Time/Action
0.000 L'utente preme Left, la gemma si sposta a sinistra
0.007 L'utente preme Right, la gemma ritorna a destra
0.010 Delay passato per Left, la gemma si sposta a sinistra
0.017 Delay passato per Right, la gemma ritorna a destra
0.020 Delay passato per Left, la gemma si sposta a sinistra
0.027 Delay passato per Right, la gemma ritorna a destra
[etc etc]
Quindi la gemma fa avanti ed indietro continuamente..

Ma con un solo delay questa situazione è gestita male:
0.000 L'utente preme Left, la gemma si sposta a sinistra
0.007 L'utente preme Right, la gemma non si sposta a destra
0.010 Delay passato per Left, la gemma si sposta a sinistra

Quindi due spostamenti a sinistra con uno solo che sarebbe dovuto avvenire...

[fek]

Originariamente inviato da cionci

Jocchan l'ha già testata...ha detto che gli piace...

Ok, in tal caso la inserira come prossima storia e possiamo creare i task relativi.

[BlueDragon]

Originariamente inviato da cionci

Ma con un solo delay questa situazione è gestita male:
0.000 L'utente preme Left, la gemma si sposta a sinistra
0.007 L'utente preme Right, la gemma non si sposta a destra
0.010 Delay passato per Left, la gemma si sposta a sinistra

Quindi due spostamenti a sinistra con uno solo che sarebbe dovuto avvenire...

No, viene gestita bene
Quando vengono ricevuti gli eventi di pressione, essi vengono eseguiti senza considerare il timestamp. Vengono eseguiti e basta, così come vuole l'utente.

Il timestamp serve solo per controllare se un certo tasto è stato tenuto premuto per più di un certo tempo.

Cmq il mio codice funziona e supera i test che avevo proposto...se volete cancello tutto e riscrivo (o riscriviamo a più mani) partendo dai Test.

[fek]

Originariamente inviato da BlueDragon

No, viene gestita bene
Quando vengono ricevuti gli eventi di pressione, essi vengono eseguiti senza considerare il timestamp. Vengono eseguiti e basta, così come vuole l'utente.

Il timestamp serve solo per controllare se un certo tasto è stato tenuto premuto per più di un certo tempo.

Cmq il mio codice funziona e supera i test che avevo proposto...se volete cancello tutto e riscrivo (o riscriviamo a più mani) partendo dai Test.

Lavora pure nel branch di cionci e implementa anche questa soluzione, magari dietro uno switch per passare da una all'altra. Poi la decisione di che cosa fare e' solo di Jocchan.

Direi di portare questa Storia al prossimo Ciclo e usiamo la scorsa settimana come spike su questo problema che non e' di poca importanza.

[Jocchan]

Sono mancato per tutto il tardo pomeriggio, quindi rispondo solo ora.
Il lavoro di Cionci è stato ottimo, dato che il gioco risponde prontamente a tutti i comandi (e sono rimasto a picchiettare sui tasti a velocità folli... tutto sempre perfetto).
L'unico difetto è che premendo contemporaneamente sia sinistra che destra la gemma sembra sparire per un istante, ma questo si può correggere.
La velocità va un pò calibrata, sto smanettando con i settaggi e mi sto facendo un'idea, ma per il resto mi sembra che già la "Cionci version" vada più che bene.
Se, a parte questo piccolo difetto che possiamo considerare un bug, abbiamo soddisfatto i requisiti della storia (una pronta risposta agli input del giocatore), allora cosa manca ancora?

[71104]

Originariamente inviato da cionci

71104: hai rifatto il commit, ma erano i tuoi sorgenti ad essere indietro rispetto al mio aggiornamento...

cheee?? O_o
ti assicuro che è impossibile, io prima di iniziare a lavorare lo faccio sempre l'update... O_o oltrettutto non penso sia mai esistita nel repository una revisione che da' eccezione per mancanza di parametri in Config... secondo me era un problema di Tortoise... comunque vabbè, ora ripiglio il task e penso ai test.