[CICLO 2] Storia 1 - Pagina 3

^TiGeRShArK^ · 08-10-2005, 15:54

completato e committato anke il task 3.4...
ovviamente il test TestCollision però non passa perchè 71104 dovrebbe aggiungere nel codice del controllo delle collisioni il controllo in base all'Extent attuale... x il resto la build è verde (a parte qualke minor correction ke 71104 deve fare nel suo codice ke non passa le strette maglie del controllo sintattiko d fek

)

VICIUS · 08-10-2005, 16:05

Quote:

Originariamente inviato da ^TiGeRShArK^

[...] a parte qualke minor correction ke 71104 deve fare nel suo codice ke non passa le strette maglie del controllo sintattiko d fek

)

Ma come. Ha fatto un commit senza controlalre con ant check !!

ciao

cisc · 08-10-2005, 16:09

Quote:

Originariamente inviato da 71104

ragazzi, Config non è inutile in realtà perché Sprite, Texture e altre classi la usano per leggere le dimensioni del display, secondo me *non va* tolta, e anzi sapete una cosa? mi sa che la metto pure nel costruttore di Extents visto che le dimensioni del display mi servono per convertire le coordinate...

Config nel costruttore di Sprite l'abbiamo aggiunto io e DanieleC88 per conoscere le dimensioni dello schermo come parete di collisioni, in parole povere, se riduci lo spazio in cui il diamante può muoversi tramite Extents, Config non server più...

71104 · 08-10-2005, 16:12

Quote:

Originariamente inviato da cisc

Config nel costruttore di Sprite l'abbiamo aggiunto io e DanieleC88 per conoscere le dimensioni dello schermo come parete di collisioni, in parole povere, se riduci lo spazio in cui il diamante può muoversi tramite Extents, Config non server più...

perfetto, allora li tolgo tutti e poi faccio anche ant check (scusate, non sapevo manco che fosse ant

)

VICIUS · 08-10-2005, 16:24

C'è anche un test che fallisce. Si tratta di testCollisionBottom. Chi ha fatto un commit prima di controllare i test? Di chi è la colpa su dai che non vi faccio niente... io

ciao

71104 · 08-10-2005, 16:44

io ho controllato ed era tutto verde... ehm, Danilo...?

cmq il mio commit era la revision 232 se non erro.
comunque ragazzi lasciatevi dire che con le coordinate dell'asse Y avete fatto un discreto casino... O_O
dovrò cambiare un bel po' di cose...
intanto ditemi una cosa: qual è di preciso il significato dei membri widthCollision e heightCollision?

cisc · 08-10-2005, 16:53

Quote:

Originariamente inviato da 71104

io ho controllato ed era tutto verde... ehm, Danilo...?

ma chi è Danilo!!!

Quote:

cmq il mio commit era la revision 232 se non erro.
comunque ragazzi lasciatevi dire che con le coordinate dell'asse Y avete fatto un discreto casino... O_O
dovrò cambiare un bel po' di cose...

spiegati meglio, qual'è il casino di cui parli?

Quote:

intanto ditemi una cosa: qual è di preciso il significato dei membri widthCollision e heightCollision?

widthCollision e heightCollision sono le dimensioni dello Sprite che non variano con il pulsing e che quindi possono essere controllati nelle collisioni senza che venga introdotto il bug segnalato da cionci, al momento il codice in Sprite non va bene perchè le variabili in questione vengono aggiornate insieme a width e heigth, ma nelle mie modifiche di ieri avevo corretto questo problema, adesso le mie modifiche le ha Vicius

71104 · 08-10-2005, 16:59

Quote:

Originariamente inviato da cisc

ma chi è Danilo!!!

TigerShark

Quote:

spiegati meglio, qual'è il casino di cui parli?

a parte un errore trovato da Danilo (top e bottom scambiati), qui si fa molta confusione con l'orientamento dell'asse Y...

Quote:

widthCollision e heightCollision sono le dimensioni dello Sprite che non variano con il pulsing e che quindi possono essere controllati nelle collisioni senza che venga introdotto il bug segnalato da cionci, al momento il codice in Sprite non va bene perchè le variabili in questione vengono aggiornate insieme a width e heigth, ma nelle mie modifiche di ieri avevo corretto questo problema, adesso le mie modifiche le ha Vicius

capisco; cerco di aggiornare pure io; se necessario farò una mostruosa opera di merge :|

71104 · 08-10-2005, 17:18

GROAR MA CHI E' STATO a fare le funzioni per testare le collisioni con le pareti?!?!?!!?

