7 iulie
Dupa cateva momente paranormale, am reusit sa fac exportorul meu in Python sa mearga, facut tot intr-o singura zi (Python a fost principalul ajutor!)

Dupa ce cubul a mers cu succes, am stat ca pe jar cand am transferat ultimul test (numarul 13!! 13!!! ) : capul de maimuta din Blender (un fel de echivalent al teapot-ului clasic)

Din cate se vede, exportorul merge bine: ~900 de fete, si ~500 vertecsi, iar texturarea pare ok. (se vede mai bine pe cub, pe maimuta e cam ciudat, desigur, deoarece l-am texturat folosind un cilindru din perspectiva din fata ei)

In formatul XML, asta inseamna 135KB, vre-o 5 secunde dureaza sa-l exporteze pe un Celeron@466, si cam 3 secunde sa-l importeze pe un Celeron@1.6GHz )

De mentionat (pt mandriea mea ) este ca au fost numai bug-uri minore de genul a schimba ">" in ">=", nimic "mare", fara eroare de concept sau design!

Exportorul a fost EXTREM de usor de scris in Python! Cum m-am intors sa scriu sistemul de screen-shot in C++, mi sa si facut dor de Python!

Desigur, acesta e un format text, este si de asteptat! O sa se reduca drastic dimensiunile si timpii de incarcare atunci cand trec la formatul binar, dar n-o sa fac asta deocamdata, deoarece formatul insusi este cam nou-nascut, deci o sa fie modificat des, si doar ma chinui cu binarele aducandu-le la zi mereu. E mai bine XML asa o vreme.

Ah, desigur, nu puteau lipsii screenshoturile! Nu prea se intelege din lipsa iluminarii, a lipsei umbrelor, si pt ca textura e stearsa rau, dar acolo e un cap de maimuta, pe cuvant! In plus, am pus si un render wire-frame... Si cu ocazia asta, am scris si codul pt screenshoturi!




3 iulie
Linia incercuita e cea care mi-a facut viata amara... pt vre-o 4-5 zile.
Am uitat sa o includ, si sa dus totul de rapa... In rest, nici un alt bug de care stiu...


Noaptea 6 (27-28 iunie), o saptamana ramasa!
Am fost eu si mama sa dam examenu de conducere... eu nu aveam un document care sa arate clar unde locuiesc... Degeaba incerca mama sa-i explice tipului de la ghiseu: " I am your mother! " (in loc de MINE), si desi tipul nu a fost surprins de engleza oribila a doamnei care tot insista ca e maica'sa , nu sa induplecat, asa ca eu il dau maine.
Surprinzator pt cineva cu un asemenea nivel de engleza, mama a luat examenu din prima... deh, a avut pila un fiu angajat acolo!

Nu stiu de ce, dar azi am fost foarte obosit... seara asta se termina la 3:48 (dar macar am inceput-o pe la 6 dupamasa). De obicei stateam mai mult.

Oricum, in acest timp am imbunatatit (ca sa nu spun tocmai "reparat" ) designul resurselor. boost::shared_ptr a fost de mare ajutor...

O chestie care am implementat-o este, spre exemplu am terminat de jucat un nivel, si vreau sa joc altul. Acum pot chema spre exemplu 'TextureManager::releaseUnreferenced();' (sau asa ceva, sunt prea ametit sa-mi aduc aminte) si ma scapa intr-un mod convenabil de ce nu am nevoie. Resursa respectiva (fie textura ca in exemplu, fie oricare alta) nu mai pare ca este "disponibila" sa fie folosita din nou, iar atunci cand obiectele existente ce folosesc resursa sunt distruse, si respectiva resursa e distrusa automat cand nu mai e folosita de nimeni.

Desigur, am terminat si partea care creaza un model dintr-un fisier XML. Maine seara o sa incarc o cutie amarata acolo, si sa o tin pe ecran... nimic impresionant, dar e un inceput pentru restul jocului...

Ah, era sa uit, am facut asta seara si materialele, care sunt definite tot in fisiere XML, dar sunt destul de mici.

Uhhhhh... atatea de facut, si cam putin timp...

