View Full Version : [CICLO 10] Storia 1
Storia: Introduzione di una griglia secondaria, in grado di contenere gli stessi oggetti della principale già in uso, e controllata da un secondo giocatore mediante il tastierino numerico (8, 4, 6 e 2 per le 4 direzioni; 7, 9 e 5 per Z, X e C).
La coda di gemme da creare deve essere inizialmente uguale per i due giocatori. Ogni volta che una coppia di gemme collide, ed una nuova coppia viene aggiunta in coda, la stessa coppia deve essere aggiunta anche nella coda dell’altro giocatore, in maniera da conservare l’uguaglianza delle due code in ogni situazione possibile.
Il secondo box Score deve inoltre riportare il punteggio dell’avversario, similmente a quello già presente, ed allo stesso modo il secondo box Next deve riportare la prossima coppia in caduta nello schermo dell’avversario, in maniera simile a quanto già accade per il giocatore.
Punti cardine da tenere a mente durante i lavori:
* Mai fare a gara a chi finisce il task per primo, meglio procedere con calma, altrimenti perderemo molto più tempo in seguito
* Evitiamo di complicarci la vita, esiste di certo una soluzione più semplice di quella che abbiamo pensato di implementare
* MAI aggiungere elementi non richiesti esplicitamente dai task: se mai serviranno, se ne parlerà nelle prossime storie
* Comunichiamo il più possibile, se qualcosa non è chiaro discutiamone tutti i dettagli fino ad eliminare ogni dubbio, anche il più insignificante
* Postare sempre la test list PRIMA di mettere mano al codice
Ecco i task (sono di Vicius, li posto io così, anche senza essere io moderatore, possiamo modificarli entrambi):
10.1.1: ^TiGeRShArK^ + cionci: Completato
Creare una nuova griglia controllabile tramite tastiera nella zona destra dello schermo alle coordinate x=524 y=32.
10.1.2: ^TiGeRShArK^: Completato
Creare un secondo box per visualizzare il punteggio alle coordinate x=419 y=421 e attaccarlo alla seconda griglia.
10.1.3: cionci: Completato
Le due code delle nuove gemme da creare devono essere distinte ma produrre sempre la stessa sequenza di gemme.
10.1.4: cdimauro: completato
Creare un secondo box che mostra la prossima GemPair che verrà creata nella seconda griglia alle coordinate x=476 y=32
E fare in modo che mostri la prossima coppia presente nella coda associata alla seconda griglia.
10.1.5: thebol: 2 giorni
Aggiungere i tasti e gli handler necessari al secondo giocatore per controllar la gemma pivot nella seconda griglia.
I Tasti per il secondo giocatore sono:
8 -> Su
2 -> Giu
4 -> Sinistra
6 -> Destra
7 -> Z
9 -> X
5 -> C
Ciao ;)
Mi prenoto per il 10.1.3 però da svolgere solo a partire da giovedì pomeriggio o venerdì, comunque sempre dopo il completamento dei task precedenti...
Acceptance test:
- dopo N estrazioni vengono estratte altre M gemme identiche da entrambe le code
Dopo tutto credo che questo task sia molto semplice, visto che basterà utilizzare due generatori casuali inizializzati con lo stesso seed...
^TiGeRShArK^
07-02-2006, 22:52
mi proporrei per il 2...
però lo potrei fare domani sera... ormai oggi è tardi x me..
Acceptance test:
- dopo N estrazioni vengono estratte altre M gemme identiche da entrambe le code
Dopo tutto credo che questo task sia molto semplice, visto che basterà utilizzare due generatori casuali inizializzati con lo stesso seed...
Ah...il tempo... Metto 2 giorni...tante volte ci fossero imprevisti...
mi proporrei per il 2...
però lo potrei fare domani sera... ormai oggi è tardi x me..
Venduto! :D
ciao ;)
^TiGeRShArK^
08-02-2006, 00:21
ovviamente metto come tempo 2 giorni per sicurezza, ma credo di cavarmela in un giorno..... :Prrr:
^TiGeRShArK^
08-02-2006, 21:08
ehm...ma il task 1 ancora non l'ha fatto nessuno??? :confused:
allora mi sa ke inizio a farlo io, xkè altrimenti non posso fare il 2 :fagiano:
^TiGeRShArK^
08-02-2006, 21:38
ehm... sono arrivato ad una piccola scelta di design...
Per quanto riguarda il GridController, dato ke esso controlla un solo gemspair e una sola griglia, mi sa ke conviene anke creare un nuovo gridController anzikè gestire all'interno del gridController la griglia per il P1 e per il P2...
ma così facendo avremo ripercussioni sulla gestione degli input (non ho idea di come sia cambiata quella parte... è da un pò ke non leggo il codice....)
intanto proseguo sulla strada della duplicazione del gridController... se ci sono controindicazioni evidenti ke mi sono sfuggite....avvisatemi :D
In questo momento ti dovrebbe bastare duplicare il gridController... In questo modo chiaramente il GridController su cui viene chiamato prima reactToInput si prende tutti gli input (InputReactor si dovrebbe duplicare automaticamente perchè viene istanziato nella create di GridController)...
^TiGeRShArK^
08-02-2006, 22:00
fatto..
ma mi sfugge qualcosa... le gemme vengono create solo nella prima griglia....
e inoltre sono trasparenti..
ora vedo se mi sono dimenticato qualcosa...
Lo fai l'update sia della prima che della seconda griglia ?
Eehhehe...mi sa che non è così semplice... Bisogna dare una "origine" alla griglia... Tutti i disegni sono stati fatti in base alla griglia corrente...
^TiGeRShArK^
08-02-2006, 22:09
:fiufiu:
:D
Infatti questi non vanno più bene:
private static final int TOP = 32;
private static final int LEFT = 20;
private static final int WIDTH = 256;
private static final int HEIGTH = 448;
Credo che convenga passare un Rect a Gridcontroller...magari fai un factory method per il player1 ed un factory method per il player2...
^TiGeRShArK^
08-02-2006, 22:24
quelli in gridcontroller li avevo già aggiornati...
avevo preferito passargli un boolean isPlayer1 ke mi pareva più "leggero" e leggibile per distinguerli..
infatti le griglie le disegna al posto giusto....
il problema sono le gemme..
sto cercando il codice dove viene inizializzata la loro posizione.... spero di trovarlo prima o poi :D
^TiGeRShArK^
08-02-2006, 22:38
forse ho trovato.....
sto guardando il metodo moveToCell della classe Gem....
^TiGeRShArK^
08-02-2006, 22:47
kakkio è vero! :doh:
mi ero dimenticato di passargli le nuove posizioni... :fiufiu:
provvedo subito :D
^TiGeRShArK^
08-02-2006, 23:04
nope...
mi pareva troppo bello... :sob:
ancora c'è lo stesso problema....
^TiGeRShArK^
08-02-2006, 23:06
ora mi ha creato una terza griglia sotto la prima! :eek:
^TiGeRShArK^
08-02-2006, 23:25
ma porka troia...
mi legge le variabili
private static final int GRID_P2_TOP = 32;
private static final int GRID_P2_LEFT = 524;
invertite! :eek:
ma com'è possibile??? :confused:
ho provato col debug e mi dice GRID_P2_TOP = 20 e GRID_P2_LEFT = 524 :eek:
mai vista una cosa del genere... :eek:
Guarda che basta usare due Factory Method diversi...uno per il primo controlelr e uno per il secondo...
^TiGeRShArK^
08-02-2006, 23:30
boh..giuro ke non ci capisco niente...come fa a cambiare il valori di variabile final e a ritrovarselo sbagliato???:confused:
il codice incriminato è il seguente:
private static GridController createWithGemGenerator(Config config, Input input, GemGenerator gemGenerator, boolean isPlayer1)
{
Grid grid;
if(isPlayer1)
{
grid = new Grid(
new Rectangle(
GRID_P1_LEFT,
GRID_P1_TOP,
WIDTH + GRID_P1_LEFT - 1,
HEIGTH + GRID_P1_TOP - 1),
config);
}
else
{
grid = new Grid(
new Rectangle(
GRID_P2_LEFT,
GRID_P2_TOP,
WIDTH + GRID_P2_LEFT - 1,
HEIGTH + GRID_P2_TOP - 1),
config);
}
InputReactor inputReactor = new InputReactor(
input,
config.getInteger("NormalRepeatDelay"),
config.getInteger("FastRepeatDelay"));
GridController controller = new GridController(
grid,
inputReactor,gemGenerator
);
controller.setDelay(config.getInteger("NewGemDelay"));
return controller;
}
ho controllato col debug per vedere se prendeva il ramo giusto dell'if ma mi da quel valore assurdo per uqelle costanti....:eek:
non ci capisco + niente...:sob:
^TiGeRShArK^
08-02-2006, 23:31
Guarda che basta usare due Factory Method diversi...uno per il primo controlelr e uno per il secondo...
si ok... ma ks xkè non funge???:fagiano:
Boh...
Io l'ho messo così:
public static GridController createFirst(Config config, Input input)
{
return createWithGemGenerator(config, input,
new GemQueue(config), new Rectangle(20, 32, 275, 479));
}
public static GridController createSecond(Config config, Input input)
{
return createWithGemGenerator(config, input,
new GemQueue(config), new Rectangle(524, 32, 779, 479));
}
^TiGeRShArK^
08-02-2006, 23:38
ah.. gli hai messo proprio i valori numerici nel metodo?
hai provato ad usare le costanti per vedere se ti da lo stesso problema mio???
Le costanti le ho proprio tolte perchè non venivano lette da nessuno... :fagiano:
^TiGeRShArK^
08-02-2006, 23:44
ah... pensavo fossero messe per una questione di leggibilità in modo da averle sempre sott'okkio in cima alla classe.....
^TiGeRShArK^
08-02-2006, 23:45
cmq ora lo faccio col factory method...
uso le costanti o metto direttamente i valori numerici????
Fai te... Comunque potrebbero bastare anche le costanti vecchie... Poi basta sfasare 304 pixel il primo e il terzo parametro del rectangle...
^TiGeRShArK^
08-02-2006, 23:57
fatto....però ancora le gemme sono solo nella prima griglia... ora vedo se capisco ke mi dimentico : muro:
^TiGeRShArK^
08-02-2006, 23:58
risolto...
oa vedo se passa il checkstyle e committo :D
^TiGeRShArK^
09-02-2006, 00:01
perfetto... green..
l'unico dubbio..
ho mantenuto il metodo creat di gridcontroller per compatibilità con i test...
ke faccio lo sostituisco con createFirst? forse sarebbe piu' logico...
anzi ... ora lo faccio :D
^TiGeRShArK^
09-02-2006, 00:07
ok perfetto...
Task 1 completato...
1 grazie a cionci per l'aiuto.....
e 1 maledizione a quel maledetto bug delle costanti sfasate ke mi ha fatto perdere la salute stasera :D
Spero di essermi perso qualcosa....altrimenti ti devo sgridare Tiger.
LA TEST LIST ??? :mad:
Spero di non aver rubato la frase a uno dei project manager :D
Spero di essermi perso qualcosa....altrimenti ti devo sgridare Tiger.
LA TEST LIST ??? :mad:
Spero di non aver rubato la frase a uno dei project manager :D
Non è stato introdotta nessuna nuova funzione quindi è gia tutto testato :p
Ora che siamo partiti mi aspetto di vedere tutti task completati fra due giorni. Quindi dateci sotto su che sono facili.
ciao ;)
^TiGeRShArK^
09-02-2006, 09:25
Non è stato introdotta nessuna nuova funzione quindi è gia tutto testato :p
Ora che siamo partiti mi aspetto di vedere tutti task completati fra due giorni. Quindi dateci sotto su che sono facili.
ciao ;)
infatti era un semplice refactoring ;)
vabbè.. semplice a parte il mio solito :ciapet: ke bekko le situazioni piu' inspiegabili... tipo quelle costanti ke cambiano valore da sole...:fagiano:
LA TEST LIST ??? :mad:
ops...che figuraccia !!! :ops:
^TiGeRShArK^
09-02-2006, 13:44
ma ancora nessun altro si è prenotato per gli altri task???:confused:
vabbè mi faccio anke il 2 stasera se riesco....tanto risulta ancora assegnato a me :sofico:
come al solito tempo stimato 2 giorni per rispettare la legge di murphy ma ottimisticamente dovrei finirlo stasera....
P.S. ... ma ke fine hanno fatto tutti i rapaci??? :fagiano:
P.S. ... ma ke fine hanno fatto tutti i rapaci??? :fagiano:
Si è aperta la stagione della caccia alle aquile. Si saranno rifugiati nei loro nidi :D
ciao ;)
Io mi metto ora a fare il 3...
Dovrei avere quasi finito...
Ma mi sono accorto di fare prima a controllare che il generatore casuale estragga la stessa sequenza di numeri invece di controllare la sequenza di gemme...
Inoltre è la classe Game che pensa ad inizializzare i due RandomGenerator con lo stesso seed...
cdimauro
09-02-2006, 16:42
Il task 4 lo prenoto io. Tempo previsto 2 giorni.
Task 10.1.3 completato...
I test sull'avvenuta duplicazione dei numeri casuali estratti sono in TestGemGenerator
Il task 4 lo prenoto io. Tempo previsto 2 giorni.
È tutto tuo. Bentornato cesare :)
ciao ;)
Non posso testare il gioco perchè la build machine sarà down (credo) fino a sabato, ma Ufo mi riferisce che non funzionano i game over.
Bene, riguardando bene i task, anche se non era specificato, direi che era parte del task 1 (ossia creare una griglia uguale alla principale). Cionci e Tiger, ce la fate a farlo voi?
Ok...ci penso io :) Comunque credo che ai fini del debug sia utile che una gliglia non si fermi al momento del gameOver dell'altra...
Ok...ci penso io :) Comunque credo che ai fini del debug sia utile che una gliglia non si fermi al momento del gameOver dell'altra...
No, ovviamente ognuna deve fermarsi solo al proprio game over, indipendentemente da quel che succede all'altra.
^TiGeRShArK^
09-02-2006, 20:18
ah.. quello non l'avevo messo io di proposito perchè x ora poteva dare game over anke quando non scendevano le altre gemme....o almeno è un ragoinamento ke avevo fatto ad okkio..
cmq è roba di un secondo....se vuoi cionci lo posso fare pure io tra 2 min... sempre se nn l'hai già fatto :D
No, ovviamente ognuna deve fermarsi solo al proprio game over, indipendentemente da quel che succede all'altra.
Ah...ok... allora mi sembrava di averlo già fatto...
Ah...volevi duplicare la scritta game over.... Ok...procedo :)
^TiGeRShArK^
09-02-2006, 20:27
dimmi quando finisci ks updato e parto col task :D
^TiGeRShArK^
09-02-2006, 20:44
ehm...avrei finito già... :sob:
faccio solo qualke verifica xkè mi scomparivano delle gemme casualmente la prima volta ke l'ho eseguito:eek:... ma poi le altre volte era tutto a posto...:confused:
^TiGeRShArK^
09-02-2006, 20:59
GREEN...Commit effettuato... task completato... ho trovato pure un buggettino ke posto nell'altro thread... ma non so se era già stato individuato....
Ottimo lavoro ^TiGeRShArK^.
ciao ;)
Tiger vabbè che sono task facili, ma... sei un mostro (come ovviamente anche Cionci)! :D
cdimauro
10-02-2006, 06:29
Ho appena fatto l'update per cominciare a guardare i sorgenti e a lavorare al task 4, ma come faccio di solito eseguo subito una build con Ant per vedere se è tutto ok.
Il risultato in allegato (ho provato a fare copia & incolla direttamente qui, ma all'invio del messaggio mi dice che ci sono troppe facine).
Nel frattempo riprendo confidenza col codice.
x VICIUS: grazie :)
cdimauro
10-02-2006, 06:51
OK, per finire il task mi basta passare un Rectangle a NextGemsPanel con le coordinate del box e usare quelle al posto dei valori hard coded che ci sono attualmente.
Però aspetto che la build sia di nuovo verde per mettere mano al codice del task.
Ho ancora qualche minuto prima di andare a lavoro: provo a dare un'occhiata al codice per vedere se riesco a capire cos'è che fa saltare quei test.
cdimauro
10-02-2006, 07:08
Falso allarme: non so per quale motivo, ma ant faceva riferimento a dei file di test inesistenti, per cui chiaramente falliva.
Buttando tutto il progetto e rieseguendo il CheckOut, la build è verde.
La mia solita sfiga. Fortuna che ho l'ADSL a casa (col 56K sarebbe stato un inferno).
Adesso vado a lavoro. Il task lo finisco stasera.
Scusate per lo spam. :muro:
Falso allarme: non so per quale motivo, ma ant faceva riferimento a dei file di test inesistenti, per cui chiaramente falliva.
Basta fare il clean della build quando succedono queste cose...
Non posso testare il gioco perchè la build machine sarà down (credo) fino a sabato, ma Ufo mi riferisce che non funzionano i game over.
Sabato se tutto va bene, altrimenti domenica. Sabato mi attaccano la DSL nella casa nuova.
Bear with me for a while.
Cionci...ma per clean intendi quello nel menù di SVN oppure il task ANT ???
Col task ant, se poi faccio i test non riesco più a far partire il gioco dal .bat perchè i file non sono più in bin, main debug o relase. :muro:
Cionci...ma per clean intendi quello nel menù di SVN oppure il task ANT ???
Col task ant, se poi faccio i test non riesco più a far partire il gioco dal .bat perchè i file non sono più in bin, main debug o relase. :muro:
Nel menu di eclipse "Projects" -> "Clean..."
ciao ;)
^TiGeRShArK^
10-02-2006, 14:15
Tiger vabbè che sono task facili, ma... sei un mostro (come ovviamente anche Cionci)! :D
non tanto...
ci ho pensato un pò stanotte quando ero a letto (non ridete... è sempre il momento in cui mi vengono le idee migliori :D) e mi sono venuti un paio di refactoring.. mi metto stasera a farli se riesco :p
(anke xkè non mi piaceva proprio il codice ke avevo fatto in quel modo :D)
^TiGeRShArK^
10-02-2006, 18:46
refactoring completato, build verde, commit effettuato ;)
^TiGeRShArK^
10-02-2006, 18:52
ehm.. una domandina...
ma a livello di giocabilità non è meglio utilizzare per il P1 le freccette + CANC, FINE, PAG e per il P2 W,A,S,D come tasti direzionali e 4,5,6 per le rotazioni???
meglio WASD e freccette imho :)
Urge un refactoring...mi sta qui sul collo... Domani ve ne parlo...
cdimauro
11-02-2006, 06:42
Completato task 4, build verde.
Non è stato introdotto alcune metodo, quindi non c'era bisogno di introdurre nuovi test.
Ho semplicemente aggiunto un parametro Point al costruttore di NextGemsPanel, che viene utilizzato per definire le coordinate del primo punto. Il secondo è definito dalle stesse coordinate, con l'ordinata aumentata di 32.
Si poteva fare diversamente.
Passare un Rectangle, ma un rettangolo mi dà l'idea di una superficie che racchiude uno spazio.
Oppure passare due Point, ognuno legato alla rispettiva gemma.
Io ho scelto la soluzione che ai miei occhi sembra più semplice e veloce per portare a termine il mio task. De gustibus. :D
x cionci e Vicius: grazie per i suggerimenti. ;)
secondo me un test serve...
Dato che in Diamonds non si modifica codice senza avere un test che fallisce basta un test con MockEngine che dimostri che è stato disegnato il pannello nella locazione giusta... A quel punto build rossa e vai con la modifica :p
Ma se il punto diverso viene passato in Game non si può testare...
Piuttosto, ecco la mia proposta di refactoring... Non è semplice perchè bisognerebbe portare molto del codice che è in Game in una classe esterna...e quindi completamente da creare e testare...
Secondo em è arrivata la necessità di creare una classe PlayerField o PlayField in cui si inizializzano e gestiscono tutte le componenti dell'area di gioco di un giocatore... Quindi la classe Game del gioco vedrebbe solo ed esclusivamente questa classe...
Che ne dite ?
cdimauro
11-02-2006, 10:31
secondo me un test serve...
Dato che in Diamonds non si modifica codice senza avere un test che fallisce basta un test con MockEngine che dimostri che è stato disegnato il pannello nella locazione giusta... A quel punto build rossa e vai con la modifica :p
Sì può anche fare, certamente, ma questo perché sarebbe necessario introdurre almeno un metodo per implementare la funzionalità desiderata. ;)
x cionci: mi sembra una buona idea.
Piuttosto, ecco la mia proposta di refactoring... Non è semplice perchè bisognerebbe portare molto del codice che è in Game in una classe esterna...e quindi completamente da creare e testare...
Secondo em è arrivata la necessità di creare una classe PlayerField o PlayField in cui si inizializzano e gestiscono tutte le componenti dell'area di gioco di un giocatore... Quindi la classe Game del gioco vedrebbe solo ed esclusivamente questa classe...
Che ne dite ?
direi fondamentale :)
Ragazzi...allora parto a farlo, ma la cosa sarà alquanto lunga... Intanto parto...ovviamente senza modificare il comportamento attuale e il test lo metto in ignore, così potete continuare dopo di me....
Piuttosto, ecco la mia proposta di refactoring... Non è semplice perchè bisognerebbe portare molto del codice che è in Game in una classe esterna...e quindi completamente da creare e testare...
Secondo em è arrivata la necessità di creare una classe PlayerField o PlayField in cui si inizializzano e gestiscono tutte le componenti dell'area di gioco di un giocatore... Quindi la classe Game del gioco vedrebbe solo ed esclusivamente questa classe...
Che ne dite ?
È un ottimo refactoring. Potremmo considerarlo parte del task 1 della seconda storia. Qualcuno vuol aiutare cionci in pair ?
ciao ;)
Presto aggiornerò la versione sul repository... Per ora ho fatto la gestione della reazione agli input e degli update (spostandoci anche i timeStamp)...
Ora bisogna spostarci l'inizializzazione (quindi l'aggiunta ai vari layer e la posizione delle varie componenti) ed il disegno su schermo...
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...
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?
Sfasate ? A me non mi sembra... Ora provo...a vedere meglio...
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
Possibile che nessuno voglia prendersi l'ultimo task ? :confused:
ciao ;)
Possibile che nessuno voglia prendersi l'ultimo task ? :confused:
ciao ;)
prendo io:)
tempo 2 giorni
come mai i test su PlayField sono su ignore?
Per il sync delle gemme non hai aggiunto un test?
Mi sono scordato di spostarlo :D
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...
prendo io:)
tempo 2 giorni
Perfetto.
ciao ;)
prendo io:)
tempo 2 giorni
Consiglio...giocati bene l'assegnazione dei tasti... Potrebbe essere ottimale farla nei factory method di playfield...
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...
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 :)
ho implemento in input iterable per usare l'iteratore.
Non si puo usare un foreach qui ?
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 ;)
IMHO anche duplicare la keyboard non sarebbe poi una brutta idea...comunque la seconda è una soluzione nettamente più bella :)
Non si puo usare un foreach qui ?
[\quote]
il foreache non mi da la remove(avevo iniziato con quello...)
[quote]
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ò :)
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.
thebol News? Siamo piuttosto in ritardo e pensare che i task erano piuttosto facili :(
ciao ;)
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 :)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.