[CICLO 2] Storia 2

[VICIUS]

La corpertura dei test ora è piuttosto buona quindi potete divertirvi a fare commit di tutti i task che volete.

ciao

[71104]

ma i test dei nuovi task...?

[VICIUS]

Originariamente inviato da 71104

ma i test dei nuovi task...?

Uhm ma non doveva pensarci fek?

ciao

[71104]

boh, chiediglielo...

[VICIUS]

Certo che è anche ora che incominciate a camminare con le vostre gambine. Su dai fatevi i test da soli se servono

ciao

[71104]

Originariamente inviato da VICIUS

Certo che è anche ora che incominciate a camminare con le vostre gambine. Su dai fatevi i test da soli se servono

ah no, stavolta aspetto che me li faccia lui, perché se fosse per me io riscriverei precisa com'era la classe PlayArea con il suo bel test che non testa quasi nulla (perché non c'era nulla da testare: è una classe che disegna soltanto...)
ergo onde evitare (mamma mia che latinista che sono ) un'altra cancellazione del mio codice...

[Vifani]

Scusatemi ragazzi, ma avrei bisogno di conoscere alcune informazioni per lo sviluppo del mio task.

La domanda è questa: la larghezza delle colonne è fissata? Lo spostamento laterale deve essere della stessa larghezze della colonne? Bisogna considerare un margine come bordo?

[VICIUS]

Originariamente inviato da Vifani

Scusatemi ragazzi, ma avrei bisogno di conoscere alcune informazioni per lo sviluppo del mio task.

La domanda è questa: la larghezza delle colonne è fissata?

Si per ora è della stessa larghezza di Gem. 32px.

Originariamente inviato da Vifani

Lo spostamento laterale deve essere della stessa larghezze della colonne?

Si.

Bisogna considerare un margine come bordo?

I bordi da considerare nelle collisioni sono in bound. Se non ricordo male il codice non dovresti essere costretto a modificare il codice delle collisioni.

ciao

[71104]

Originariamente inviato da Vifani

La domanda è questa: la larghezza delle colonne è fissata?

è fissata secondo una costante che potrebbe anche cambiare
credo che sia abbastanza corretto considerarla uguale alla larghezza della texture delle celle, che per ora è 32; per ora mettici 32, poi quando faccio il mio task sistemo un po' di cose.

Lo spostamento laterale deve essere della stessa larghezze della colonne?

io a direi il vero direi di fare uno spostamento molto veloce ma non del tutto istantaneo...

Bisogna considerare un margine come bordo?

chiaramente se il diamante va a cozzare contro l'extent (o il bound che dir si voglia) si deve fermare...

[Vifani]

Scusate ma se è così basta mettere un setSpeed(32,1) nel costruttore della Gem e questa si sposta di 32 pixel alla volta in orizzontale

[Jocchan]

Originariamente inviato da Vifani

Scusate ma se è così basta mettere un setSpeed(32,1) nel costruttore della Gem e questa si sposta di 32 pixel alla volta in orizzontale

Pur essendo piuttosto ignorante, posso dire la mia?
Eviterei un approccio del genere, dato che un semplice spostamento di una quantità costante di pixel, anche se coincide con la dimensione delle colonne, non ci garantisce al 100% che la gemma arrivi al posto giusto.
La sua posizione iniziale potrebbe non essere perfetta.
Ad un approccio del genere, inserirei una funzione di controllo che si assicuri del suo corretto posizionamento, magari valutando il numero della colonna in cui la gemma si trova e la coordinata orizzontale del suo hot spot, e corregga il tutto se il valore non è quello atteso.
In termini computazionali, dovrebbe avere complessità trascurabile (giusto un paio di calcoli), ma eliminerebbe ogni rischio di errore.
Poi magari è fatica inutile, ma ripeto che la programmazione non è il mio campo ^_^;;;;;;

[Vifani]

Originariamente inviato da Jocchan

Pur essendo piuttosto ignorante, posso dire la mia?
Eviterei un approccio del genere, dato che un semplice spostamento di una quantità costante di pixel, anche se coincide con la dimensione delle colonne, non ci garantisce al 100% che la gemma arrivi al posto giusto.
La sua posizione iniziale potrebbe non essere perfetta.
Ad un approccio del genere, inserirei una funzione di controllo che si assicuri del suo corretto posizionamento, magari valutando il numero della colonna in cui la gemma si trova e la coordinata orizzontale del suo hot spot, e corregga il tutto se il valore non è quello atteso.
In termini computazionali, dovrebbe avere complessità trascurabile (giusto un paio di calcoli), ma eliminerebbe ogni rischio di errore.
Poi magari è fatica inutile, ma ripeto che la programmazione non è il mio campo ^_^;;;;;;

