Am inceput devlog-ul la acest proiect ca poate asa ma tin de treaba. Folosesc C/C++ si DirectX9.
    Ideea principala a proiectului e sa invat cat mai multe chestii in timp ce ma apropii de un joc gen RTS. Proiectul se cheama sec G-Engine(aka nu are nume inca). G vine de la Gabi...

    Proiectul l-am inceput incercand sa rezolv doua probleme cu care ma chinuiam de ceva timp la celalalt "engine" pe care il scriam : LostDevice si Shadere. Aveam un program care recupera device-urile, dar era cu Flexible Vertex Format si unul care era cu Vertex Declarations si shadere, dar nu recupera device-urile. Intr-o noapte in care era sa renunt de vreo 5 ori, spre surpinderea mea, am reusit sa le combin.

    Mi-am dat seama ca am inteles mai bine decat ma asteptam felul in care functioneaza directx-ul. Dupa cateva zile mi-am dat seama ca am inteles mult mai prost decat ma asteptam C/C++. Mai exact inca nu inteleg exact cum fac include-urile fara sa imi dea erori gen "already defined". Am folosit si #pragma once si #ifdef-uri, tot nu merge cum vreau eu. Am schimbat extensia din cpp in c si a mers si asta m-a bagat in ceata si mai tare. Si mai multe probleme de genul asta, dar o sa pun intrebarile astea mai incolo, pentru ca am reusit sa trec peste intr-un fel sau altul. Am altele momentan

    Alta chestie de care mi-am dat seama e ca nu e chiar usor sa sparg proiectul in clase si sa ma folosesc de OOP asa cum trebuie. Parea mult mai simplu cand foloseam clasele doar pe post de structuri sau cand vedeam in carti cum clasa maimuta mosteneste clasa animal.

ScreenShot:
    
    
Download:
    http://rapidshare.com/files/419869302/GEngine.zip
    
Google code Project:
    http://code.google.com/p/g-engine-rts/
    
SVN:
    svn checkout http://g-engine-rts.googlecode.com/svn/trunk/ g-engine-rts-read-only

Probleme:

-Nu am reusit sa fac transparenta sa functioneze cum trebuie, se observa comportamentul ciudat in poza.
Verdele care nu trebuia sa se vada, vine de la :

"Bucatile" de foc sunt quad-uri, nu sunt PointSprites.
Dupa multe variante care nu au mers, am ajuns la varianta asta ( care evident nu merge ) :

-Se vad niste taieturi orizontale in foc, sper ca se rezolva de la sine dupa ce fac instancing si dupa ce rezolv cu transparenta


Ce poate face pana acum:

    -Terrain dintr-un heightmap tinut ca fisier txt
    -Ray Picking atat pe modele cat si pe teren
    -Se prinde de inaltimea la care trebuie sa se afle o unitate pe teren.
        ( miscati grunt-ul din arrow keys )
    -Un fel de particle engine, defect deocamdata
    -Multe alte chestii mici, mai putin complicate
    
    
ToDo:

    -Sa mai organizez putin codul
    -Sa rescriu particle engine-ul ca e gandit in graba
    -Sa fac instancing la particle engine
    -Sa fac selection box ca in jocurile de strategie
    (am implementat, dar nu l-am adaugat in proiect)
    -Sa il fac independent de viteza pc-ului pe care ruleaza. Adica sa inmultesc viteza * deltaTime

Salut,
M-am uitat peste proiect si pare foarte intersant. Nu ma pricep atat de bine la DX, dar c/c++ il stapanesc destul de bine. Legat de problema ta cu #include/#define/#pragma..am avut-o si eu si cel mai bun articol pentru asa ceva este

http://www.gamedev.net/reference/articles/article1798.asp


Sper ca te ajuta cu ceva si multa bafta cu proiectul tau

Despre proiect:

