Grandi pulizie...

...più o meno.

Ho dedicato la giornata di oggi alla razionalizzazione dei sorgenti; abituato come sono a Java, preferisco mantenere la filosofia "un file per classe", così almeno sono in grado di capire subito cosa contiene un file sorgente, e dove andare in cerca della classe x dopo una settimana di ferie e non ricordandomi più nemmeno come mi chiamo.
E così abbiamo Galaxy.cpp, Map.cpp, Planet.cpp, System.cpp e via discorrendo.
Andava fatto un robusto refactoring (purtroppo a mano, VC++ non è ahimè Netbeans..) di alcuni metodi che stavano proprio nella classe sbagliata: la parte di codice che disegna la mappa è giusto che stia in Map.cpp, non in Galaxy.cpp, tanto per dirne una. E se non sto attento rischio di generare un "mostro" che poi difficilmente avrò il tempo e la voglia di riordinare.
Così ho colto l'occasione per togliere parti di codice ormai obsolete, dare una nomenclatura alle variabili un pò più sensata, e con l'occasione ho pure scoperto un pò di strutture che rimanevano allocate anche dopo il termine del programma, prontamente corrette.
Non che ora si respiri aria di pulito, ma cose tipo

D3DVECTOR Pos;
Pos.x = s.coords.lyX+s.coords.sectorX*10;
Pos.y = s.coords.lyY;
Pos.z = s.coords.lyZ+s.coords.sectorZ*10;

HR(pSprite->Begin(D3DXSPRITE_OBJECTSPACE|D3DXSPRITE_DONOTMODIFY_RENDERSTATE));

D3DXMatrixTranslation(&T,Pos.x,Pos.y,Pos.z);

A=R*S*T;

HR(pSprite->SetTransform(&A));

almeno hanno un briciolo di dignità rispetto al caos che regnava prima.

Quindi nessuna novità di rilievo per il week end, tranne forse la gestione finalmente funzionante del full screen, in aggiunta alla modalita' window. Per scoprire tra l'altro che a 1440x900 gira con gli stessi identici FPS di una finestrella 800x600, a dimostrazione che l'overhead è per ora tutto a carico della CPU, nello specifico nel rendering dei nomi delle stelle: ancora non ho capito come mai si porti via tutto sto tempo, e se vi sia una strada alternativa per farla andare più veloce.
Ogni vostro suggerimento è ben accetto!

Una curiosita': l'eseguibile per ora occupa la "bellezza" di 56 kbytes (!), che aggiunto al singolo kilobyte dello sprite e a 2kb di un semplice shader che uso, porta il tutto a circa 60kb. Siamo a un decimo della dimensione di Frontier per Amiga, il quale fu scritto comunque in assembly (di sua natura più compatto del C++) e su un processore a 16 bit.
Messo per ora da parte l'intenzione di rendere più sofisticata la gestione dei nomi, e l'ottimizzazione negli FPS, il prossimo passo che voglio compiere è la gestione del mouse: per ora col tasto destro si ruota la mappa, e con la tastiera si alza/abbassa la telecamera. Ora manca il vero scopo della mappa, ovvero la selezione col tasto sinistro della stella di destinazione.
Un click sul pallino, e si sceglie la stella verso la quale si vuole dirigersi. Sembra facile ma c'e' di mezzo il solito problema della conversione da coordinate bidimensionali, a tridimensionali.
Il mouse infatti lavora su un piano, il puntatore idem, mentre le stelle hanno una dimensione in più. Che succede quindi se, ad esempio, a causa della particolare prospettiva selezionata con la telecamera, vado a clickare su una stella che ne nasconde un'altra? Entrambe anno la stessa posizione sullo schermo, quando seleziono una con il mouse, in realta' quali delle due devo considerare?
Ne parliamo la prossima volta, buon week-end.