I'll be back!

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Noaptea 5 (26-27 iunie), 8 nopti ramase:
Ieri nu am apucat sa lucrez... dupa ce m-am intors acasa dupa 7 ore de vopsit... am dormit 14.. (prima zi de munca adevarata din viata mea... nu mai vreau... )

Asta seara am adaugat suport primitiv pt texturi (adica poti doar sa le incarci si sa le folosesti, in rest nu pot lua dimensiunile sau alte smecherii, dar ar trebui sa fie indeajuns deocamdata)

Am adaugat desigur si clasele pt mesh-uri, si acum lucrez la codul ce le incarca dintr-un fisier XML. (cele binare vin la sfarsit, diferenta e doar de viteza de incarcare...) Seara sa terminat la 4:40, dar nu am apucat sa termin tot la partea de incarcare... pe maine.

Dupa ce termin asta, o sa incerc sa incarc un model simplu, texturat, si sa-l rendez, o sa postez un screenshot...

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Noaptea 4 (24-25 iunie), 9 nopti ramase:
La FIX am apucat sa termin tot ce este legat de bufferi! Index buffer, vertex buffers, o clasa ajutatoare care grupeaza vertex buffer-i dupa stream-ul lor (pt hardware instancing), manager care le distruge/recreeaza cand device-ul se pierde si altele legate de bufferi.

Zic "la FIX" deoarece am terminat partea asta in 'numai' (o fi bine?) 3 ore, si apuc sa ma culc la 2 si ceva... Nu de alta, dar maine ma duc la 9 sa vopsesc tencuiala... Pierd o zi de development, dar primesc 100$..

Maine: format si parser pt mesh-uri Are cineva un tutorial cum sa scrii un exportor pt 3DS Max va rog?

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Noaptea 3, 10 nopti ramase: (23-24 iunie)
Noaptea asta a inceput in forta rau.. o, da!
Cand pornesc programul, imi inghite memorie ca o gaura neagra! Vre-o 50MB/s... pana nu mai poate aloca, si se prabuseste. Distractiv! Mi-a luat o ora si ceva sa-l repar.

Iar extrem de complicata "reparatie" a constat intr-o singura linie gresita, care facea orice resursa (cum ar fi un font), sa nu tina minte corect ca a fost incarcata deja, si la fiecare folosire a respectivei resurse, datele ei sunt re-create!

A fost mai degraba un typo, dar un typo foarte simpatic... ori neatentie, ori cealalta faza: cateodata, cand Windows face trashing (muta memoria multa) si e prea ocupat, nu ia unele comenzi, ba chiar le pierde de tot, cum ar fi... CTRL+C! (poate sa nu-ti ia CTRL+C, dar sa-ti execute CTRL+V ul..)
Mi sa mai intamplat... este foarte posibil sa fi copiat inainte "RS_UNLOADED", si dupa aceea "RS_LOADED", sa dau CTRL+V, si sa nu fi observat din graba ca nu am pus ce trebuia...

Si mai nasol a fost ca tocmai terminasem de scris input-ul, si problema nu aparea in versiunea anterioara... deci primul instinct a fost ca problema e la codul nou (input)

CEL mai nasol a fost debug-uirea. Cand aloci atata memorie, Windows muta paginile altor procese in swapfile (eu avand un groaznic laptop cu doar 512MB, nici pe departe suficienti pt development), iar cand in sfarsit reusesti sa omori procesul buclucas, trebuie sa astepti iar pana aduce Windows paginile vechi din swap in RAM... da' astepti frate nu alta!

De timp nu ma supar, dar ma oftic groaznic de altceva! Daca logam tot felul de evenimente, cum ar fi "Loading font 'foo'", vedeam din prima in log ca mi-l incarca de enspe mii de ori, si nu mai pierdeam nici timpul!... *grr* *grr*

Eh, se mai intampla...

Chestia asta ma pune pe ganduri totusi... eu in sub 5000 de linii am avut mici scapari pe ici pe colo, si una groaznica... Dar Windows, care are 25 de milioane de linii? Care sunt sansele ca un programator obosit sau neatent sa faca o astfel greseala greu de depistat? Nici nu-i de mirare ca e un ditamai update-ul de cate 8MB la Windows la fiecare 2 saptamani...