Nu mai baga chestiile generate de editor si de compilator in SVN. In fisierele ncb, suo si vcproj.user isi tine Visual Studio date pentru Intellisense si starea proiectului (ce geamuri ai deschise, configuratia activa etc.). Astea se modifica de fiecare data cind deschizi solutia si nu-s relevante pentru proiect. Cind o sa vrei sa lucrezi in mai multi (nu neaparat la proiectul asta), o sa ai probleme din cauza lor pentru ca se va intimpla urmatorul lucru:
- doi oameni fac checkout si incep sa lucreze
- primul da commit la ce-a lucrat, inclusiv ncb-ul si suo-ul asa cum le-a scris IDE-ul lui
- al doilea vrea sa dea si el commit la ce-a lucrat, fara legatura cu ce-a lucrat primul. Totusi, IDE-ul lui a schimbat si el chestii prin ncb si suo cum l-a dus capul, si acum fisierele alea sint diferite fata de base revision, dar si fata de ultimul commit. Cu alte cuvinte, ai un conflict si ala va fi obligat sa faca merge, ceea ce nu se poate ca fisierele sint binare.

Alta situatie mai putin tragica, dar tot nasoala, e cind cineva da update si primeste ncb-ul si suo-ul din ultimul commit, care n-a fost facut de el. Cum in suo ai bookmark-uri, breakpoint-uri, fisierele deschise si restul starii IDE-ului, omul ala, care probabil lucra la ceva, va deschide Visual Studio si va vedea ce fisiere, breakpoint-uri si bookmark-uri avea altcineva. Starea lui, pe care se baza ca sa poata relua chestia la care muncea, s-a dus.

Din fix aceleasi motive, tot ce se pune in directoarele Debug si Release (si altele, in caz ca-ti faci alte configuratii), nu are ce cauta in source control. Alea-s chestii care se genereaza cind dai F7, inclusiv exe-urile. In repository nu se baga chestii generate.

Vad ca ti-ai pus resursele in directorul Release si ca executabilul le cauta acolo. Cum faci debug la proiect? Muta toate texturile, shaderele si ce mai ai pe-acolo intr-un director separat numit "data" sau cum vrei tu si aflat in radacina proiectului, dupa care fa engine-ul sa le caute acolo.

Dupa ce iti muti asset-urile, sterge directoarele debug si release din source control. Dupa ce dai build din nou si reapar, baga-le in ignore list la SVN. Fa la fel si cu ncb-ul, suo-ul si .vcproj.user. Vezi sa nu scoti sln-ul si vcproj-ul, alea trebuie sa fie ca sint setarile proiectului in sine, nu ale IDE-ului.

Despre cod:

Articolul ala despre include-uri e bun, dar scrie pe undeva prin el ca in headere se pun define-uri, constante si alte chestii. Asta e adevarat cind constantele alea sint relevante pentru mai multe cpp-uri. Cind o constanta e locala, se pune in cpp, ca sa nu poluezi alte cpp-uri carora nu le pasa despre ea, si sa nu recompilezi aiurea jumate din proiect cind schimbi ceva (chiar daca nu trece de simtul estetic al lui nekitu). Ma leg de asta pentru ca am vazut la tine constanta FULLSCREEN, care e definita in Support.h, dar e folosita doar in main.cpp. Cind o schimbi se recompileaza tot proiectul degeaba. Daca o muti in main.cpp, o sa se recompileze doar un fisier cind umbli la ea.

Nu mai include un header intreg intr-un alt header cind vrei doar sa tii sau sa returnezi un pointer la o clasa. De exemplu in Entity.h folosesti pointeri la Model si incluzi Model.h pentru asta. Inlocuieste include-ul cu un forward declaration al lui Model (class Model; ) si include header-ul in entity.cpp, nu in h. In felul asta nu obligi toate cpp-urile care includ entity.h sa citeasca si model.h, scurtind timpul de compilare.

Nu mai include lib-uri cu #pragma comment. Vad ca il incluzi pe winmm.lib de vreo 3 ori, ceea ce duce la haos. Foloseste project settings -> linker -> input -> additional dependencies, ca d-aia e acolo.

