[CICLO 10] Storia 1

[cionci]

Ho fatto l'update...

[cionci]

Ho finito il refactoring...

Volevo porre l'attenzione sulla modifica che ho fatto al metodo di calcolo degli aggiornamenti dei timer... Questo tipo di aggiornamento è sicuramente più preciso (e non di poco), ma ha un side effect...

Provate a trascinare la finestra dell'applicazione e vedete come reagisce il gioco, non mi piace molto... A voi la scelta...

[Ufo13]

Secondo me è giusto così...

Il gioco deve andare avanti anche se trascini la finestra altrimenti metti il caso della partita online ed uno dei due giocatori si mette a trascinare la finestra a casaccio! Non si deve perdere il sync in quel caso...

Noto però che le gemme player 1 e player 2 escono un po' sfalsate... Non sarebbe meglio sistemare?

[cionci]

Sfasate ? A me non mi sembra... Ora provo...a vedere meglio...

[cionci]

Dovrei aver risolto...

[Ufo13]

come mai i test su PlayField sono su ignore?

Per il sync delle gemme non hai aggiunto un test?

Ottima idea comunque a mio parere quella del PlayField

[VICIUS]

Possibile che nessuno voglia prendersi l'ultimo task ?

ciao

[thebol]

Originariamente inviato da VICIUS

Possibile che nessuno voglia prendersi l'ultimo task ?

ciao

prendo io

tempo 2 giorni

[cionci]

Originariamente inviato da Ufo13

come mai i test su PlayField sono su ignore?

Per il sync delle gemme non hai aggiunto un test?

Mi sono scordato di spostarlo

Per il sync era la soluzione che avevo adottato prima non testata (da me stupidamente inserita)...quella che c'è ora è una semplice inizializzazione a 0... Ed il sync è mantenuto automaticamente...

[VICIUS]

Originariamente inviato da thebol

prendo io

tempo 2 giorni

Perfetto.

ciao

[cionci]

Originariamente inviato da thebol

prendo io

tempo 2 giorni

Consiglio...giocati bene l'assegnazione dei tasti... Potrebbe essere ottimale farla nei factory method di playfield...

[thebol]

Originariamente inviato da cionci

Consiglio...giocati bene l'assegnazione dei tasti... Potrebbe essere ottimale farla nei factory method di playfield...

ci stavo gia pensando, anche se nn ho ancora bene individuato dove...

[thebol]

Avrei quasi finito, ho spostato la creazione e assegnazione degli handler in playField, ho abilitato l'input in game.processInput() e creato i nuvoi collegamenti fra i keyEvent nuovi e i rispettivi tasti in ogl in Keyboard

Poi ho dovuto modificare il comportamento di inputReactor.reactToInput, perche al suo passaggio, estrava da input tutte le chiavi(i tasti premuti) e alla seconda griglia non arrivava nulla

    public void reactToInput(TimerInterface timer)
    {
        lastInputTimeStamp = timer.getTime();

        
        for (Iterator<KeyEvent> iter = input.iterator(); iter.hasNext();)
        {
            KeyEvent event = iter.next();
            if (isHandleableKeyEvent(event))
            {
                handleKeyEvent(event);
                iter.remove();
            }
        }

        handleKeyRepetition();
    }

ho implemento in input iterable per usare l'iteratore.

Tutto perfetto in teoria, tranne che in MoveLeftCommandHandler e il suo compagno MoveRightCommandHandler.

Questi hanno cablato al loro interno KeyEvent.Right e viceversa, per il controllo sulla pressione simultanea.

Il problema e che ho creato dei nuovi keyEvent relativi al num_pad, per cui quei valori cablati creano un bel null pointer.

Cosi a caldo mi vengono in mente 2 soluzioni:
usiamo 2 input diversi, con 2 keyboard diverse con la prima keyboard legata ai tasti di P1(keyMap[KEY_UP] = KeyEvent.UP, etc) e la seconda legata al p2 (keyMap[KEY_NUMPAD8] = KeyEvent.UP).

In questa maniera risolvo il problema dei move...CommandHandler, e posso togliere il refactoring in reactToInput.

La seconda idea, e creare un ulteriore strato fra keyEvent e la keyMap in KeyBoard, dove mappare keyEvent con keyHanler, e keyEvent con keyMap di ogl.