Inapoi la demo:
Am rezolvat problema, iar acum programul sta in limite normale de RAM folosit la rulare: 10MB (15MB in total dupa ce am adaugat FMOD, cu numarul maxim 4093 de canale, inutil de multe zic eu), nu fluctueaza, si asta compilat cu debug information.
Am adaugat sunetul, cu tot cu pozitionare 3D, dar nu si dinamic (adica sa se plimba prin spatiu) Nu e posibil inca, deoarece nu am "actori" sau orice fel de entitate inca dupa care sa se tina bietul sunet... dar nu'i bai

Per total... a fost o zi destul de groaznica, cu putine progrese, zic eu.
Daca as face o lista cu ce am de facut cel mai devreme, as scrie asa: bufferi (index+vertex) <-- imediat maine!, format pt mesh-uri (modele 3D), materiale (definite extern, ca fonturile si ce mai am eu la sunete: playlist-uri).

Ca veni vorba de materiale, nu am timp sa ma complic cu tot felul de artificii fixed pipeline, asa ca merg exclusiv pe shadere.
Pe undeva prin lista aia, o sa intre si cateva dependinte.
(Aproximativ) Dupa ce termin lista de mai sus, incerc sa construiesc niste gameplay (sa te plimbi printr-un nivel)
Asta presupune niste fizica, deci ceva timp in plus pt PhysX...
10 zile... hmmm..... cam putin? Incurajeaza Mr.Sinatra cel putin...

(seara asta sa terminat 'doar' la 4:34, pentru ca maine ma duc la un interviu)

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Inainte de noaptea a 3a (23 iunie):
In cursul zilei am "reparat" si pus cap la cap tot, si am un ceva, o fundatie daca vreti, pe care sa construiesc (scrie :-P) si eu ca tot omul, sa pot testa usor, etc.

(sa nu se holbeze nimeni la FPSul meu, pentru ca am o placa jaf, integrata, de laptop mai exact... stiu ca ar trebui sa scrie un numar cu 4 cifre acolo, dar inca sunt blocat cu un ATI x200m, iar singura placa mai proasta decat asta are o sigla S3 pe ea... cred ca si Intel-urile alea on-board sunt mai bune... ma rog, "minunea" asta suporta vertex&pixel shaders 2.0! Le suporta... si cam atat. )

Memory manager-ul sa dovedit destul de folositor, am avut 2-3 leak-uri... deh, ameteala cand scrii framework-ul de baza la inceput. Oricum, a fost usor de reparat cu ajutorul acestuia.

Ma gandeam pentru asta seara sa adaug ceva simplu, inainte sa trec maine la chestiile nasoale. Simplitatile sunt: input (keyboard si mouse), si sunet de baza (fara 3D inca, deoarece nu am niste entitati sarecele pe acolo, deci nu are logica...) Asa pot as pun niste muzica de fundal, click-uri be meniu..

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Noaptea 2, 11 nopti ramase: (22-23 iunie)
Okey, aseara am mai lucrat eu pe ici pe colo la cod, in principiu sa am o fereastra up, din cate imi aduc aminte imi trebuie un device D3D inainte sa creez bufferi. Am renuntat la FreeImage, nu am timp si de asta in doar 2 saptamani, in plus am vazut ca si ce returneaza functiile D3DX pt texturi, culmea tot textura obisnuita (nu stiu cum mi-a scapat), se comporta cam la fel ca suprafetele D3D, deci pot sa-i dau LockRect. E bine pentru mine. O sa-mi foloseasca pt HDR...

M-am uitat putin mai in detaliu si dupa BSP si Octree... pentru stilul de joc care il fac eu, geometria nivelului este intinsa, dar extrem de mica in numar de poligoane, insa nu-mi vine sa o rendez toata...

Iar daca o impart in orice fel astfel ca rezulta mai multe batch-uri, mai mult rau imi fac...

Ce m-am gandit eu, sa impart geometria nivelului pt rendat (cea pt coliziune e separata) in grupe, cu un singur vertex buffer care nu-l modific, si doar sa modific index bufferul, scriind in el doar grupele care vreau sa le rendez.

Nu stiu despre performanta cand vine vorba sa scriu in index buffer, dar acestea nu o sa se schimbe des... (sa zicem o data la 1000 de frame-uri? mai mult probabil) Oricum, din moment ce il scriu de la capat de fiecare data, pot foarte bine sa-l trec "dynamic" si "discardable", deci ar trebui sa fie ok.