sentite, visto che devo anche eliminare Config e le dimensioni del display, io qua tolgo tutte ste collisioni del cavolo, lascio solo le collisioni con l'Extent e riproduco il suono per quello inferiore... se poi ho fatto casino si torna indietro, amen.

^TiGeRShArK^ · 08-10-2005, 18:53

boh..
mel lo kiedevo pure io...
infatti le ho dovute correggere che top e bottom erano invertite perchè erano state fatte pensando che l'origine delle coordinate fosse in alto a sinistra...
comunque con le modifiche che ho fatto dovrebbero andare...
basta ke le modifichi per aggiungere il controllo da extent anzichè nei margini dello schermo..
penso ti convenga inserire getLimitX e getLimitY da Extent in modo da effettuare il confronto in base a questi valori...

71104 · 08-10-2005, 18:59

cmq sia vi prego di non committare nulla finché non ho sistemato un po' di cose, sto facendo un poderoso refactoring (tranquillo fek, lo faccio passo passo

non committo nulla finché non ho tutti i test verdi e il programma funzionante

)

71104 · 08-10-2005, 19:44

ragazzi, ho trovato un altro punto su cui si è fatta un po' di confusione: il significato della posizione di uno sprite; l'hot spot per così dire dello sprite va considerato il punto centrale, quello in alto a sinistra o quello in basso a sinistra? per ora io ho messo quello centrale (nella maggior parte del codice veniva interpretato così) ma se devo cambiare non c'è problema, devo modificare solo un paio di cose in Extent e Sprite.

EDIT: vorrei un'altra conferma per questo punto perché i test delle collisioni falliscono: devo correggerli ma prima voglio la conferma. VIIIIICIUUUUUSSSSS???

71104 · 08-10-2005, 20:24

non c'entra nulla coi problemi che ho adesso, ma propongo di spostare il metodo reactToInput in Gem; per ora è in Sprite e non mi sembra concettualmente corretto (non tutti gli sprites che useremo dovranno rispondere all'input dell'utente, senza contare che altri tipi diversi da Gem derivati da Sprite reagiranno in maniera diversa); ci metto un TODO?

VICIUS · 08-10-2005, 20:30

Quote:

Originariamente inviato da 71104

ragazzi, ho trovato un altro punto su cui si è fatta un po' di confusione: il significato della posizione di uno sprite; l'hot spot per così dire dello sprite va considerato il punto centrale, quello in alto a sinistra o quello in basso a sinistra? per ora io ho messo quello centrale (nella maggior parte del codice veniva interpretato così) ma se devo cambiare non c'è problema, devo modificare solo un paio di cose in Extent e Sprite.

EDIT: vorrei un'altra conferma per questo punto perché i test delle collisioni falliscono: devo correggerli ma prima voglio la conferma. VIIIIICIUUUUUSSSSS???

Nel resto del codice viene interpretato cosi per via del fatto che gli sprite sono disegnati con due triangoli. Questi sono, secondo me, quei tipi di dettagli sulla implementazione che è meglio nascondere. Quindi io preferirei in alto a destra, anche perché mi viene più naturale pensare con quel tipo di coordinate.

ciao

VICIUS · 08-10-2005, 20:31

Quote:

Originariamente inviato da 71104

non c'entra nulla coi problemi che ho adesso, ma propongo di spostare il metodo reactToInput in Gem; per ora è in Sprite e non mi sembra concettualmente corretto (non tutti gli sprites che useremo dovranno rispondere all'input dell'utente, senza contare che altri tipi diversi da Gem derivati da Sprite reagiranno in maniera diversa); ci metto un TODO?

Era un idea che era venuta pure a me. Per ora mettici un TODO. Una volta finiti i task ci mettiamo e li sistemiamo tutti prima di cominciare la prossima storia.

ciao

71104 · 08-10-2005, 23:19

Quote:

Originariamente inviato da VICIUS

Nel resto del codice viene interpretato cosi per via del fatto che gli sprite sono disegnati con due triangoli. Questi sono, secondo me, quei tipi di dettagli sulla implementazione che è meglio nascondere. Quindi io preferirei in alto a destra, anche perché mi viene più naturale pensare con quel tipo di coordinate.

in alto a destra?

non volevi dire forse sinistra?

comunque siccome l'asse delle Y è orientato verso l'alto in questo caso io l'hot spot lo metterei piuttosto in basso a sinistra; comunque per ora lascio al centro e attendo il parere di fek (potrebbe essere necessario modificare anche alcuni test delle collisioni oltre a Extent e Sprite).