Foloseste precompiled headers. Fa un fisier numit GEnginePCH.h in care muti toate include-urile alea cu angle brackets (windows.h, stdio.h d3d9.h etc.). Mergi la project settings, selecteaza "all configurations", dupa care C++ -> Precompiled Headers si zi-i ca use precompiled header cu GEnginePCH.h. Pune #include "GEnginePCH.h" la inceputul fiecarui fisier CPP din proiect si scapa de toate include-urile cu angle brackets de peste tot. Fa un fisier GEnginePCH.cpp in care incluzi doar GEnginePCH.h. Da click dreapta pe el, properties, C++ -> Precompiled Headers, schimba din "Use" in "Create Precompiled Header" (la fel, cu "all configurations" selectat).

Cu PCH si cu putina disciplina in cod, la mine pe calculator proiectul tau face un build complet in 3 secunde, iar un build dupa ce modifici ceva intr-un cpp dureaza sub o secunda. Proiectul asa cum il ai tu face un clean build in vreo 15 secunde si un build dupa ce schimbi un fisier in vreo 3-4. Diferentele astea vor deveni mult mai mari pe masura ce proiectul va creste si va fi din ce in ce mai frustrant sa astepti dupa compilator. Productivitatea scade spre 0 daca trebuie sa astepti 30 de secunde sa recompilezi proiectul dupa ce schimbi o linie, ca sa poti testa daca a mers.

Despre engine:


Verdele de la particule vine de la faptul ca pictezi sprite-urile inaintea cerului. In cazul ala, ele se vor blendui cu verdele pe care-l folosesti la clear si vor scrie in z buffer ca-s pe-acolo. Cind vii mai tirziu cu skybox-ul, el nu va aparea in pixelii aia ca va pica la depth test. Daca n-ar pica la depth test, oricum n-ar avea cum sa se blenduiasca cu particulele, ca alea s-au scris deja in framebuffer.

Daca vrei alpha blending, trebuie sa desenezi intii toata geometria opaca (inclusiv skybox-ul), dupa care sa sortezi particulele back to front, dupa care sa le pictezi in ordinea aia. Poti sa dezactivezi scrisul in depth buffer atunci, pentru ca oricum sortarea rezolva problema occlusion-ului.

Daca vrei alpha testing e mult mai simplu. Pixelii care pica la alpha test nu updateaza depth buffer-ul, deci se va vedea cerul prin ei chiar daca desenezi skybox-ul dupa particule. In treacat fie spus, e bine cum faci acum ca pictezi skybox-ul dupa toate celelalte obiecte, pentru ca beneficiezi de early z rejection pentru pixelii din el care-s acoperiti de alte obiecte, care in general sint foarte multi. Faza cu alpha blending-ul ramine totusi - daca vrei chesti cu alpha blending, le desenezi dupa tot restul geometriei si dupa skybox, ca altfel nu merge.

Vad ca tu dai enable si la alpha blend, si la alpha test. Alege una, nu se folosesc impreuna (sau ma rog, nu in cazul tau). Eu ti-as recomanda sa alegi alpha testing, ca e suficient pentru particulele alea. Uite cum arata cu alpha test. Ca sa si mearga, pune in D3DRS_ALPHAREF o valoare mai mare de 0. In poza la care am dat link e pus 127 si sint comentate liniile care umbla la D3DRS_ALPHABLENDENABLE, D3DRS_SRCBLEND si D3DRS_DESTBLEND.

Am vazut ca iti tii matricea de proiectie in c8-c11 si ca incarci constantele alea o singura data, cind (re)initializezi device-ul. Asta e o chestie destul de restrictiva si va duce la complicatii cind o sa ai un vertex shader care n-are nevoie de alea acolo, plus probleme de performanta pentru ca trebuie sa apelezi de mai multe ori SetVertexShaderConstantF() cind ai de setat chestii si prin c0-c7, si de la c12 incolo pentru acelasi shader. Nu e bine sa ai un state global d-asta. Mai bine pasezi matricea aia pentru fiecare shader care are nevoie de ea, in locul unde-i pasezi si celelalte constante. Poti aduna toate constantele pentru shader intr-o structura pe care o dai dintr-o singura miscare cu SetVertexShaderConstantF(). Mai mult, in cazul de fata vad ca n-ai nevoie sa-ti trimiti in shader separat matricile de world, view si projection. Poti sa le inmultesti linistit in CPU si sa trimiti o singura matrice la shader. E mult mai ieftin sa inmultesti 3 matrici in CPU o singura data per draw call, decit sa faci 3 inmultiri vector-matrice (adica 12 dot product-uri) in shader pentru fiecare vertex al fiecarui mesh.