Din punct de vedere fizic, Ageia PhysX se ocupa de toate, iar toata geometria fizica a nivelului sa fie incarcata permanent in PhysX. Avand in vedere ca animatiile de skelet o sa le fac in vertex shader (deci pe GPU), nu mai e alt "criminal" pe CPU, deci PhysX are drum liber si eu zic ca o sa se miste destul de fin... sper

Fereastra ar trebui sa fie ok acum, nu am verificat, dar isi incarca setarile dintr-un fisier XML. Noaptea asta a fost putin cam neclara...

Detalii mai exacte noaptea viitoare. E cam imbarligat codu acum. Am lucrat la RenderSystem, RenderWindow, si prea m-am complicat cu RenderQueue si RenderQueueListener.. le simplific azi.

Stia careva ca Frank Sinatra a fost prima celebritate care a promovat o consola de jocuri - Magnavox Odyssey? (care la randul ei cred ca a fost si prima consola de jocuri...)

Uite o pauza care nu am regretat ca mi-am luat-o... ce mai 4 minute!
http://www.trilulilu.ro/Liviug/27fdb06895e265
Updateul in sine vine maine de dimineata. Examenul l-am lasat pe luni sau marti... poti sa te duci sa-l dai cand ai chef, si nici limita de timp nu exista... daca vrei, stai toata ziua in dreptul bucatii de hartie

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Inainte de noaptea a 2a (22 iunie):
Am facut rost de un al 2lea calculator, un Celeron la 466, dar numai bun pentru chestiile marunte ale restului familiei... Trebuie insa sa impart conexiunea la internet, si cum nu am un router inca... o sa facem cu randu la cablu' Asa ca updateurile or sa vina putin mai tarziu (probabil in cursul zilei urmatoare, dupa fiecare noapte, cum o fi norocul...

PS: okey, okey, hai cu comenturile daca aveti ceva interesant de zis, dar daca sunt ridicole, nu o raspund absolut deloc la respectivul(a)

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Ce'am facut pana la demo-ul meu nu mi-a placut - prea imbarligat!!
Arunc TOT la gunoi si o iau de la capat, cu cat mai putine dependinte posibile. Lista mea este facuta din DirectX (3D si input), FMOD (sunet), RakNet (ghici) si PhysX. (ghici iar... daca ditamai enginu Unreal3 nu si-au facut fizica proprie, si vad si de ce, eu de naiba sa-mi fac?? In plus si ei au folosit tot PhysX, care este probabil cea mai buna librarie in domeniu...)
Ah, si boost pt shared_ptr... dar asta nu se pune... :-P

Noaptea 1, 12 nopti ramase: (21-22 iunie)
Creat proiectul in MSVC2005 Express, aranjat directoarele si copiat dependintele (headere si lib-uri), setat cateva chestii la proiect. Am inceput deja sa scriu la cod, dar cu un sentiment foarte ciudat, de parca sunt gata sa ma las de programare... tremur putin.
Am deja cateva chestii de baza... cam 7 headere si doua cpp-uri. Am ceva gen "StdHeaders.h", imi include toate chestiile obisnuite din std, mai am si un "Prerequisites.h" care imi pre-declara clasele, pentru a compila mai repede, si nu in cele din urma mi-am facut un memory manager... doamne, nu stiu cum am trait fara asa ceva pana acum...

Sentimentul ciudat nu dispare, defapt, parca am pielea prea rece, un sentiment oarecum sinucigas. Oarecum ironic, dar incep sa ma indoiesc ca o sa mai ies ceva in viata.

Totusi, continui sa scriu, desi e 3:43 dimineata, si mai rau, tocmai m-am uitat in oglinda. Ochii mei arata ca dracu'

Putin mai tarziu, am si logging, iar atunci cand arunci o eroare fatala [am un mic macro GAME_TERMINATE(str)], iti apare o fereastra, iti explica frumos sa vezi ce sa intamplat (daca rulezi in debug vezi si de la ce fisier, functie si linie a fost aruncata eroarea), dupa care chem un exit(-1) Evident, este vorbda despre C++ (nici nu stiu de ce am inclus amanuntul acesta??..)

