|
|
|
SA BITW SEGFiX Em TiGFiX Lary Engine
Grafikus motor (API)
Kategória: Grafikus motor
A projectről:
A következő grafikus motoromról van szó. Egy alapszintűt már csináltam Delphiben, ezt használta a szakdolgozatom, a PR00FPS . A mostanit Visual C++-ban csinálom, szintén egy DLL fogja tartalmazni, de sokkal profibb és gyorsabb megoldások lesznek benne. Kb. két hetet szenteltem arra, hogy átgondoljam a motor vázát és működési elvét, és már összeállt a kép. Delphiből és VC++ból is használható lesz a DLL, előbbit az is biztosítja, hogy a bemutató példaprogikat Delphiben írom, persze C++os példaprogi is lesz. Törekszek a minél gyorsabb és hatékonyabb működésre és a minél könnyebb használatra (a motort használó programozó részéről).
MS Visual C++ 2005 Express (nem managed kód),
Borland Delphi 6.0,;
| Fejlesztés kezdete: |
Tervezett befejezés: |
2007. 05. 25.
|
2010
|
Beküldve:
2007.06.07 11:24
|
Elérhetőség:
e-mail: proof88@freemail.hu
Tagok:
beküldő: proof88
regisztrált tagok:
Fejlesztés állapota:
Fejlesztés alatt
|
Képek - SA BITW SEGFiX Em TiGFiX Lary Engine
|
|
|
Csiga élsimítás nélkül
|
| 2008.02.11. 13:24 |
|
|
|
|
Csiga élsimítással
|
| 2008.02.11. 13:24 |
|
|
|
|
Teleport élsimítás nélkül
|
| 2008.02.11. 13:24 |
|
|
|
|
PR00FPS-ből teleport item élsimítva
|
| 2008.02.11. 13:23 |
|
|
|
|
Ütemterv
|
| 2007.12.25. 03:54 |
|
Fejlesztési napló - SA BITW SEGFiX Em TiGFiX Lary Engine
| proof88 |
2009.01.03. 22:35 |
|
|---|
| Ja, a nevet megváltoztattam valami értelmesebbre. Bár a JointFuture megmarad, mint kódnév, a hivatalos neve a motornak már az új, szép hosszú név. :D |
| proof88 |
2009.01.03. 22:34 |
|
|---|
| A helyzet az, hogy újra elkezdtem írni a motort, mert néhány dolog megváltozott bennem. Szerencsére az eddig befektetett munka nem vész kárba, a megírt osztályaim 90%-át felhasználom, csak apró módosításokat eszközlök bennük és a kapcsolatuk lesz más. |
| proof88 |
2008.10.07. 05:32 |
|
|---|
Ehh. Hát igen, legutóbb februárban történt érdemi dolog. Sajnos azóta nem foglalkoztam vele eleget.
De a project nem halt meg, de félig újrakezdem. Pontosabban, az eddig megírt osztályaimat használom, de a köztük lévő kapcsolatokat meg fogom változtatni, néhány dolgot ki fogok venni.
Sajnos, nagyon nehéz dolog megírni egy ultra univerzális grafikus API-t. Idő hiányában ezért stratégiát váltok, ezért néhány dolog kikerül a feature listből, és csak azokat valósítom meg, amik nekem kellenek a diplomamunkához. |
| proof88 |
2008.02.11. 13:26 |
|
|---|
| Felkerültek az első hivatalos renderelt képek. Implementálva lett a hardveresen gyorsított élsimítás, multisampling, ennek minősége futás közben állítható. A képen látható ablak már a motor által kezelt ablak, melynek szintén bármikor megváltoztathatóak a tulajdonságai. Tervezek még egyéb élsimítási lehetőségeket, például supersampling, de egyelőre most arra koncentrálok, hogy az eddigi feature-ök hiányosságait javítsam, bugfixeljek, és főleg a kód méretét csökkentsem, hogy kialakulhasson egy stabil, 0.1-es verzió. Bár a motor jól megtervezett, jelenleg még az eddig megírt osztályoknak is sok hiányossága van, a további fejlődéshez elengedhetetlen az alap megszilárdítása. |
| proof88 |
2008.01.14. 14:52 |
|
|---|
Az utóbbi időm eléggé szűkösen alakult a vizsgák miatt, és még mindig van hátra vizsgám. A CWindowManager egy rejtett manager, csak a Renderer használja, kívülről nem elérhető. Így ablakot sem lehet létrehozni kívülről, csak kérni lehet, ha nem adnak HWND-t, akkor létrehoz egy managált ablakot, aminek meghívhatóak a metódusai. Csak egy ilyen ablak lehet (nem akartam az RC-kkel szórakozni).
Futásidőben, létrehozás után is állíthatóak az ablak paraméterei, de csak a lényegi dolgok (átméretezhetőség, méretek, pozíció, stb.). Be lehet kapcsolni egy olyat, hogy átméretezéskor figyelmeztesse a Camera Managereket, hogy átméretezés történt - ekkor a cammanagerek átméretezik a hozzájuk tartozó kamerák viewportját az arányoknak megfelelően.
A CCamera osztályt módosítottam úgy, hogy beállítható, hogy az aspect ratio fix legyen, tehát a beállított arány legyen mindig, vagy dinamikus, ilyenkor az arány mindig a szélessége/magassága a viewportnak.
Most kicsit az inicializálását a renderenek írogatom át, felkészítem a multisampling-re, és tervezem, hogy még 2 dolgot csinálok a CWindow-nak: eseményekhez rendelhető fv.-mutatók (pl. OnKeyDown(), stb...), ill. egy SetAttributes() függvényt, ahol maszkolva adhatóak meg a tulajdonságok konstansokkal, tehát így egyszerűbben is be lehet állítani a dolgokat, mintha külön-külön hívogatnánk a metódusokat.
Ja, és azt is tervezem, hogy a Renderer inicializáló függvényénél is meg lehet majd adni ezt a maszkot, tehát az inicializálással lespórolható a CWindow SetAttributes() metódusa is. MINDENT A FEJLESZTŐK KÉNYELMÉÉRT (már aki majd használni fogja ezt az API-t :)). |
| proof88 |
2007.12.25. 03:58 |
|
|---|
Felraktam egy képet az ütemtervről, majd kiderül, hogy alakul. :) Pl. most is már nem úgy alakul, mert egy új managert csináltam, ami se nem light-, se nem window-, habár a windowmanager is alakulgat. :P
Tényleg igyekszek, hogy januárban megírjam azt a wrapper DLL-t, amit berakva a PR00FPS alá az új grafikus motorral, már azt használhatja a PR00FPS. Ennek az az értelme, hogy a PR00FPS kódjának megváltoztatása nélkül tudom tesztelni az új motort a PR00FPS-sel, és elhagyva a régi motort, tovább optimalizálható a régi játék. :P Nagymértékű optimalizációkra számítok, betöltési sebesség és renderelési sebesség terén is. :) |
| proof88 |
2007.12.10. 13:42 |
|
|---|
Ja és még: textúránként állítható szűrési módok, anizotropikus is.
Van CCamera, ami egyértelmű, hogy mi. Kameránként lehet viewportot állítani, tehát egyszerre több aktív kamera is lehet, pl. osztott képernyő esetén 1. kamera a bal oldalt, 2. kamera a jobb oldalt adja. Kameránként állítható tulajdonságok a látószög, szélesség/magasság arány, viewport méretek, aktív-e, stb... Csak akkor látszik egy kamera képe, ha aktív. Tehát ha van 10 kamera és abból 1 aktív akkor csak annak a képét látjuk.
Képet csak akkor láthatunk, ha legalább 1 világ (CWorld) van, és benne van legalább 1 kamera. Több világ is lehet, világonként más-más környezeti beállítások, stb.
Általában minden osztály felett egy manager osztály őrködik, pl. CImage felett CImageManager, és így tovább. Ezek hozzák létre, törlik, tehát kezelik őket. |
| proof88 |
2007.12.10. 13:37 |
|
|---|
Tehát. A fejlesztés 2007. 06. 01-én kezdődött kb., ezt megelőzte egy kb. 2 hetes fejben tervezési állapot. Ez azt jelenti, hogy most kb. fél éve fejlesztem már a motort. Elég lassan haladok, ez több oknak tudható be: egyetem, napokig tartó bugfixelése az idegesítően láthatatlan bugoknak, stb...
Jelenlegi feature-ök:
- 1-, 4-, 8-, 24-, 32- bites BMP-k betöltési lehetősége, DDS-ek betöltése, ezeket pixelenként lehet módosítani. CImage osztály felel ezekért. Van egy CTexture osztály, ami a textúrákat testesíti meg, őt is létre lehet hozni közvetlenül fájlból, de nem kezel fájlt, mert CImage osztályból csinálja a textúrát. Most bonyolult így elmagyarázni, de mindegy. Ha a kártya támogatja, generáltatja a mipmapeket, különben CPU-val generáltat. Ha már vannak, nyilván nem generáltat (pl. DDS-ek esetén, ha van bennük). Ha a kártya támogatja a BGR pixelformátumot, akkor nem húzza az időt a BMP-k esetén a BGR->RGB konvertálással. A textúrákat lehet tömöríteni, választható tömörítéssel. Ha DDS-ről van szó, nyilván nem tömörít újra. Ha DDS-ről van szó, de ki van kapcsolva a tömörítés, tömörítetlenül tárolja a textúrát. Meg lehet adni minőséget is, ami azt jelenti, hogy alacsonyabb minőség esetén negyedeli a textúrák méretét (szélesség/2 és magasság/2).
Egyelőre OBJ formátumot tud betölteni, mint modellt, de azt is fapadosan, az előző motorhoz hasonlóan. Csak kompatibilitás miatt van, nem ez lesz az elsődleges formátuma. Textúrák terén az elsődleges a DDS lesz, a BMP csak kompatibilitás miatt maradt meg meg ugye elég gyorsan feldolgozható.
Nálam a CMaterial osztályok testesítik meg az anyagokat, melyek objektumokhoz társíthatóak (és objektumok is társíthatóak anyagokhoz). Egy anyag jelenti a textúra rétegeket, a csillanások, stb. mértékét. Több réteg multitextúrázással megy.
Az objektumok a CObject osztályok, ezeket lehet megjeleníteni. A CMesh osztályok a test osztályok, ezek az alap dolgokat tárolják, pl. vertexek, uvw-k, stb...
Na nagyjából így ennyi idáig. Állítható felbontás, színmélység, etc. természetesen. Most azon dolgozok, hogy ha nem valid ablak azonosítót kap a motor inicializálásnál, akkor csinál magának egyet és oda fog rajzolni. |
Hozzászólások - SA BITW SEGFiX Em TiGFiX Lary Engine
|
Legújabb project:
electronics
Legutóbb frissített
project:
electronics
Friss kép a galériából:
|
Bocs, ezt jól benéztem. 