In questa manire il mapping fra keyEvent è Handler rimane inalterato per i player, cambia solo il mapping fra keyEvent e il tasto effettivo sulla keyboard.

KeyEvent diverrebbe un tasto "logico".


Ditemi cosa ne pensate, che domani provo(ma nn garantisco..domani sera devo uscire a cena..) a finire

[VICIUS]

Originariamente inviato da thebol

ho implemento in input iterable per usare l'iteratore.

Non si puo usare un foreach qui ?

Originariamente inviato da thebol

Tutto perfetto in teoria, tranne che in MoveLeftCommandHandler e il suo compagno MoveRightCommandHandler.

Questi hanno cablato al loro interno KeyEvent.Right e viceversa, per il controllo sulla pressione simultanea.

Il problema e che ho creato dei nuovi keyEvent relativi al num_pad, per cui quei valori cablati creano un bel null pointer.

Cosi a caldo mi vengono in mente 2 soluzioni:
usiamo 2 input diversi, con 2 keyboard diverse con la prima keyboard legata ai tasti di P1(keyMap[KEY_UP] = KeyEvent.UP, etc) e la seconda legata al p2 (keyMap[KEY_NUMPAD8] = KeyEvent.UP).

In questa maniera risolvo il problema dei move...CommandHandler, e posso togliere il refactoring in reactToInput.

La seconda idea, e creare un ulteriore strato fra keyEvent e la keyMap in KeyBoard, dove mappare keyEvent con keyHanler, e keyEvent con keyMap di ogl.

In questa manire il mapping fra keyEvent è Handler rimane inalterato per i player, cambia solo il mapping fra keyEvent e il tasto effettivo sulla keyboard.

KeyEvent diverrebbe un tasto "logico".


Ditemi cosa ne pensate, che domani provo(ma nn garantisco..domani sera devo uscire a cena..) a finire

Preferisco di gran lunga la seconda soluzione. Creare due keyboard diverse è un hack che non mi piace per niente.

ciao

[cionci]

IMHO anche duplicare la keyboard non sarebbe poi una brutta idea...comunque la seconda è una soluzione nettamente più bella

[thebol]

[quote=VICIUS]Non si puo usare un foreach qui ?
[\quote]
il foreache non mi da la remove(avevo iniziato con quello...)

Preferisco di gran lunga la seconda soluzione. Creare due keyboard diverse è un hack che non mi piace per niente.
ciao

ok, vada per la seconda.

cosi a naso direi che sposterò la hashmap keyMap[KEY_NUMPAD8] = KeyEvent.UP in inputReactor.

in questa maniera l'associazione inputHandler -> eventKey ritornerà in gridController, mentre in playField assegnero la keyMap bottone logico -> bottone fisico.


ps.sono d'accordo sul log error nel file, ma cmq continuerei a stamparlo in console, è scomodo in fase di sviluppo andarsi a guardare un file di log se crasha tutto...

pps.ma le key di KeyEvent(ora degli int) perche non trasformarle in enum?
a fine task ci guarderò

[fek]

Originariamente inviato da thebol

In questa manire il mapping fra keyEvent è Handler rimane inalterato per i player, cambia solo il mapping fra keyEvent e il tasto effettivo sulla keyboard.

KeyEvent diverrebbe un tasto "logico".

Si'. Prosegui con questa soluzione.

[VICIUS]

thebol News? Siamo piuttosto in ritardo e pensare che i task erano piuttosto facili

ciao

[thebol]

Originariamente inviato da VICIUS

thebol News? Siamo piuttosto in ritardo e pensare che i task erano piuttosto facili

ciao

finito adesso(ho scoperto un bug, e per vedere se ero stato io ho fatto un revert..)

cmq alla fine ho fatto il mapping tasto logico -> tasto fisico.

Questo mapping l'ho messo in Input, percui ora ogni inputReactor avra il proprio Input.

Rimane invece in comune la keyboard.

Pero questo ha portato a un problema, cioè la keyboard gestiva solo un input alla volta..ma ho risolto in fretta con un arrayList(ora una keybord puo gestire n input).

Il mapping tasto logico tasto fisico viene inizializzato in Game.


Inoltre ho tolto il refactoring su inputReactor.reactToInput, che non serviva piu

commitato ora

[VICIUS]

ciclo chiuso.