ArsLudica.org Forum
Cogitare => Officina Creandi => Topic aperto da: Cherno - Dicembre 29, 2008, 11:02:42
-
Approfittando delle ferie natalizie e quindi il tempo libero che ho, nonostante ora sia a lavoro :x , sto tirando su un giochino 2d, pertanto ho deciso di condividere con voi questo progettino. Il design non è completo, credo anche che mai lo sarà a dire il vero, quel che è certo è che il giocatore controllerà un demonietto in fuga durante la quale dovrà eliminare i suoi inseguitori.
La visuale è in sidescrolling, il nostro alter ego si troverà in una landa desolata nella quale potrà muoversi a destra e sinistra, saltare e sparare un raggio al fine di eliminare i suoi antagonisti. Per sparare basterà puntare con il mouse e cliccare nella posizione dove si intende direzionare il raggio distruttore.
Direzione artistica:
Lo sprite del personaggio l'ho creato io diverso tempo fa, era li che aspettava di essere utilizzato :D Avendo scarsa capacità artistica sia nel disegno, sia nel disegno digitale, ho fatto un lavoro minimale e con pochi frame di animazione: la corsa è composta da 4 frames, tanto per dire.
Ecco:
(http://img242.imageshack.us/img242/6291/30846770hl1.png)
Questo è il demonietto, fa molto megaman, lo so, in ogni caso ditegli ciao :D
Assodata quindi la mia poca competenza nella digital art, il gioco seguirà questo stile in pixel art molto essenziale. In rete cercherò dei tile-set e degli asset grafici per caratterizzare l'ambiente di gioco.
Realizzazione tecnica:
Sono pigro: non ho avuto nessunissima voglia di cercare motori 2d già fatti, installarli, configurarli ed imparare ad utilizzarli. Ho parecchio codice messo via scritto da me nel corso di vari anni, quindi ho dato una bella rispolverata al tutto, ho preso su Visual C++ ed ho organizzato il lavoro: il risultato ottenuto fra ieri e l'altro ieri è che attualmente il mio motore grafico poggia su directx9, è in grado di gestire sprite 2d sia animati che statici, può integrare elementi 3d.
Le strutture dati per far muovere il tutto ci sono, quello che ancora andrebbe fatto è rendere il motore grafico più indipendente in modo che disegni e basta, in maniera ottimale, senza che sia a conoscenza di cosa gli si stia dando in pasto(che sia uno sprite animato, non animato, ecc ecc). Insomma sto modularizzando, come è giusto che sia e come Monopoli insegna :D , tanto è vero che il motore sarà una dll a sè stante.
Per quanto riguarda l'input per ora ho gestisco la tastiera. Finiti i lavori sul motore grafico, passerò a sistemare l'input del mouse
Stato dei lavori:
Attualmente l'applicazione disegna un terreno in parallasse stile shadow of the beast ed il personaggio. E' possibile spostarsi in giro, ma l'ambiente è ancora spoglio e di avversari non ve ne è ancora l'ombra.
Nei prossimi giorni:
Come dicevo sto approfittando di questo periodo di vacanza per tirare su il motore, attualmente sta andando tutto bene ed in maniera fluida, tanto e vero che con relativamente poche ore di lavoro ho già una struttura decente e soprattutto un codice che mi permette di aggiungere features senza dannarmi troppo. Quello che mi prefiggo di fare da oggi al sette gennaio è quindi di terminare i lavori sul motore grafico e sul sistema di input, sistemare le strutture dati e creare un sistema di collisioni. Se riesco in questa impresa entro il termine impostomi (7 gennaio) anzitutto mi sentirò un figo, in seconda battuta potrei andare avanti e sviluppare di più il gameplay e creare un tool per la progettazione dei livelli.
A breve posterò un video, stay tuned :D
-
Realizzazione tecnica:
Sono pigro: non ho avuto nessunissima voglia di cercare motori 2d già fatti, installarli, configurarli ed imparare ad utilizzarli. Ho parecchio codice messo via scritto da me nel corso di vari anni, quindi ho dato una bella rispolverata al tutto, ho preso su Visual C++ ed ho organizzato il lavoro: il risultato ottenuto fra ieri e l'altro ieri è che attualmente il mio motore grafico poggia su directx9, è in grado di gestire sprite 2d sia animati che statici, può integrare elementi 3d.
Le strutture dati per far muovere il tutto ci sono, quello che ancora andrebbe fatto è rendere il motore grafico più indipendente in modo che disegni e basta, in maniera ottimale, senza che sia a conoscenza di cosa gli si stia dando in pasto(che sia uno sprite animato, non animato, ecc ecc). Insomma sto modularizzando, come è giusto che sia e come Monopoli insegna :D , tanto è vero che il motore sarà una dll a sè stante.
Interessante. Ma sinceramente secondo me sarebbe meglio una .lib di una DLL, che te ne fai del linking dinamico?
Nel senso: non ti accorcia i tempi di compilazione se cambi i .h, non ottimizza "whole program", non inlinea una mazza, gli accessi a funzioni e metodi sono piu' costosi perche' risolti a runtime, devi smazzarti la (piccola) bega degli entry point della DLL, potenzialmente hai la rogna delle variabili statiche e globali, e tutto questo per cosa?
Le DLL le han fatte per non avere su disco (e in memoria) codice "duplicato". Mi sta bene la DLL del CRT (e forse per un gioco neanche), tanto quasi tutto usa le DLL del CRT, per cui ce l'hai gia' in memoria con risparmio di ram (una miseria, cmq: il runtime del Visual 7.1 sono 300 KB, e se poi consideri che il linker scarta i pezzi che non gli servono, alla fine risparmi circa 80 KB di ram e di HD, cioe' molto poco), ma non so quanto davvero ti serva per un engine grafico.
Quanto al resto, in genere, amo le strutture "a tre strati": un primo strato "di sistema" (threading, gestione della memoria, I/O su disco, "libreria di cose che van sempre bene", tipo liste puntate, alberi e cose varie); un secondo strato "di engine" (con un engine per componente, per dire: engine grafico, engine audio, engine di input, eccetera), e un ultimo strato contenente le logiche di gioco che poggia sui due precedenti. Ciascuno dei componenti singoli e' legato solo ed esclusivamente ai componenti dello strato inferiore, ad eccezione dello strato piu' basso; e ciascuno dei componenti e' relegato entro una sola libreria completa (un .lib).
Cmq, se vuoi una mano con il refactoring dell'engine grafico o di qcosa d'altro, fai un fischio :D
Per quanto riguarda l'input per ora ho gestisco la tastiera. Finiti i lavori sul motore grafico, passerò a sistemare l'input del mouse
Fai attenzione. Aggiungere una feature "di basso livello" come l'input da mouse non e' affatto triviale come sembra una volta che tutto quello che sta "piu' in alto" e' "up and running", e spesso si risolve in una serie senza fine di smanazzi imbarazzanti.
-
Oramai ho fatto una dll, un pò anche per provarc:i è un argomento che affrontai in passato, ma ero ancora immaturo a livello di deisgn del codice. Non che ora sia un espertone, ma sicuramente ne so di più di prima. Quindi a livello formativo faro così :D La storia dell'inline non l'avevo considerata, quindi direi che a livello didattico sto centrando l'obbiettivo, ora so che inline e dll non cozzano :D
Per quel che riguarda l'input sono d'accordissimo con te, ma ho preferito lasciarlo dietro in quanto ho già "pezzi di codice" che gestiscono il tutto in maniera corretta. Visto che c'è qualcuno che ne sa, posterò anche lo schema delle classi :sisi:
Ti ringrazio infinitamente per i consigli :D
-
Ciao demonietto.
-
Oramai ho fatto una dll, un pò anche per provarc:i è un argomento che affrontai in passato, ma ero ancora immaturo a livello di deisgn del codice. Non che ora sia un espertone, ma sicuramente ne so di più di prima. Quindi a livello formativo faro così :D La storia dell'inline non l'avevo considerata, quindi direi che a livello didattico sto centrando l'obbiettivo, ora so che inline e dll non cozzano :D
Per la DLL, l' "esperimento didattico" e' davvero l'unica ragione sensata.
E d'altronde, l'inline (e altre ottimizzazioni, tipo l'omissione dello stack frame - come fai a omettere lo stack frame se non sai QUALE stack frame omettere? - e altre ancora) te le perdi per forza, perche' quando hai da un lato una DLL che deve saper stare su da sola, e dall'altro un eseguibile che non sa cosa chiama - perche' cmq il codice della DLL e' separato dal codice del chiamante - il compilatore non puo' ottimizzare la chiamata di funzione: deve preoccuparsi prima della "coerenza", cioe' considerare il fatto che chiunque potrebbe chiamare la dll e la dll stessa dovrebbe funzionare, inoltre l'eseguibile potrebbe chiamare qualsiasi versione della dll che esporti un certo simbolo, e poter funzionare.
Non e' tanto "inline e dll non cozzano" quanto piuttosto "dato che ogni pezzo di codice e' indipendente (il codice della dll deve star su da solo, quello del chiamante anche), il compilatore non puo' ottimizzare l'insieme dei due, ma puo' ottimizzare soltanto le due parti singolarmente".
Per quel che riguarda l'input sono d'accordissimo con te, ma ho preferito lasciarlo dietro in quanto ho già "pezzi di codice" che gestiscono il tutto in maniera corretta. Visto che c'è qualcuno che ne sa, posterò anche lo schema delle classi :sisi:
Ti ringrazio infinitamente per i consigli :D
Per l'input... va bene avere delle classi per gestirlo correttamente, ma e' piu' un problema di interfaccia fra chiamato e chiamante.
Nel senso: hai delle classi che lo gestiscono l'acquisizione dei dati, e hai delle classi che usano i dati acquisiti.
Sembra tutto banale, da li', ma devi vedere anche il formato in cui i due si scambiano i dati, e la quantita' dei dati che si aspettano - se la classe che usa i dati si aspetta un formato e quella che li acquisisce ne usa un altro, puoi doverti ritrovare a fare un cabaret di smanazzi per far andare tutto :D
Per i consigli, no problem :D
-
Perché non hai utilizzato XNA?
-
XNA l'avrò usato mezza volta, poi l'ho lasciato li per mancanza di tempo. Lo scopo del progetto è puramente didattico: vorrei mettere in campo le mie conoscenze programmative, rispolverare alcuni concetti, applicare un pò di software engineering e sviluppare un piccolo progetto, per tanto sto utilizzando librerie ed ambienti di sviluppo che già conosco. Sviluppare un giochino sarebbe solo una conseguenza di quello che sto facendo, tanto è vero che il design è dell'applicazione è: corri e spara. Tutto qua. All'inizio neanche volevo metterci il salto :D
Insomma sto studiando :D
-
Ah, bon.
Se ti interessa, io avrei un progettino per G4W ed eventualmente Community/XBLA (ho le licenze) di un platformuzzo free roaming, con grafica 2D (2D editato vettorialmente, è più semplice e manutenibile).
-
Dal 7 gennaio ti saprò dire se avrò tempo e quanto, ti farò sapere :sisi:
-
il demonietto mi piace.
-
Ah, bon.
Se ti interessa, io avrei un progettino per G4W ed eventualmente Community/XBLA (ho le licenze) di un platformuzzo free roaming, con grafica 2D (2D editato vettorialmente, è più semplice e manutenibile).
Potrebbe interessare anche me :D
-
Che sai fare, idduzzo?
Al momento sto partorendo un altro shmup vettoriale, facendo il porting del motore usato per la mia submission XBLA ad XNA che è infinitamente migliore per giochilli piccoli e veloci. Quasi porno.
-
Che sai fare, idduzzo?
Al momento sto partorendo un altro shmup vettoriale, facendo il porting del motore usato per la mia submission XBLA ad XNA che è infinitamente migliore per giochilli piccoli e veloci. Quasi porno.
Uhm, che so fare? Quando Monopoli era in Milestone, ero il suo capo.
A curriculum, ho 7 giochi commerciali pubblicati, di cui tre da lead programmer.
Vedi te =D
-
Che sai fare, idduzzo?
Al momento sto partorendo un altro shmup vettoriale, facendo il porting del motore usato per la mia submission XBLA ad XNA che è infinitamente migliore per giochilli piccoli e veloci. Quasi porno.
Uhm, che so fare? Quando Monopoli era in Milestone, ero il suo capo.
A curriculum, ho 7 giochi commerciali pubblicati, di cui tre da lead programmer.
Vedi te =D
AmoooVe! :-*
-
Che sai fare, idduzzo?
Al momento sto partorendo un altro shmup vettoriale, facendo il porting del motore usato per la mia submission XBLA ad XNA che è infinitamente migliore per giochilli piccoli e veloci. Quasi porno.
Uhm, che so fare? Quando Monopoli era in Milestone, ero il suo capo.
A curriculum, ho 7 giochi commerciali pubblicati, di cui tre da lead programmer.
Vedi te =D
LOL! Abbi pazienza, che ne sapevo!
-
Che sai fare, idduzzo?
Al momento sto partorendo un altro shmup vettoriale, facendo il porting del motore usato per la mia submission XBLA ad XNA che è infinitamente migliore per giochilli piccoli e veloci. Quasi porno.
Uhm, che so fare? Quando Monopoli era in Milestone, ero il suo capo.
A curriculum, ho 7 giochi commerciali pubblicati, di cui tre da lead programmer.
Vedi te =D
LOL! Abbi pazienza, che ne sapevo!
Ma infatti e' per quello che ho messo il faccino "=D" li' in fondo, mica me la sono presa, l'ho trovato divertente :D
Cmq, titoli altisonanti a parte, se la domanda e' "cosa so fare", in ufficio faccio un po' il jolly, nel senso - tipicamente rifinisco quello che c'e' da rifinire, per il resto fixo bug un po' dappertutto nel codice, engine a vario titolo inclusi, per cui "so fare" un po' tutto.
Se invece la domanda e' "cosa sai fare davvero bene" la risposta e' diversa: non ho le capacita' di scrivere engine grafici possenti come farebbe il Monopoli (per ora li aggiusto se serve, e basta :D ), ma ho esperienza solida con tutto il resto.
Cmq non si parlava di me nel thread, percio' propongo di chiudere qui l'OT, per il resto delle ciarle ci sono i PM e le serate birra/cazzate/giochi :D
-
Video killed the radio stars:
--Scherzavo devo ricaricarlo :asd:
-
Eccoci:
http://www.youtube.com/v/_eAmXAx5cpo&hl=it&fs=1"
Peccato che la qualità youtube lasci un pò a desiderare..
-
Che sai fare, idduzzo?
Al momento sto partorendo un altro shmup vettoriale, facendo il porting del motore usato per la mia submission XBLA ad XNA che è infinitamente migliore per giochilli piccoli e veloci. Quasi porno.
Uhm, che so fare? Quando Monopoli era in Milestone, ero il suo capo.
A curriculum, ho 7 giochi commerciali pubblicati, di cui tre da lead programmer.
Vedi te =D
Id è espertissimo in campi in cui io ho una conoscenza solamente scolastica o nulla :D
Ad esempio è espertissimo nel campo della gestione della memoria, sulle ottimizzazioni a basso livello, sulle strutture dati e in tutto quello che serve per fare un gioco.
Poi come me ha visto il codice più agghiacciante della Terra ed è riuscito a farlo funzionare, nonostante lui non volesse funzionare a tutti i costi :D
Matteo (Anelli), Id Spacca i megaculi e se vuoi fargli fare qualcosa stai tranquillo che quello che ti restituirà sarà probabilmente submittabile al primo colpo :D
-
Id è espertissimo in campi in cui io ho una conoscenza solamente scolastica o nulla :D
Ad esempio è espertissimo nel campo della gestione della memoria, sulle ottimizzazioni a basso livello, sulle strutture dati e in tutto quello che serve per fare un gioco.
Poi come me ha visto il codice più agghiacciante della Terra ed è riuscito a farlo funzionare, nonostante lui non volesse funzionare a tutti i costi :D
Matteo (Anelli), Id spacca i megaculi e se vuoi fargli fare qualcosa stai tranquillo che quello che ti restituirà sarà probabilmente submittabile al primo colpo :D
Giuro che non gli ho dato del denaro o offerto altre forme di pagamento, e' tutto spontaneo. ._.
Tornando in topic:
Eccoci:
(omissis sul video)
Peccato che la qualità youtube lasci un pò a desiderare..
Carino. Complimenti.
Anche se per certi versi sembra che il personaggio "pattini" - nel senso che ci sono frame in cui lui e' fermo, ma il terreno gli scorre spontaneamente sotto i piedi :D
-
Si si, questo perchè devo fare in modo che ogni frame venga temporizzato come si deve e soprattutto ci vorrebbe uno che a disegnare è buono :D
-
Informo che l'esperimento procede abbastanza bene:
non ho aggiunto feature a quel che già c'è, ma ho sistemato il codice. A breve la pubblicazione dello stesso :D
-
Informo che l'esperimento procede abbastanza bene:
non ho aggiunto feature a quel che già c'è, ma ho sistemato il codice. A breve la pubblicazione dello stesso :D
Saggia mossa. La fretta e' cattiva consigliera, e in ogni caso non si puo' costruire niente su fondamenta instabili, vale la pena rivederle periodicamente.
Detto cosi' sembra un'ovvieta', ma sorprende vedere quante volte il vero problema nello sviluppo di un gioco o di una applicazione complessa e' "correre troppo".
Aspettiamo con ansia (beh, io, almeno).
-
Piccolo update: oggi ho revisionato il codice, ho commentato le classi descrivendone il funzionamento ed ho implementato un sistema di parallasse, come si usava fare tanti anni fa su console e su amiga. Ecco uno screen:
(http://img201.imageshack.us/img201/1200/en2tg3.th.png) (http://img201.imageshack.us/my.php?image=en2tg3.png)
Dallo screen non si vede, però ci sono 10 livelli di parallasse. Niente di straordinario però in movimento fanno il loro lavoro :D
-
Bello lo sfondo, fa un po' Another World :sisi:
-
Si a livello artistico sto follemente prendendo ispirazioni fra another world e shadow of the beast :sisi:
-
Piccolo update: oggi ho revisionato il codice, ho commentato le classi descrivendone il funzionamento ed ho implementato un sistema di parallasse, come si usava fare tanti anni fa su console e su amiga. Ecco uno screen:
(http://img201.imageshack.us/img201/1200/en2tg3.th.png) (http://img201.imageshack.us/my.php?image=en2tg3.png)
Dallo screen non si vede, però ci sono 10 livelli di parallasse. Niente di straordinario però in movimento fanno il loro lavoro :D
Mi fa ridere pensare che oggi anche 100 livelli di parallasse sarebbero tecnicamente una bazzecola da far gestire all'hardware, mentre ai tempi si sarebbe gridato al miracolo diddio di fronte all'affermazione "10 livelli di parallasse" :D
-
he, è la stessa cosa che pensavo io. ora sto uscendo, però avrei da porti un quesito su coordinate di texture e pixel a schermo. :sisi:
-
Piccolo update: oggi ho revisionato il codice, ho commentato le classi descrivendone il funzionamento ed ho implementato un sistema di parallasse, come si usava fare tanti anni fa su console e su amiga. Ecco uno screen:
(http://img201.imageshack.us/img201/1200/en2tg3.th.png) (http://img201.imageshack.us/my.php?image=en2tg3.png)
Dallo screen non si vede, però ci sono 10 livelli di parallasse. Niente di straordinario però in movimento fanno il loro lavoro :D
Mi fa ridere pensare che oggi anche 100 livelli di parallasse sarebbero tecnicamente una bazzecola da far gestire all'hardware, mentre ai tempi si sarebbe gridato al miracolo diddio di fronte all'affermazione "10 livelli di parallasse" :D
Già proprio l'altro ieri ho parlato con un developer che sta per lanciare un editor open source molto potente per giochi 2D per XNA che ha un limite di 6 layer di paralasse mentre tutte le altre dimensioni sono customizzabili, memoria e piattaforma permettendo.
Al che gli ho domandato il perché potessi fare una mappa lunga 10 milioni di pixel e non profonda 500 layer.
-
he, è la stessa cosa che pensavo io. ora sto uscendo, però avrei da porti un quesito su coordinate di texture e pixel a schermo. :sisi:
Sei un po' criptico ma improssivo. Assumo che parliamo di posizionare sprite.
Se usi una risoluzione fissa di riferimento e setti la tua scala del viewport in maniera tale che ha tante X-unità ed Y-unità quanto la risoluzione fisica, hai una *buona* probabilità che le texture si mappino 1:1 rispetto ai pixel, a patto di disabilitare il filtering e di usare una proiezione ortogonale e non prospettica. Hai una *buona* possibilità perché a volte driver diversi producono approssimazioni diverse, con degli errori a volte piuttosto strani (approssimazione?). Se usi valori proporzionali (tipo: le coordinate del tuo viewport è 3x o 1/3 della risoluzione fisica), spesso le texture un po' sgranano se non usi il filtering (se la risoluzione è bassa, potresti perderti qualche colonna o riga e un po' potrebbe notarsi, specie sulle cose statiche come gli sfondi).
Di norma funziona, quasi tutte le GUI nei giochi usano varianti di questa tecnica per essere posizionate sullo schermo al posto giusto senza diventare matti.
Se invece vuoi posizionare Sprite in una scena completamente 3D con proiezione prospettica, fai prima ad utilizzare direttamente una billboard (un quad texturizzato che ha sempre la normale che punta verso la camera).
-
No non c'entra, non è un problema di sgranamento od altro solo che adesso sono un pò stanco per spiegare. Domani farò la mia richiesta in maniera più chiara :D
-
Adesso sono in condizioni di spiegare:
Ogni piano di parallasse che ho creato non è nient'altro che un rettangolo(2 triangoli quindi :D ) texturizzato. Per dare l'impressione di movimento traslo semplicemente le coordinate di texture ad una certa velocità. Il fatto è che non c'è corrispondenza pixel a schermo->coordinata di texture, quindi il problema è far muovere alla stessa velocità i miei sprite con il piano di parallasse al quale poggiano, dato che gli sprite li muovo in pixel, mentre il piano in coordinate di texture. Dovrei trovare la relazione fra i due, ma proprio non mi viene ed il risultato è che gli sprite che poggiano su un piano di parallasse, quando questo si muove, pattinano.
-
Puoi usare una striscia di quad con la stessa texture ripetuta invece che uno soltanto.
Per lo scrolling, manipoli il vertex buffer (o ridisegni i quad se usi direttamentre le primitive) che usi per disegnarli per fare in modo che nella direzione in cui il PG cammina, ci sia sempre un quad pronto offscreen. Credo ti basti una striscia con 3 quad, uno offscreen davanti e uno offscreen dietro (se lo scroll è bidirezionale). Non appena entra nella visuale uno dei quad che sono offscreen (diciamo, quando è per metà nella visuale e metà ancora fuori), mofichi gli indici dei vertici così che quello che è offscreen nella direzione opposta diventa il nuovo offscreen nella direzione in cui cammini.
In questo modo inoltre hai il vantaggio che puoi animare e creare sfondi compositi (con attori o entità che si muovono coerentemenre con le regole fisiche del tuo mondo) tramite l'additività del vettore velocità che usi per la traslazione della parallasse senza troppi problemi.
Pensa ad un nemico volante che si muova sullo sfondo del terzo layer ad una velocità X (che poi è la stessa che ha quando lo hai sul layer in cui si svolge l'azione di gioco). Se il vettore velocità che usi per la parallasse del terzo layer è Y, la sua velocità apparente sarà X + Y.
Si usano trucchetti simili anche quando nei simulatori spaziali vuoi dar l'impressione della velocità facendo vedere dei punti o delle point texture che si muovono verso la camera: prepari una matrice 3x3 di 27 cubi con il "rumore" che simula la velocità attorno alla camera e aggiorni gli indici man mano che la camera si muove. Poi disegni la scena.
In questo modo utilizzi la stessa unità di misura anche per lo sfondo ed eviti molti bug (in particolare sui chip integrati economici) che alcuni chipset o driver hanno sulla manipolazione delle texture coordinates. Mi sa che guadagni anche qualcosina prestazionalmente (modificare un vertex buffer dovrebbe costare meno di animare texture) ma non penso faccia una differenza significativa se non sui chipset più scarsi!
-
Come dice Matteo funziona, pero' anche l'idea dell'UVshift mica e' brutta. Non basta fare 1.f/PixelDelloSchermo per avere il numerello che equivale al pixel?
Mi ricordo che su PC c'e' qualcosa tipo lo shift di un pixel, che nelle skybox rompe le balle. Se vedi che c'e', compensa :D
-
Come dice Matteo funziona, pero' anche l'idea dell'UVshift mica e' brutta. Non basta fare 1.f/PixelDelloSchermo per avere il numerello che equivale al pixel?
Mi ricordo che su PC c'e' qualcosa tipo lo shift di un pixel, che nelle skybox rompe le balle. Se vedi che c'e', compensa :D
Eh, ma molto spesso c'è shifting anche nelle implementazioni dei driver (o magari sono errori di approssimazione per eccesso o difetto in alcuni calcoli? Boh) e quello nn c'è modo di leggerlo dai capbits.
Ne sanno qualcosa i tuoi colleghi di LOTRO cosa gli sta facendo penare NVIDIA con gli ultimi driver per Vista con le modifiche all'UV mapping sulle DX 10! :)
-
Si effettivamente la strada indicata da matteo era la prima che volevo percorrere, poi però mi son detto: "fanculo, i buffer write only sono fatti apposta per essere veloci" e quindi mi è venuta in mente l'idea dell'uv shifting. :sisi:
La storia dello shift del pixel non è il famoso 0.5f per la storia texel/pixel? :D
-
Come dice Matteo funziona, pero' anche l'idea dell'UVshift mica e' brutta. Non basta fare 1.f/PixelDelloSchermo per avere il numerello che equivale al pixel?
Mi ricordo che su PC c'e' qualcosa tipo lo shift di un pixel, che nelle skybox rompe le balle. Se vedi che c'e', compensa :D
Sono proprio un pollo :D ...e dire che la stessa cosa la faccio anche per animare gli sprite :D
-
In realtà nel tuo caso il fatidico pixel traslato che potresti incontrare nell'UV Mapping su PC non ti fa né caldo né freddo, perché se gli sfondi sono ciclici semplicemente partiranno traslati di 1px rispetto alle coordinate UV che usi, senza artefatti.
Ti rimane un problema solo se vuoi aggiungere qualcosa di più dinamico sui layer di sfondo ma fino a che devi scrollare un'immagine sono soluzioni pressoché equivalenti.
-
Piccolo update: oggi ho revisionato il codice, ho commentato le classi descrivendone il funzionamento ed ho implementato un sistema di parallasse, come si usava fare tanti anni fa su console e su amiga. Ecco uno screen:
(http://img201.imageshack.us/img201/1200/en2tg3.th.png) (http://img201.imageshack.us/my.php?image=en2tg3.png)
Dallo screen non si vede, però ci sono 10 livelli di parallasse. Niente di straordinario però in movimento fanno il loro lavoro :D
Mi fa ridere pensare che oggi anche 100 livelli di parallasse sarebbero tecnicamente una bazzecola da far gestire all'hardware, mentre ai tempi si sarebbe gridato al miracolo diddio di fronte all'affermazione "10 livelli di parallasse" :D
Già proprio l'altro ieri ho parlato con un developer che sta per lanciare un editor open source molto potente per giochi 2D per XNA che ha un limite di 6 layer di paralasse mentre tutte le altre dimensioni sono customizzabili, memoria e piattaforma permettendo.
Al che gli ho domandato il perché potessi fare una mappa lunga 10 milioni di pixel e non profonda 500 layer.
Perchè probabilmente ha fatto come me ora: ha hardcodato il layering. Io conto di parametrizzare il tutto a breve, forte anche del fatto che ho risolto il mio precedente problema pixel/coordinate uv :sisi: