[CICLO 2] Storia 2

[VICIUS]

Originariamente inviato da 71104

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

Questa era una idea. Ma per ora abbiamo preferito non complicare troppo la stroia. Magari piu avanti aggiungeremo anche l'animazione per gli psostamenti laterali.

ciao

[VICIUS]

Originariamente inviato da 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.

Quella con bounds che trasla ?
Quello che secondo me ti conviene fare le segenti cose. Sempre che tu non ti diverta a vedere la tua classe gettata dalla rupe degli spartani da fek un'altra volta.

- creare una classe PlayAreaBackground in cui crei gli sprite, li posizioni e li disegni. Qui di test non dovrebbero essercene. La classe dovrebbe implementare Drawable. Si tratta di creare gli sprites e posizionarli nel costruttore e un foreach in draw.
- creare una classe PlayArea che al suo interno crea un istanza di Bounds e una di PlayareaBackground nel punto giusto dello schermo. Qui ci potrebbero essere molti cambiamenti in futuro ma per ora non ci interesa. L'unico metodo da tesatre sarebbe getBounds() per avere l'istanza di bounds creata da usare con i diamanti.

ciao

[71104]

Originariamente inviato da VICIUS

[...] Sempre che tu non ti diverta a vedere la tua classe gettata dalla rupe degli spartani da fek un'altra volta.

dimmi solo una cosa signor "asd": tu e fek preferite che io non lavori al progetto? perché è un po' che vi immagino così: (quello rosso sarei io e quello azzurro voi...)
percui se avete qualcosa da dirmi in proposito ditemelo apertamente: in caso cancellate pure la mia prenotazione a questi task senza che io continui a lavorare inutilmente...

- creare una classe PlayAreaBackground in cui crei gli sprite, li posizioni e li disegni. Qui di test non dovrebbero essercene. La classe dovrebbe implementare Drawable. Si tratta di creare gli sprites e posizionarli nel costruttore e un foreach in draw.
- creare una classe PlayArea che al suo interno crea un istanza di Bounds e una di PlayareaBackground nel punto giusto dello schermo. Qui ci potrebbero essere molti cambiamenti in futuro ma per ora non ci interesa. L'unico metodo da tesatre sarebbe getBounds() per avere l'istanza di bounds creata da usare con i diamanti.

non dovevi dirlo -.-'
ora sono praticamente costretto a fare come dici :-|
comunque non sta a me implementare il movimento orizzontale, istantaneo o rapido che sia; io avrei semplicemente creato PlayArea, che per ora disegna solo le celle; in più avrei messo quel famoso test che mi è venuto in mente.

[VICIUS]

Originariamente inviato da 71104

dimmi solo una cosa signor "asd": tu e fek preferite che io non lavori al progetto? perché è un po' che vi immagino così: (quello rosso sarei io e quello azzurro voi...)
percui se avete qualcosa da dirmi in proposito ditemelo apertamente: in caso cancellate pure la mia prenotazione a questi task senza che io continui a lavorare inutilmente...

personalmente non ho nulla contro di te. anzi ti ritengo piuttosto dotato come programamtore. secondo me ti manca solo un po di esperienza.
quella degli spartani era semplicemente un battuta. nulla piu. se ti ho offeso in qualche modo mi schuso.

Originariamente inviato da 71104

non dovevi dirlo -.-'
ora sono praticamente costretto a fare come dici :-|
comunque non sta a me implementare il movimento orizzontale, istantaneo o rapido che sia; io avrei semplicemente creato PlayArea, che per ora disegna solo le celle; in più avrei messo quel famoso test che mi è venuto in mente.

guarda che il mio era solo un consiglio su come procedere per separare playarea in due classi distinte e testarla. non voleva essere assolutamente un ordine. il motivo principale per cui fek a fatto il revert di playarea era appunto perchè mancavano i test e faceva due cose distinte.

ciao

[fek]

Originariamente inviato da 71104

boh, chiediglielo...

Oggi e domani sono in MS e senza un PC collegato.