In mare, am copiat sistemul de logging care l-am mai facut de enspe mii de ori, numai ca l-am facut thread-safe, si chestia cu fereastra. Cateva linii. Usor.

Moving on, tot nu ma simt mai "incurajat."

Am incercat sa dau un build sa vad daca totul e ok... Cateva probleme de linking, chestii de win api.

Schimb tipul proiectului la "WINDOWS", si cateva setari la "Linking", si ma scot. Merge. Eh, mai greseste si omu cand se apuca sa faca proiecte la ora asta. Dar bine ca merge.

Trec de cateva probleme in plus cu memory managerul, il testez, si -yay!- a mers! Este in mare dintr-un proiect mai vechi, dar adaptat pt secolul acesta...

Sa vedem... ce utilitati mai sunt de adaugat, sa pot incepe maine fara sa ma plictisesc cu detalii handicapate... (maine vreau sa fac sist. de fonturi, inainte sa fac bufferii si un queue de render operations). Ah, da! Un timer... indispensabil.

Un timer, alta chestie exasperanta care a mai fost facuta de milioane de ori... deja il stiu complet pe dinafara...

Printre alte maruntisuri, am mai adaugat si o clasa, "ColorValue". Motivul? operator [] si operatori aritmetici. Imi plac chestiile astea... (mai putin sa le scrii, foarte plicticoasa treaba)

Cam de ajuns pe noaptea asta. Pot spune ca, defapt, nu am scris cu adevarat o singura linie de cod... intr-un fel.

Maine seara intru in 2 chestii: fonturi, si rendarea lor pe ecran (foarte simplu cu D3DX), si bufferi hardware. Desi o chestie mai usoara ar fi sa fac texturi inainte de bufferi, sincer, nu ma atrage idea sa incarc texturi alan-dala cu D3DX, ci prefer sa creez un buffer in memorie si sa incarc acolo. (IDirect3DSurface9, desigur) Nici nu mai stiu daca pot sa incarc cu D3DX intr-un IDirect3DSurface9, sau daca trebuie sa folosesc 3rd party, si sa scriu in buffer direct.
E o librarie faina, FreeImage, pe care am vrut mereu sa o incerc, asa ca o sa profit de ocazie...

Noapte buna Romania... sunt sigur ca am facut numai bine nedormind juma de noapte cand maine am examen de conducere... =.=

PS: pentru a evita neplaceri inutile, imi fac acest blog readonly. Nu aveti decat sa trancaniti, eu n-o va raspund (decat in mod exceptional? probabil numai Rimio&Dark, daca trec si ei pe aici din intamplare.. )

Ce bine ca nu ai ramas in Romania sa dai examenul de conducere
kidding bro...deh mai Andi asa-i cand iti iei viata in piept, intr-o lume necunoscuta..e greu.
Oricum bafta la examen!

Mersi... am auzit ca aproape toata lumea il pica de 2-3 ori... Asta e examenul de "learner", doar teoretic. Dupa ce fac 50 de ore de practica (50$/ora dar poti scapa si cu doar cateva ore platite daca ai prieteni cu permis Full, care sa faca ei restul de ore pana la 50 cu tine...) + examen practic, imi iau "Provisional", si pot sa conduc singur. Dupa 2 ani, daca nu calc pe nimeni , primesc permisul "Full"... De abia astept sa-mi iau Provisional-u...

Insa tot traiesc cu impresia ca toti de aici sunt retardati mintal, fiindca aproape toate masinile au cutii automate (nici nu se mai fabrica multe cu manuala)

Ai tu ce ai cu cutia masinilor

Eu personal prefer automatele, sau daca se poate o combinatie intre secvential si automat. Pur si simplu e mai comod in inghesuiala din oras.

*** ghici.. ***

Lucky you! Il aveam chiar la bookmarks:

http://sparks.discreet.com/knowledgebase/techdocs/searchable/techdoc_exporter/EXPORTER_LAB.htm



Sper sa te ajute.