Despre forum:

Din pacate ti-am facut spam aici cu mai multe mesaje pentru ca softul de forum crapa cind bagam tot mesajul si-mi arata doar o pagina goala dupa submit. Cred ca era din cauza ca pusesem semnele "mai mic" "mai mare" in loc sa scriu "angle brackets" acolo unde ziceam de PCH. Noroc ca scrisesem intr-un txt si am dat paste pe forum, ca daca scriam tot romanu' asta si-l pierdeam din cauza unui parser paranoic, ma duceam si mai dadeam odata voturi negative pe la competitii.

I mean, srsly guys.

@Stefan
    Mersi de link, o sa il citesc acum. Vad ca trateaza problema care ma deranja cel mai tare: dependenta ciclica intre doua headere.

@Dark
    Am observat si eu ca imi recompileaza tot proiectul pentru ca modific macro-ul FULLSCREEN. Acum imi dau seama ca are sens sa faca asta...
    Am vrut sa fac svn-ul sa imi ignore anumite fisiere, dar nu a functionat perfect. O sa citesc cum se face asta ca sa nu ma mai complic.
    Resursele le ia din folderul cu proiectul, le-am copiat eu in release ca sa mearga si la dublu-click.
    Forward declaration cred ca e exact ce cautam pentru dependenta ciclica( problema cu include guard-urile).
    Acum mi-am dat seama ca eu inmultesc matricele pentru fiecare vertex . Mi se parea mie ca prea trimit toti matricele deja inmultite la shader. Eu ma gandeam ca fiind column-major face mai usor calculele (scria pe undeva prin documentatia microsoft), desi imi era frica ca pierdeam avantajul asta pentru ca apelam de mai multe ori SetVertexShaderConstantF().
    La faza cu alpha blending-testing(nu faceam diferenta pana acum), citisem pe net ca trebuie sa randez front-to-back sau invers. Problema era ca Skybox-ul era si front si back in acelasi timp.


    Ca sa nu mai pierzi post-uri, e o extensie de chrome care tine minte ce scrii (inca tine minte post-ul de ieri in toate variantele lui), desi eu prefer sa scriu intai in txt.




Multumesc foarte mult ca ti-ai pierdut timpul uitandu-te prin proiectul meu si explicandu-mi multe chestii de care nu m-as fi prins singur pentru mult timp...

Ma apuc de treaba.

Daca folosesti Tortoise (ceea ce iti recomand), ai la click dreapta add to ignore list, si poti sa adaugi dupa extensie sau dupa tot numele.

SVN ignore este implementat foarte simplu: pentru fiecare chestie din proiect (fisier sau director) SVN tine o lista de proprietati care au un nume si o valoare de tip string. Proprietatile pot avea orice nume vrei (si le poti folosi in scopuri proprii in cazuri mai avansate), iar SVN isi defineste citeva care incep cu "svn:" si care au diverse semnificatii. Una din ele e svn:ignore, a carei valoare e o lista de pattern-uri separate cu enter, pe care clientul de SVN trebuie sa le ignore cind verifica ce s-a modificat.

Cind adaugi un fisier sau un pattern la lista de ignore, el e pur si simplu adaugat in proprietatea svn:ignore a directorului in care se afla. D-aia directorul iti va aparea drept modificat cind dai commit sau check for modifications. Poti sa vezi lista de proprietati si sa umbli la ele din Tortoise SVN -> Properties, sau din linia de comanda cu svn proplist/propget/propset/propedit. Nu e nici o smecherie cind intelegi ce si cum face de fapt.



Pai da, d-aia ziceam sa le pui intr-un director separat si ca cauti acolo, ca sa nu copiezi resurse prin 15 locuri.



Column-major vs. row-major n-are legatura cu asta. Din pacate (cum ii ziceam si lui meshoo acu' vreo 2 zile) Microsoft au decis sa foloseasca notatia gresita pentru vectori din cauza ca cineva a auzit ca e mai eficient sa faci calcule asa, idee provenita dintr-o confuzie antica si cauzatoare la rindul ei de multe confuzii ulterioare. In practica inmultirea in shader dintre un vector si o matrice 4x4 se face cu 4 instructiuni DP4. Ca sa mearga asta cu notatia din D3D, trebuie ca fiecare coloana sa fie intr-o constanta, d-aia auzi discutii despre column-major si vezi o multime de transpuneri de matrici inainte sa fie trimise la shader.

Oricum, chiar daca e optim in shader, n-o sa mearga mai bine sa faci ceva pentru fiecare vertex in loc de o singura data per draw call.



Cum adica skybox-ul e si back si front? Back to front inseamna sa sortezi obiectele semitransparente in ordinea descrescatoare a distantei fata de camera, si sa le desenezi asa. Asta se face din cauza ca operatia de alpha blending nu e comutativa, dupa cum se poate verifica foarte usor cu un pix. Skybox-ul trebuie pictat inainte de orice obiect transparent (ca si restul geometriei opace) pentru ca obiectele alea sa faca blend cu el, nu cu culoarea de clear. Nu se poate spune ca e "front" sau "back".



Mersi, o s-o instalez sa vad cum e.

    Cred ca am terminat de modificat cam tot ce mi-a spus Dark.

    Dupa ce am inmultit matricele pe cpu am ajuns de la vreo 30 fps la 35 fps. (Inca era focul ala cu alpha testing in scena).

    Am inteles cum functioneaza si alpha testing si alpha blending si am reusit sa le fac sa mearga pe amandoua. Tigrul ala galben semitransparent acum nu mai e verde cand are doar skybox-ul in spate. Cum a zis Dark, trebuia sa randez intai obiectele opace si dupa aia cele semitransparente in ordinea descrescatoare a distantei fata de camera. N-am nici cea mai mica idee cum fac ordonarea asta cand trebuie sa randez un model, dar nu e cazul inca sa ma complic.

    S-a vazut o diferenta enorma la timpul de compilare dupa ce am facut precompiled header.

    Am sters particle engine-ul vechi si am luat un engine din cartea "Special Effects Game Programming with DirectX". Era facut cu pointsprites, asa ca am incercat sa il fac eu fara pointsprites. Nu am reusit . (LATER EDIT3: aproximativ Solved. Detalii in postul urmator... )

    Adica in afara de faptul ca imi ia complet aiurea coordonatele de textura : http://img153.imageshack.us/img153/6978/screen2gc.png
, pare sa mearga :
http://img704.imageshack.us/img704/7669/screenot.png .
(LATER EDIT2: Cu FVF merge, deci probabil e de la shader)
Pot sa comentez liniile pVertices->tu = 1.0f; pVertices->tv = 1.0f; nu se intampla nimic. Am incercat sa vad cu PIX care e problema, dar vertex bufferul e trimis bine si la index buffer imi arata numai zero-uri si imi arata de doua ori mai putine valori , desi forma particulelor e buna(sunt patrate). Pe langa asta tu si tv se si modifica in timp ce particula se misca.(LATER EDIT: PIX vroia sa ii zic si tipul de date din buffer. float-ul are 4 si short-ul are 2, d-aia arata de 2 ori mai putine valori. Se pare ca si index bufferul e trimis bine...)
    


    Are instancing. Desi in cartea din care am luat codul, zicea ca pentru 10% din toate particule per draw call de obicei se obtine performanta cea mai buna, din testele mele de pana acum, pentru 100% se obtine performanta cea mai buna. Am vazut ca si in cartea de la Game Institute sunt prezentate niste teste unde se observa ca pentru foarte multe poligoane trimise doar cu un draw call performanta scade. O sa mai testez dupa ce imi iese si partea cu textura.
    
    Particle engine-ul e independent de viteza pc-ului(faza cu deltaTime).

    
    Engine-ul asta are mai multe optiuni decat cel vechi : gravitatie, dimensiune etc. E mult mai configurabil.

    TODO la engine:
        Culoare - sigur o sa arate interesant cand o sa dau culoare random pentru fiecare particula.(asta o sa necesite un nou VertexDeclaration si un nou Shader)
        Trebuie sa ii mai fac si billboarding cred.

    TODO in rest:
        Sa organizez cumva elementele din joc astfel incat sa le incarc direct din fisier.
        
        
        

Am reusit oarecum sa fac Particle Engine-ul(cred ca am zis de 100 de ori "Particle Engine"... ) sa mearga. Am ales sa las pentru moment alpha blending ca arata mai spectaculos, dar loveste FPS-ul destul de urat. Cel mai probabil o sa pun un parametru care sa decida daca se va face blending sau testing. :
http://img227.imageshack.us/img227/7350/screen3d.png

Nici nu imi dau seama exact ce am modificat de l-am facut sa mearga, dar problema cea mai clara e ca asa merge :



Daca comentez linia     tiger1->getModel()->Render( d3ddev ); Particle engine-ul randeaza foarte ciudat.

http://img843.imageshack.us/img843/331/screen4lq.png

Pateam ceva asemanator si la focul din prima versiune, acum imi amintesc ca asta ma oprise sa il pun sa fie randat ultimul si sa faca blending calumea.

Functia render e definita asa :

Singurul lucru dubios in codul pe care l-ai postat e apelul catre SetMaterial(). Ala e fixed function, n-are ce cauta intr-un cod care foloseste shadere. Totusi, apelul e doar inutil, n-are cum sa cauzeze ce vezi tu in poza.

Pune codul shaderelor pe care le folosesti pentru particule. Manipulezi in vreun fel coordonatele de textura de pe sprite-uri (scrolling, rotatie, ceva)? Banuiala mea e ca ramin niste constante setate pentru pictat tigrul in unele sloturi in care sprite-urile doresc sa fie parametrii pentru modificat UV-urile.

Apropo de pictat modele cu alpha blending, solutia corecta este sa sortezi triunghiurile (index buffer-ul) de fiecare data cind se schimba pozitia camerei, dar evident nimeni nu face asa ceva pentru ca e mult prea costisitor. Exista niste alternative gen depth peeling, dar tot incete sint. In practica te bazezi pe faptul ca backface culling-ul te va scapa de majoritatea triunghiurilor care se suprapun. Pentru un obiect convex te va scapa de toate, deci nu vei avea probleme de ordonare; pentru unul concav pot aparea artefacte, dar lumea le ignora. ATI fac o biblioteca numita Tootle care optimizeaza ordinea triunghiurilor in index buffer pentru a minimiza overdraw-ul, ceea ce ajuta si la minimizarea (dar nu eliminarea) problemelor aparute la alpha blending.

LE: pardon, m-am uitat acum din nou peste ce face Tootle si e invers fata de cum am crezut, optimizarea lor produce mai multe artefacte de alpha blending, nu mai putine.

Primele 2 shadere sunt versiunea 2.0






Se intampla la fel si daca folosesc :



Si totusi eu comentez doar linia care face render, nu liniile care au legatura cu shader-ul. Modifica directx-ul ceva din shader prin functiile alea ? Sau vede ca nu randez nimic si optimizeaza ?

Nu-mi dau seama ce are, pune codul daca poti si o sa dau un ochi.

Shaderii is ok, poti sa postezi te rog metoda care deseneaza particulele? Ca doar aia mai lipseste ca sa ne dam seama,ca banuiesc ca metoda de update a sistemului de particule doar updateaza pozitia acestora, nu?

In functia update doar modific pozitia si adaug particule noi.
Functia ParticleEmitter::Render e aici :

http://pastebin.com/WTNwyL9L