[***dati incompleti: scheda gioco o num immagine mancante***][***dati incompleti: scheda gioco o num immagine mancante***]
Un esempio pratico(a sinistra con l'nFiniteFX attivato; a destra disattivato)
[*] Il nostro engine proprietario è basato sulla tecnologia OpenGL. Ecco un piccolo schema degli acronimi:
| OpenGL | DirectX 8 |
| Vertex Programs | Vertex Shaders |
| Texture Shaders + Register Combiners | Pixel Shaders |
Giovanni Caturano, alias Froyd, è attualmente lead programmer di DroneZ, il gioco in sviluppo presso la software house Zetha GameZ.
Con il lancio della GeForce 3 e delle DirectX 8, tutti stanno parlando dei Vertex Shaders; nelle OpenGL, sono chiamati Vertex Programs, ma sono esattamente la stessa cosa, per questo motivo userò i due come sinonimi[*].
La ragione è molto semplice: sono assolutamente fichi e le demo terrificanti!
I Vertex Programs danno a noi sviluppatori la possibilità di entrare dentro la pipeline dell'Hardware Transform & Lighting (T&L) e implementare a nostro piacere!
Alla Zetha non avremmo potuto usare l'hardware T&L nei precedenti chips GeFOrce o Radeon, perché il nostro modello di illuminazione con il bump mapping non corrispondeva al metodo standard con cui le GPU utilizzano per calcolare il T&L.
Questo non è un difetto in alcun prodotto; è solo il modo in cui stavano le cose. Il pensiero comune su differenti modelli di illuminazione, tecniche di skinning originali, superfici bumpy-shiny e tutte le altre pazze idee hanno ispirato nVidia a creare l'nFiniteFX engine della GeForce 3.
Ora, con i Vertex Programs (o Shader, come preferite), noi possiamo "insegnare" alla GPU a fare T&L in modo originale - questo è ottimo, ma non è tutto.
Un Vertex Program ci permette di prendere le informazioni di un vertex (la sua posizione, normale, colore, texture etc.) e elaborarle in qualsiasi modo.
E' un modo eccezionale di skinnare, pompare effetti, fare morphing, deformazioni e qualsiasi cosa può venire in mente ad uno sviluppatore da far eseguire all'hardware.
I Vertex Programs sono scritti in una sorta di linguaggio assembly che è molto simile al linguaggio macchina delle GPU (p.e. il motore nFiniteFX) e abbastanza diverso dal linguaggio macchina della CPU principale (p.e. Pentium o Athlon). Le istruzioni sono differenti, ma anche il flusso generale del programma è differente: con i Vertex Shaders, state programmando un altro chip! Se voi state eseguendo un Vertex Shader e non avete una GeForce 3 (o una qualsiasi scheda grafica nativa per le DirectX8 GPU), il linguaggio macchina GPU deve essere emulato dalla CPU principale (qui avviene sia in DirectX che in GL).
Come la maggior parte di noi ha sperimentato, facendo girare un emulatore qualsiasi (tipo un emulatore di coin up, un emulatore di PSX o Amiga) le performance si riducono rapidamente, per la semplice ragione che il processore Intel o AMD è molto lontano dall'emulata GPU e l'emulazione in se stessa prende molte risorse, solo perché i due chip sono così diversi. Se voi doveste scrivere lo stesso codice per la CPU, dovreste farlo differentemente, e sarebbe ovviamente più veloce della GPU emulata, per la stessa ragione per cui visualizzare un personaggio 3D con un codice Direct3D standard è molto più veloce che visualizzare lo stesso personaggio 3D in un emulatore di PSX!
Il problema sorse mentre codificando una modalità di Benchmark per DroneZ: nVidia stessa ci raccomandò di tenere la lealtà nel benchmarks. Come fare ciò? Se noi avessimo rilasciato una versione del benchmark che sfruttasse il motore eFiniteFX usando i programmi Vertex, senza nessun altra pipeline disponibile, sapevamo che, quando sarebbe girato su una GeForce 2, questo avrebbe sensibilmente rallentato il nostro software ottimizzato per il T&L, il quale usa l'hardware solo per la fase di rendering (non per il T&L). Questo non è perché l'emulazione di nVidia o Microsoft sono male: semplicemente perché è emulazione e non non può essere meglio di un codice ottimizzato e nativo.
Così abbiamo deciso di permettere all'utilizzatore di sfruttare il software con il T&L ottimizzato (e non solo l'emulazione) quando girava sulla macchina senza il motore nFiniteFX.
Inoltre, per ottenere una vera e leale comparazione, non potevamo giusto stampare i poligoni passati dall'OpenGL: infatti, nel software ottimizzato per il pipeline, tu passi molti meno poligoni di quanti ne passi attraverso il processo GPU con il completo T&L - hey questa è una delle principali differenze tra il fare le cose via software o via hardware. Così abbia lasciato un'abilità per stampare entrambi i totali poligoni T&L e il totale dei poligoni passati: nel caso della GeForce 3, i due numeri sono gli stessi, perché tutte le T&L sono via hardware, incluso il setup del bump mapping e tutto il resto.
Questo significa che, con il nostro benchmark, potete realmente comparare il vantaggio dell'avere un prodotto nFiniteFX-ottimizzato contro un software T&L- ottimizzato. Inoltre puoi stimare il peso dell'emulazione facendo girare su una GeForce 2, il software T&L e l'emulato T&L. La differenza nella performance è ciò che perdete durante l'emulazione.
La buona notizia per tutti i fortunati possessori della GeForce 3 è che tutto ciò è ancora meglio. Infatti puoi pensare che se hai, un processore a 1,6 GHz puoi avere la stessa velocità della GeForce 3, ma questo è solo una mezza verità dato che puoi avere lo stesso risultato in un benchmark, ma questo non è ciò che accade realmente. In un gioco, mentre il motore nFiniteFX sta facendo il suo lavoro, la CPU è libera di fare l'IA e i calcoli della fisica, per prendersi cura del gioco in rete e così via... pensaci!
E' tutto? No. Il motore nFiniteFX inoltre ha come caratteristica il texture shaders (or "Pixel Shaders", in Dx8), i quali non possono praticamente essere emulati completamente, via software, ma permettono per incredibile qualità una completa gamma di nuovi effetti speciali.
Per noi, le nuove tecnologie dovrebbero essere un vantaggio per la gente che può affrontare l'acquisto, ma non deve essere un ostacolo per quella che non può. Se avete un eccellente macchina, dovreste avere un eccellente qualità, se avete una buona macchina vi dovrebbe ancora piacere quello che vedete, e se la vostra macchina non è realmente l'ultimo modello uscito.. perché non divertirsi con il gameplay?
Questo è perché programmiamo DroneZ in un modo che possa sfruttare la maggior parte delle macchine, e che può girare ad un recente framerate su la maggior parte delle schede video: più giustamente invece che pompare più poligoni intorno, noi proviamo a lavorare per la qualità, e pensiamo che i risultati giustifichino i nostri sforzi.