VICIUS · 08-10-2005, 23:35

Quote:

Originariamente inviato da 71104

in alto a destra?

non volevi dire forse sinistra?

uh? ah! si a sinistra

ciao

71104 · 09-10-2005, 01:46

finalmente ce l'ho fatta: tra problemi nel codice da sistemare e antipatia naturale tra me e SVN stavo uscendo pazzo (intendo dire peggio di come sono :|)
cisc: abbiamo perso il tuo task (il 3.5)

l'errore è stato mio, ti prego di perdonarmi:

ho fatto casino sul mio pc col merge (lo ammetto!!!

); comunque volendo vedere il lato positivo delle cose:
1) 4 task su 5 sono completi e funzionanti (test completamente verdi)
2) nel programma sono state sistemate numerose incoerenze e un errore madornale (grazie TigerShark

)
3) l'unica una piccola incoerenza rimasta è completamente "sotto controllo" (a seconda del parere di fek possiamo aggiornare rapidamente il codice e renderlo perfetto)
4) il task 3.5 immagino che ce l'avrai ancora sul tuo pc, ma ad ogni modo penso che varrà la pena di rifarlo perché sono cambiati alcuni metodi in Sprite (ed è stato anche aggiunto un bel TODO che cambierà molte cose)

se vuoi il tuo task posso rifarlo io, visto che si è perso per causa mia, anche perché ho finito il mio con un giorno di anticipo quindi ho un altro giorno di tempo

detto questo dopo che sarà stato ripristinato il task 3.5 io mi proporrei per spostare reactToInput da Sprite a Gem

PS: spero di aver fatto tutto bene con SubVersion: dall'ultimo update di prova che ho fatto (senza errori) ho importato il progetto in Eclipse, i test erano tutti verdi e il programma funzionava; insomma non dovrei proprio aver rotto la build

comunque se ci sono problemi avvisatemi che sul mio pc ho ben due copie funzionanti dei sorgenti

DanieleC88 · 09-10-2005, 08:19

Quote:

Originariamente inviato da 71104

GROAR MA CHI E' STATO a fare le funzioni per testare le collisioni con le pareti?!?!?!!?

Parli di testCollision.java?

...sono stato io...

Cosa avevano di così tragico?

VICIUS · 09-10-2005, 11:48

Quote:

Originariamente inviato da 71104

4) il task 3.5 immagino che ce l'avrai ancora sul tuo pc, ma ad ogni modo penso che varrà la pena di rifarlo perché sono cambiati alcuni metodi in Sprite (ed è stato anche aggiunto un bel TODO che cambierà molte cose)

Il task di cisc ce l'ho pure io nei miei sorgenti in locale. Se non vedo nessun commit da parte di qualcuno per quel task lo metto su io questa sera.

ciao

08-10-2005, 15:54	#41
^TiGeRShArK^ Senior Member Iscritto dal: Jul 2002 Città: Reggio Calabria -> London Messaggi: 12112	completato e committato anke il task 3.4... ovviamente il test TestCollision però non passa perchè 71104 dovrebbe aggiungere nel codice del controllo delle collisioni il controllo in base all'Extent attuale... x il resto la build è verde (a parte qualke minor correction ke 71104 deve fare nel suo codice ke non passa le strette maglie del controllo sintattiko d fek ) __________________

08-10-2005, 18:53	#50
^TiGeRShArK^ Senior Member Iscritto dal: Jul 2002 Città: Reggio Calabria -> London Messaggi: 12112	boh.. mel lo kiedevo pure io... infatti le ho dovute correggere che top e bottom erano invertite perchè erano state fatte pensando che l'origine delle coordinate fosse in alto a sinistra... comunque con le modifiche che ho fatto dovrebbero andare... basta ke le modifichi per aggiungere il controllo da extent anzichè nei margini dello schermo.. penso ti convenga inserire getLimitX e getLimitY da Extent in modo da effettuare il confronto in base a questi valori... __________________

08-10-2005, 19:44	#52
71104 Bannato Iscritto dal: Feb 2005 Città: Roma Messaggi: 7029	ragazzi, ho trovato un altro punto su cui si è fatta un po' di confusione: il significato della posizione di uno sprite; l'hot spot per così dire dello sprite va considerato il punto centrale, quello in alto a sinistra o quello in basso a sinistra? per ora io ho messo quello centrale (nella maggior parte del codice veniva interpretato così) ma se devo cambiare non c'è problema, devo modificare solo un paio di cose in Extent e Sprite. EDIT: vorrei un'altra conferma per questo punto perché i test delle collisioni falliscono: devo correggerli ma prima voglio la conferma. VIIIIICIUUUUUSSSSS??? Ultima modifica di 71104 : 08-10-2005 alle 19:47.

