Numele proiectului : K_Game 3D Game Engine
Membrii :Catalin-Alexandru Nastase [katoun]
Oras : Bucuresti
Tehnologii: OpenGL,DirectInput,Win32,Angelscript
Licenta: LGPL
Categorie:3D Game Engine
Stadiu:WIP
Site : http://k-game.sourceforge.net/

Din ce am vazut pe site, e destul de interesant. Mai e si open-source. Dar cred ca ar fi mai bine sa aiba suport pentru mai multe formate, nu doar tga.

Cum e gandit engine-ul? Sa fie cat mai usor de folosit, cat mai detaliat (deci mai mult de codat pe partea celui care-l utilizeaza), sau echilibrat? Desi sunt sigur ca ai sacrificat una din cele de mai sus pentru alta.

// Sper ca intelegi ce vreau sa zic, nu prea am gasit cuvintele potrivite.

Salut.
Pai e cam "echilibrat" si tind sa-l metin asa in timp ce lucrez la el.
Incerc sa am un nivel de abstractizare dar care sa nu depaseas "bunul simt", adica care sa aduca destula functionalitate fara a avea multe dependente.

Am mai vb legat de el si aici http://www.gamedev.ro/forum/topic/888 deoarece are ceva legatura cu Ogre .

DDS . Eu l-am folosit si in aplicatii OpenGL (cu loader scris de mine) si stie chestii de care TGA nu e in stare (texture compression, mipmapuri precompilate, floating point textures). Eu zic ca nu ai absolut nimic de pierdut (poate o ora-doua sa scrii 300 de linii de cod). Tooluri marfa (pluginuri photoshop, viewere si alte minuni) gasesti pe site-ul NVidia. Spor la treaba .

Chiar m-am gandit la DDS si voi adauga si asa ceva, dar Acum lucrez la implementarea de Hardware Buffers care nus asa de usoare de implementat daca vrei sa fie codul harware independant.

ce iti recomand e sa use STL .. standard, propria ta librarie o sa isi arate limitarile in timp, asa am avut si eu, ceva ani, si apoi am vazut STL, la inceput mi s-a parut o mare varza, azi nu mai pot face o aplicatie fara el, doar recomandarea mea...

STL are foarte putine lucruri folositoare pentru jocuri: std::vector (dar trebuie sa fii atent), std::sort si inca o mina de chestii de prin header-ul algorithm. Restul este dezastruos. Containerele in special sint foarte nasoale, deoarece majoritatea fac o alocare per element (in afara de alocarea elementului in sine). De asemenea lipsesc unele chestii care ar fi utile, cum ar fi un hash map (se gasesc in boost si vor exista in C++0x, dar asta e alta discutie). Multe implementari ofera un hash map ca extensie, dar de obicei vin cu functii de hashing cel putin groaznice (de exemplu prostia folosita in VC pentru hash-uri de string-uri).

Mergind mai departe, cel mai nasol lucru pe care-l poti face este sa folosesti STL intr-o biblioteca pentru care distribui doar binarele (ceea ce probabil nu-i cazul aici, dar asa, ca idee). Nu exista o interfata binara standardizata pentru STL, astfel incit daca linkezi cu un lib ce foloseste STL, trebuie sa folosesti si tu exact acelasi compilator si aceleasi setari ca el. In particular, in STL-ul de la Dinkumware (care-i folosit de catre Microsoft in VC, de exemplu), mai toate obiectele au dimensiuni diferite intre debug si release si in functie de diverse macro-uri care mai de care mai dubioase (_SECURE_SCL e preferatul meu pentru aplicatii ce se doresc real-time).

STL este si o metoda foarte buna pentru a genera code bloat. Fiind template-uri, se genereaza cod separat pentru fiecare tip inclus intr-un container, ceea ce face sa-ti explodeze dimensiunea executabilului si a codului in RAM. E posibil sa nu ajungi sa te preocupi de eficienta cache-ului de cod, dar daca ajungi si descoperi ca-i de la STL, e prea tirziu. Unele compilatoare (printre care si VC, din fericire) fac eforturi substantiale pentru a nu duplica instantierile care ajung sa contina acelasi cod (de exemplu toti vectorii de pointeri chori pot folosi acelasi cod, indiferent de tipul pointat), dar nu merge intotdeauna si e dubios sa te bazezi pe un feature ezoteric al unui compilator.

In concluzie, nu folosi nimic din STL decit daca intelegi exact ce face si ce inseamna asta pentru codul tau.

LE: DDS e singurul format de textura pe care trebuie sa-l suporti. Toate celelalte (TGA, BMP, JPG etc.) sint balarii optionale, dar DDS e obligatoriu, pentru ca nimeni n-ar trebui sa fie nebun si sa foloseasca de 4 sau 8 ori mai mult RAM video decit trebuie.

Da, nici eu nu folosesc STL, si as mai adauga ca au fost probleme cu trecerea de la 2003 la 2005 (in sensul ca acelasi cod care mergea pe 2003 nu mai mergea pe 2005 din cauza STL).

Partea cu STL-ul o stiu foarte bine, de aceea am mers asa in avea propriile containere, sunt scrise curat si pot fi usor urmarite la debug si asa mai departe...

Hm, la partea cu DDS-urile, m-ati pus pe ganduri nitel si asta nu e un lucru rau. Stiu ca aveti dreptate si am considerat cu exceptia dds-urilor tga-urile sunt cele mai potrivite pt jocuri 3D. Dupa de ma chinui cu Hardware Bufferele si le implementez bine o sa ma uit cum sa implementez dds-uri.

trebuie sa stii cand sa folosesti STL si cand nu, iar partea cu rebeliunea impotriva STL/Microsoft/optimizare am auzit-o de multe ori , good luck, no more comments.
Plus, daca iti faci mini libu tau de vectors/strings, tot la templates ajungi, si tot la problemele de compilare, asa ca mai bine decat sa intretin si acel lib, iau unul care dupa cate am vazut e destul de ok, bineinteles ca nu e mana cereasca, insa eu unul asta am invatat in atatia ani, unde roata merge ok nu o mai reinventa, unde e mai ovala, o poti reinventa, dar in cazul STL nu vad probleme majore, doar daca tii mortis sa iti faci tu super libu mai rapid de N ori decat STL. Nu are rost, tot la rezultatele alea ajungi, poate chiar mai rau. Am avut cativa ani buni my own lib, a mers ok pana cand am avut nevoie de new features care trebuiau gandite si implementate, care luau timp si resurse pentru a fi testate, iar STL pana acum nu mi-a facut probleme de viteza sau alte alea, singurele issues au fost cele "obvious"/clare, la care eram eu stupid si nu STL-ul, anyway, nu e numai pt STL aceasta problema, e pentru multe alte libs, daca-s facute si probate ca merg, use them, asa doar ca sa inveti e ok sa iti faci tu, insa daca vrei sa faci ceva care sa mearga ok sau ceva spre comercial sau public, e mai bine sa use libs care si-au dovedit eficacitatea si functionalitatea, nu reinventa roata aiurea (daca e doar pentru a invata, atunci da).

PS: But again, I'm just an old fart

Salutare.
Lucrurile au mai evoluat de atunci.
Acum am sunet prin OpenAL, fizica prin PhysX, si de curand un scene loading care va fii suportat de 3dMax exporter.

Si mult, mult refactoring si bug fixing.