Scarpinare cu degetul mic de la piciorul sting in urechea dreapta. Asta inseamna un upload peste bus (latency mare) si ca strici paralelismul GPU-CPU (pe linga copierile inutile de memorie pe care le faci, care probabil nu se vad daca n-ai altceva CPU-hungry in joc). In plus, inseamna sa tii indecsii de 2 ori in memorie (odata tu, ca sa ai din ce sa copiezi, odata runtime-ul). De ce faci asa ceva in loc sa faci fiecare "grupa" un obiect separat? Diferenta ar fi mai multe draw call-uri, dar costul draw call-urilor este mai mic deci cel al index buffer-elor dinamice.

Mersi mult JIM, asta e ce cautam!

@Dark
Lol, iar ma apucat sa ma complic... nu stiu totusi, o sa le incerc pe amandoua, si posibil si alte smecherii, dar pt demo-ul initial o sa iau calea simpla (cum ai sugerat tu, rendez fiecare bucata in parte... cu acelasi vertex buffer...?) Pe mine ma sperie rau treaba cu batch-urile Am auzit ca 400 de batchuri la 60FPS pot satura complet un procesor la 1GHz... (sau 100FPS? nu mai stiu...)

http://developer.nvidia.com/docs/IO/8230/BatchBatchBatch.pdf

Daca vorbesti despre hardware instancing nu are sens sa-ti faci probleme despre Pentium3 la 1 GHz. Nu stiu citi oameni au GF6 sau X1800 pe un P3@1Ghz.

Problema se pune simplu: dupa ce determini ce triunghiuri ai de desenat, ar fi bine sa le desenezi in batch-uri de citeva sute (cit mai multe, cu atit mai bine), ca altfel GPU-ul sta degeaba. Asta nu inseamna sa acumulezi chestii in buffere dinamice. Inseamna sa nu ai obiecte cu 10 poligoane, cum ar fi floricele facute din billboard-uri sau pietricele cu 5 fete. Daca intr-un frame ai de pus 1 milion de poligoane pe ecran si batch size-ul e in medie de 500 de triunghiuri, ai 2000 de draw call-uri, ceea ce e destul de mult pentru un P4 la 3 GHz. Poti sa faci clustering, dar asta inseamna sa folosesti mai mult ram pentru geometrie. Poti folosi hardware instancing pe placile care-l suporta si daca nu ti se pare prea limitat. Poti folosi shader instancing ca sa suporti mai multe placi si sa ai mai multa flexibilitate, dar din nou iti creste memoria ocupata de geometrie (si o sa dai de alt fel de limitari si de teritoriu neexplorat prin drivere).

Pe de alta parte, poate nu-i cazul sa desenezi 1 milion de triunghiuri per frame daca target-ul tau hardware nu duce atit. Daca faci clustering pe "grupuri" cum ziceai mai sus, poate e cazul sa maresti grupurile, astfel incit sa iasa mai putine; culling mai prost, dar daca erai limitat de draw call-uri va merge mai bine. Poate e cazul sa faci niste culling mai destept, cum ar fi occlusion. Poate merita sa experimentezi cu occlusion queries, desi nu stiu sa le fi folosit cineva cu succes in practica. Poate ai nevoie de un PVS. Poate merge sa reduci view distance-ul fara sa afectezi negativ gameplay-ul. Poate merge sa nu desenezi obiectele de detaliu (pietricele, floricele) dupa o anumita distanta.

In cazul general, folosirea unui index buffer dinamic pentru a reduce numarul de draw call-uri te va duce din lac in put. Evident, asta fiind un proiect personal e chiar indicat sa incerci, pentru a vedea ce se intimpla. Nimic nu se compara cu experienta hands-on. Este totusi important sa tii minte ca rezultatele vor diferi in functie de ce face fiecare aplicatie cu CPU-ul (in afara de draw call-uri) si ca masuratorile sint destul de greu de facut si generalizat (mai ales daca ai 200 de FPS si vezi imbunatatiri de 10 FPS de la o metoda la alta, sau daca ai de desenat 20 de obiecte in total).

Cand ai un vertex buffer cu datele comune pt fiecare instanta (ex: UV, normala etc.), si inca unul care contine datele per instanta (contine matricea de transformare), asta parca e shader instancing? Eu am zis hardware instancing?