[cdimauro]

Ho scritto il codice del test del mio task (TestLogo). Poi ho provveduto alla creazione della classe Logo che implementava quanto richiesto per far funzionare il test. Fin qui tutto ok. Poi ho provveduto a inserire nel codice di Game le (poche) istruzioni necessarie ad agganciare il logo all'area grafica. Qui sono sorti i problemi (da premettere che Ant mi dà l'OK e il test passa correttamente).

Ho eseguito il commit commentando, però, 3 righe in game.Java.

In createSprites:
//logo = new Logo(b1, b2);
fra la creazione delle playarea e del diamante.

sempre in createSprites:
//items.add(logo);
dopo l'add delle playarea.

In quit:
//logo.cleanup();
prima di tutti gli altri cleanup.

Questo per far continuare a funzionare correttamente Game esattamente com'era prima.

Il problema è che basta già decommentare la prima riga, quella della creazione / caricamento del Logo, per far bloccare il programma col seguente errore:

Exception in thread "main" org.lwjgl.opengl.OpenGLException: Invalid value (1281)
	at org.lwjgl.opengl.Util.checkGLError(Util.java:56)
	at org.lwjgl.opengl.Display.update(Display.java:567)
	at it.diamonds.engine.DisplayImpl.update(DisplayImpl.java:67)
	at it.diamonds.engine.Engine.updateDisplay(Engine.java:68)
	at it.diamonds.Game.update(Game.java:129)
	at it.diamonds.Game.main(Game.java:44)

Questo senza NEMMENO aver inserito l'oggetto in "items", e quindi farlo disegnare assieme agli altri. Infatti la creazione dell'oggetto va a buon fine, come pure tutto il resto del codice in createSprites: il fault si verifica all'atto di eseguire l'update, e quindi richiamando engine.updateDisplay().

Avete qualche idea su quale potrebbe essere il problema (ma sempre a me? )?

Un'altra cosa: potremmo finalmente deciderci ad utilizzare Config per memorizzare tutte le costanti e recuperarle soltanto da quest'oggetto? Così evitiamo di tenere costanti utili anche alle altre parti del codice o di doverle duplicare. Mi riferisco a quelle di cui è farcita createSprites (la dimensione dello schermo e delle playarea, ecc.) o altre parti del codice.

[cisc]

il problema è nella texture, infatti se provi a mettere

super(new Texture("diamond"), null);

al posto di

super(new Texture("logo"), null);

non crea nessun problema, adesso però bisogna capire cosa ha che non va logo..

[cdimauro]

Grazie per il suggerimento! Infatti così funziona perfettamente. Ho fatto il commit usando diamond.png al posto di logo.png, in attesa di informazioni in merito a quest'anomalia.

Un'altra cosa: avere due sistemi di riferimento diversi è seccante. Tra l'altro col riferimento attuale ci stiamo legando troppo a OpenGL.

Propongo di passare al sistema di riferimento ("classico") che ha come origine l'angolo in alto a sinistra, con l'asse delle Y che cresce verso il basso; allo stesso modo, per tutti gli oggetti (sprite, play area, ecc.) il riferimento dovrebbe essere l'angolo in alto a sinistra.
Secondo me tutto diventa più semplice da gestire.

[cisc]

ho l'impressione che il problema abbia a che fare con la dimensione dell'immagine, ma non ne sono sicuro e al momento non posso verificare meglio

[cdimauro]

Strano però se è veramente questo il problema. logo.png in effetti ha un'altezza dispari (129) e l'hot spot, con questo sistema di riferimento, mi torna la coordinata Y con .5 come decimale...

[VICIUS]

Ho appena fatto un update e mi trovo un po spaesato
Per trovare il codice di gem ho dovuto usare grep. Perchè gli è stato cambiato nome in GridSprite? Come nome mi sembra sbagliatissimo per due motivi. Non c'entra nulla con quello che fa la classe e oltretutto fornisce informazioni su come è implementata.

ciao

[71104]