09-10-2005, 01:46	#58
71104 Bannato Iscritto dal: Feb 2005 Città: Roma Messaggi: 7029	finalmente ce l'ho fatta: tra problemi nel codice da sistemare e antipatia naturale tra me e SVN stavo uscendo pazzo (intendo dire peggio di come sono :\|) cisc: abbiamo perso il tuo task (il 3.5) l'errore è stato mio, ti prego di perdonarmi: ho fatto casino sul mio pc col merge (lo ammetto!!! ); comunque volendo vedere il lato positivo delle cose: 1) 4 task su 5 sono completi e funzionanti (test completamente verdi) 2) nel programma sono state sistemate numerose incoerenze e un errore madornale (grazie TigerShark ) 3) l'unica una piccola incoerenza rimasta è completamente "sotto controllo" (a seconda del parere di fek possiamo aggiornare rapidamente il codice e renderlo perfetto) 4) il task 3.5 immagino che ce l'avrai ancora sul tuo pc, ma ad ogni modo penso che varrà la pena di rifarlo perché sono cambiati alcuni metodi in Sprite (ed è stato anche aggiunto un bel TODO che cambierà molte cose) se vuoi il tuo task posso rifarlo io, visto che si è perso per causa mia, anche perché ho finito il mio con un giorno di anticipo quindi ho un altro giorno di tempo detto questo dopo che sarà stato ripristinato il task 3.5 io mi proporrei per spostare reactToInput da Sprite a Gem PS: spero di aver fatto tutto bene con SubVersion: dall'ultimo update di prova che ho fatto (senza errori) ho importato il progetto in Eclipse, i test erano tutti verdi e il programma funzionava; insomma non dovrei proprio aver rotto la build comunque se ci sono problemi avvisatemi che sul mio pc ho ben due copie funzionanti dei sorgenti Ultima modifica di 71104 : 09-10-2005 alle 02:02.

08-10-2005, 16:24	#45
VICIUS Senior Member Iscritto dal: Oct 2001 Messaggi: 11471	C'è anche un test che fallisce. Si tratta di testCollisionBottom. Chi ha fatto un commit prima di controllare i test? Di chi è la colpa su dai che non vi faccio niente... io ciao

08-10-2005, 16:44	#46
71104 Bannato Iscritto dal: Feb 2005 Città: Roma Messaggi: 7029	io ho controllato ed era tutto verde... ehm, Danilo...? cmq il mio commit era la revision 232 se non erro. comunque ragazzi lasciatevi dire che con le coordinate dell'asse Y avete fatto un discreto casino... O_O dovrò cambiare un bel po' di cose... intanto ditemi una cosa: qual è di preciso il significato dei membri widthCollision e heightCollision?

08-10-2005, 17:18	#49
71104 Bannato Iscritto dal: Feb 2005 Città: Roma Messaggi: 7029	GROAR MA CHI E' STATO a fare le funzioni per testare le collisioni con le pareti?!?!?!!? sentite, visto che devo anche eliminare Config e le dimensioni del display, io qua tolgo tutte ste collisioni del cavolo, lascio solo le collisioni con l'Extent e riproduco il suono per quello inferiore... se poi ho fatto casino si torna indietro, amen.

08-10-2005, 18:59	#51
71104 Bannato Iscritto dal: Feb 2005 Città: Roma Messaggi: 7029	cmq sia vi prego di non committare nulla finché non ho sistemato un po' di cose, sto facendo un poderoso refactoring (tranquillo fek, lo faccio passo passo non committo nulla finché non ho tutti i test verdi e il programma funzionante )

08-10-2005, 20:24	#53
71104 Bannato Iscritto dal: Feb 2005 Città: Roma Messaggi: 7029	non c'entra nulla coi problemi che ho adesso, ma propongo di spostare il metodo reactToInput in Gem; per ora è in Sprite e non mi sembra concettualmente corretto (non tutti gli sprites che useremo dovranno rispondere all'input dell'utente, senza contare che altri tipi diversi da Gem derivati da Sprite reagiranno in maniera diversa); ci metto un TODO?

Strumenti
Mostra una versione stampabile Invia questa pagina per email