Aia cu 2 stream-uri cum zici tu se cheama hardware instancing. Oficial ai nevoie de Shader Model 3 pentru el, neoficial ATI au o extensie astfel incit merge pe toate placile lor de la 9500 in sus. Placile SM2 de la Nvidia nu suporta asa ceva, deci in tabara aia e nevoie de minim GeForce 6.

Shader instancing inseamna sa pui geometria de mai multe ori in vertex buffer si sa ai o componenta in vertecsi care reprezinta indexul instantei (cum ar fi w-ul din position sau din normala). Datele per-instanta stau in constantele pentru vertex shader, care le adreseaza folosind indexul ala din vertecsi.

Shader instancing are doua avantaje:

- merge si pe shader model 1.1 (desi e limitat tare acolo din cauza ca ai doar 96 de constante) si pe GF5, in caz ca ai nevoie sa suporti asa ceva.

- poti avea mai multe date per-instanta. La hardware instancing ai maxim 16 registri de input per obiect desenat si s-ar putea sa nu-ti ajunga sa bagi acolo pozitie, UV-uri, tangent frame, pozitia becurilor in object space, eventual parametri pentru lumini locale, o culoare de tinting, niste coeficienti de SH si ce-o mai dori shader-ul tau. La shader instancing te poti intinde mai mult, ca ai 256 de constante in care sa-ti faci de cap.

Dezavantajele la shader instancing:

- folosesti mai multa memorie pentru geometrie. Daca vrei sa ai maxim 4 instante per batch, ai de 4 ori mai mult ram pentru geometrie.

- numarul de instante per batch este limitat de cele 256 de constante disponibile (in afara de limitarea evidenta data de memorie). In practica probabil vei sta pe la 4-5 instante, dar oricum asta inseamna sa-ti reduci numarul de draw call-uri de 4-5 ori, ceea ce-i destul de bine.

- ultima data cind am incercat asa ceva cu multe date per-instanta, driverele de la Nvidia faceau ciorba din vertex shader si rezultau spike balls.

Vezi ca in SDK-ul de DirectX e un sample care-ti arata si shader si hardware instancing. Evident, fiind facut de MS nu foloseste extensia de la ATI pentru hardware instancing, astfel incit partea aia nu-ti va merge decit daca ai GF6 sau Radeon 11 (X1900, X1600 etc.).    Daca vrei sa vezi cum se procedeaza pe ATI, e un exemplu de instancing si in Radeon SDK. Pe scurt trebuie sa-i dai un FOURCC('I', 'N', 'S', 'T') prin D3DRS_POINTSIZE, hack-ul preferat al lui ATI pentru a expune extensii de DirectX (tot asa se fac R2VB si alpha to coverage).

Ce chestie nebuna...



Si MSVC 2005 SP1 nu-mi da decat un warning... asta la mine nu e decat un typo, in dreapta era defapt "pDest", si am rezolvat imediat, dar tot ma intreb ce ar fi iesit daca lasam asa...

De ce 13 nopti? Apoi o sai pe zile sau cum ?

Nu stiam Direct3D pana acum, si doar o boaba de OpenGL. Am folosit doar engine-uri high level. Uite ca mi sa pus pata , si m-am apucat sa vad ce pot face in 13 zile, cu 0 cunostinte Direct3D si WIN32... (avand in spate C++ si experienta in game engines, am facut cateva joculete mici, insa nimic concret de rendare)

Cum 2 saptamani sunt destul de putin sa inveti sa faci si sa faci un joc cat de cat modern de la (aproape) 0, adica sa invat Direct3D, shadere si putin WIN32, sigur nu e treaba de o pauza de cafea, nu? Deci niste nopti nebune rau de tot... sesiuni lungi de programare... ce as fuma o tigara acum...

Scopul este sa fac un demo, cat de cat jucabil, pana se termina timpul. Cine stie, poate imi iese isprava, nu ar fi prima data cand termin un proiect "la foc automat".. O sa vedem ce iese... Si chiar daca nu iese cum ma asteptam (de ex nu stiu sigur daca mai apuc sa bag si skeletal animation...), oricum nu arunc proiectul la gunoi (cum fac de obicei ) si-l pot termina ca pe un joc obisnuit, si lucrand ca un om obisnuit, sa am si io cu ce ma mandri pe gamedev.ro...

UMBRE - asta chiar n-am habar cum se fac...