Avevo pensato ad una cosa simile, ma devo attendere il parere di fek o vicius.

fek ogni volta mi dice di fare strettamente solo ciò che serve per completare il task nella maniera più semplice possibile.

[Jocchan]

Originariamente inviato da Vifani

Avevo pensato ad una cosa simile, ma devo attendere il parere di fek o vicius.

fek ogni volta mi dice di fare strettamente solo ciò che serve per completare il task nella maniera più semplice possibile.

C'è anche da dire che il task non è completo se c'è una percentuale (seppur piccola) di errore
Comunque fek e VICIUS sono sicuramente più affidabili di me, quindi meglio attendere loro

[71104]

caro Vifani, dico la mia: secondo me i Bounds del diamante non devono essere uguali a quelli dell'area di gioco, ma devono essere limitati alla colonna corrente in cui si trova il diamante; se l'utente preme la freccia sinistra o destra il bound deve essere esteso di una colonna a sinistra o a destra (sempre che non esca fuori dai bordi dell'area di gioco) e il diamante deve subire uno spostamento molto rapido nella direzione appropriata; deve continuare a muoversi finché le coordinate non subiscono il clipping orizzontale (e tra parentesi non sarebbe male come idea fare in modo che si possa determinare se uno Sprite ha subito un clipping durante l'ultima chiamata a move o setPos: in tal modo io potrei anche sviluppare un validissimo test per PlayArea... facciamo così?

[71104]

altra soluzione più semplice (ma in realtà preferisco quella che ho esposto di sopra): il Bound corrisponde *sempre* all'area della colonna corrente; quando l'utente preme sinistra o destra il Bound viene traslato esattamente com'è (sempre che non si esca fuori dall'area di gioco) in senso orizzontale verso la nuova colonna corrente; in tal modo non appena il diamante subisce il move verticale viene fatto il clipping (anche orizzontale) e si posiziona automaticamente al posto giusto.

[cisc]

secondo me le soluzioni di 71104 sono eccessive, io farei più una sorta di classe wrapper che "quantizzi" il movimento orizzontale del diamante e ne assicuri un movimento corretto..

[71104]

però fek stasera non si è fatto sentire e siamo bloccati (anche perché i miei task sono fondamentali per farvi procedere ^^')
per adesso farò come ho detto nel terzultimo post (prima soluzione) e casomai si riammazza PlayArea 1 altra volta.

[cisc]

Originariamente inviato da VICIUS

Non sono d'accordo. Per ora questa mi sembra la piu flessibile. Ci permette di scrivere codice senza dover scrivere le try/catch quando non ci servono (il 99% delle volte). Ad esempio è possibile accedere a config senza fare assurdi controlli oppure caricare una texture senza gestire ogni volta TextureNotFoundException. Se vogliamo gestirle in un punto particolare possiamo ancora farlo inserendo appunto try/catch. Se non vengono gestite arivano alla jvm che termina il programma stampando il messaggio.

ciao

rimango dell'idea che sia poco elegante, inoltre con i try catch si evidenziano meglio nel codice secondo me le parti più "sensibili", mentre adesso sono meno evidenti, certo, allo stato attuale del progetto può anche andare bene questa soluzione (anche se a me continua a non piacere), ma non è una gestione degli errori "robusta"

[VICIUS]

Originariamente inviato da Vifani

Avevo pensato ad una cosa simile, ma devo attendere il parere di fek o vicius.

fek ogni volta mi dice di fare strettamente solo ciò che serve per completare il task nella maniera più semplice possibile.

Se riesci a posizionare nella colonna centrale Gem poi benissimo modificare i valori delle velocità di default nella classe Gem. In questo modo non devi fare altro.
Per stare sul sicuro scrivi qualche test che mostri che l'ordinata del diamante meno l'ordinata del bordo sinistro è sempre un multiplo di 32 dopo la pressione di destra/sinistra e alla creazione.

ciao

[VICIUS]

Originariamente inviato da cisc

rimango dell'idea che sia poco elegante, inoltre con i try catch si evidenziano meglio nel codice secondo me le parti più "sensibili", mentre adesso sono meno evidenti, certo, allo stato attuale del progetto può anche andare bene questa soluzione (anche se a me continua a non piacere), ma non è una gestione degli errori "robusta"

I sorgenti di ora fanno esattamente quello che facevano prima (terminare il programma stampando un mesaggio ad ogni errore), ma con meno codice.

ciao