l'ho rinominata GridSprite perché (come ho spiegato nel commit) rappresenta il particolare tipo di sprite gestito dalla classe Grid, che ancora non ho creato...
rispetto a Sprite, GridSprite aggiunge le seguenti caratteristiche:
- reagisce agli input della tastiera (c'è già)
- ha la "gravità" (c'è già)
- ha la capacità di "agganciarsi" ad una riga e ad una colonna specifica una volta che termina la sua caduta; a quel punto, una volta agganciata, qualsiasi chiamata a move ritorna false (e questa è da implementare)

poi casomai in futuro potremo anche differenziare i vari tipi di diamanti che cadono creando Gem, e tutte le altre per rubini, zaffiri, ecc., ma io consiglio piuttosto di usare la stessa classe passando in input al costruttore nomi di texture diverse.

[71104]

cdmauro, non capisco due cose:
- perché per disegnare il Logo hai fatto una classe apposta? Sprite andava già bene...
- perché nel costruttore di questa classe (praticamente vuota) hai preso in input due oggetti Bounds? non ho capito come mai li usi così...

[cdimauro]

Il mio task (5.8) era questo:

"disegnare il logo del task 5.7 in basso tra le due aree di gioco"

Quindi l'obiettivo era di disegnare un logo. E poteva andare benissimo uno sprite, ma avevo l'esigenza di vincolarlo alla condizione specificata subito dopo.

Per cui ho pensato di crearmi un'apposita classe, derivata da sprite, ma "specializzata" per questo compito; questo è il motivo per cui il costruttore di Logo prende come valori di input i due oggetti Bounds, ossia le due aree di di gioco. Mi sembra più leggibile così.

In effetti potevo anche creare un metodo createLogo(Bounds extents1, Bounds extents1) che tornava l'istanza di Sprite opportunatamente inizializzata.

Boh. Non so. M'è venuta così. Forse è la mania di specializzare le classi che mi ha portato a questo.

Al limite rifattorizzo tutto usando createLogo, se dite che è il caso.

Comunque nessuno ha ancora commentato sulle mie proposte relative a Config e al sistema di riferimento.

[71104]

per quanto riguarda il sistema di riferimento direi di usare quello con l'origine situato in basso a sinistra (non c'è motivo di fare inutili conversioni di coordinate quando passiamo il tutto a OpenGL), che poi è l'unico che usiamo a parte per i Bounds che prima o poi qualcuno si deciderà a convertire definitivamente (probabilmente io se non lo farà nessun altro ).
per quanto riguarda Config, direi che lo stiamo già facendo... guarda il thread Diamonds Knowledge: lì trovi definite quelle che per ora sono le costanti che deve contenere.

[VICIUS]

Originariamente inviato da 71104

l'ho rinominata GridSprite perché (come ho spiegato nel commit) rappresenta il particolare tipo di sprite gestito dalla classe Grid, che ancora non ho creato...
rispetto a Sprite, GridSprite aggiunge le seguenti caratteristiche:
- reagisce agli input della tastiera (c'è già)
- ha la "gravità" (c'è già)
- ha la capacità di "agganciarsi" ad una riga e ad una colonna specifica una volta che termina la sua caduta; a quel punto, una volta agganciata, qualsiasi chiamata a move ritorna false (e questa è da implementare)

poi casomai in futuro potremo anche differenziare i vari tipi di diamanti che cadono creando Gem, e tutte le altre per rubini, zaffiri, ecc., ma io consiglio piuttosto di usare la stessa classe passando in input al costruttore nomi di texture diverse.

Sei sicuro che fossero necessari tutti questi cambiamenti per disegnare una semplice griglia all'interno di Bounds?

ciao

[VICIUS]

Originariamente inviato da 71104

per quanto riguarda il sistema di riferimento direi di usare quello con l'origine situato in basso a sinistra (non c'è motivo di fare inutili conversioni di coordinate quando passiamo il tutto a OpenGL),

Secondo me ci convine fare come ha gia detto cdimauro. Siamo tutti abituati a pensare con l'origine degli assi e "hot-spot" in alto a sinistra e cambiare ora soltanto perchè opengl usa un sistema diverso mi sembra assurdo visto che abbiamo la possibilità di continuare a dusare il nostro modificando il codice di due o tre classi.

ciao

[Vifani]

Originariamente inviato da cdimauro

Strano però se è veramente questo il problema. logo.png in effetti ha un'altezza dispari (129) e l'hot spot, con questo sistema di riferimento, mi torna la coordinata Y con .5 come decimale...

Le texture devono avere dimensioni potenza di due. Ergo 129 non va bene. Se lo converti a 128 vedrai che funziona bene. L'unico modo per fare funzionare texture con coordinate dispari è usare un'apposita estensione che si chiama GL_EXT_NON_POWER_OF_TWO, che è di ultima generazione e non ancora supportata da alcuni processori grafici. Comunque non ne varrebbe la pena, meglio avere l'accortezza di usare dimensioni potenza di due e amen.

[71104]

Originariamente inviato da VICIUS

Secondo me ci convine fare come ha gia detto cdimauro. Siamo tutti abituati a pensare con l'origine degli assi e "hot-spot" in alto a sinistra e cambiare ora soltanto perchè opengl usa un sistema diverso mi sembra assurdo visto che abbiamo la possibilità di continuare a dusare il nostro modificando il codice di due o tre classi.

non sono due o tre classi, c'è da fare una marea di modifiche nel codice e i test potrebbero non aiutare in questo caso perché andrebbero modificati anche quelli... il programma potrebbe tornare a funzionare come prima, cioè per caso (o per miracolo che dir si voglia); non è meglio finire di convertire Bounds e tanti saluti? che importa come siamo abituati a pensare il riferimento cartesiano? e poi vorrei precisare che tu sei abituato a pensarlo con l'asse delle Y orientato verso il basso, ma in geomtria in genere non è così... verissimo che solitamente le client areas delle finestre di (penso) qualsiasi interfaccia grafica sono orientate verso il basso, ma se noi lavoriamo con uno strumento che funziona secondo la norma, inutile andare controcorrente.

[cdimauro]

Originariamente inviato da 71104

per quanto riguarda il sistema di riferimento direi di usare quello con l'origine situato in basso a sinistra (non c'è motivo di fare inutili conversioni di coordinate quando passiamo il tutto a OpenGL), che poi è l'unico che usiamo a parte per i Bounds che prima o poi qualcuno si deciderà a convertire definitivamente (probabilmente io se non lo farà nessun altro ).

Non sono d'accordo. Come ho già detto, ci stiamo vincolando troppo a una tecnologia, OpenGL, che è soltanto una soluzione di comodo che abbiamo trovato per il momento, visto che il progetto non è legato a niente. Potevamo usare anche SDL. Potevamo usare anche JOGL. Potevamo usare anche le SWING o le AWT, che almeno troviamo già nel pacchetto Java.

Il motivo per cui ho fatto sparire tutte le costanti (nelle parti in cui ho lavorato), vincolandole dentro i rispettivi moduli, è proprio quello di nascondere del tutto un dettaglio implementativo come questo.

Se domani volessimo effettuare il porting per dei telefonini, ad esempio, e ci ritroviamo con delle altre API che lavorano con un sistema di riferimento diverso, come facciamo?

Meglio lavorare con il sistema che a noi (programmatori. In particolare di giochi 2D ) viene più facile da usare, e che è quello che ho esposto.

per quanto riguarda Config, direi che lo stiamo già facendo... guarda il thread Diamonds Knowledge: lì trovi definite quelle che per ora sono le costanti che deve contenere.

Potresti aggiornarlo includendo tutte le altre costanti? PlayArea Width, Height, PlayPos1, PlayPos2, ecc. Al posto di Width e Height io metterei ScreenWidth e ScreenHeight, e comunque per le altre utilizziamo dei nomi più significativi.

Quando ci sono degli aggiornamenti, è meglio fare degli "up": così almeno capiamo che qualcosa è cambiato...