Návrh interface 2D/3D enginu - obrázky a textury

[Laethnes]

Chtěl bych se zeptat na radu. Chci si naprogramovat nějaké jednoduché rozhraní ke 2D a 3D grafice a chtěl bych se zeptat, jak by se to mělo řešit. Nejprve čeho chci dosáhnout: nejde mně o grafické super-hi-tech záležitosti, ale naopak, chci dělat hry nenáročné - i na starší stroje. Umím (jestli se to tak dá říct) OpenGL a pracuji v SDL. Právě kvůli starším strojům chci, aby aplikace plně podporovala OpenGL 1.1. A i když mým dalším cílem je kompatibilita s jinými systémy (Windows, Linux) tak si chci nechat otevřené dveře i pro jiné knihovny, jako je DirectX. Zároveň plánuji ve středně daleké budoucnosti (to je definice, co? :3) programování na NDS a hodně tříd a algoritmů lze s pěkným interfacem udělat obecně (hlavně GUI - to je můj hlavní problém). Tedy potřebuji něco obecného. Z mého popisu se může zdát, že by na to (kromě NDS konzole) seděl Irrlicht engine. A chvíli jsem si s ním i hrál - líbí se mě. Bohužel, jsou zde dvě věci, které mě odrazují - jednak OpenGL podporuje až od cca 1.3 (už mám za sebou jednu neplodnou diskuzi na toto téma v rámci jiného engine na jejich IRC kanálu) a jednak jako řetězce používá 16bitové znaky. Osobně dělám vždy v UTF-8 a ze všech UTF kódování právě 16bitové nemohu vystát. Když už, tak 32, ale to by zas zabíralo moc místa...

Rozhodl jsem se tedy, že si naprogramuji něco svého, pokud možno jednoduchého. Tedy nějaké interface IVideoDriver2D, IVideoDriver3D (dědí od 2D), IImage a ITexture. Průšvih, na který jsem narazil byl, když jsem si začal dělat GUI - pro tvorbu GUI prvků potřebuji kreslit do obrázku, generovat jej. Např. když dělám nějaké orámování, ohraničení, mám zdrojový obrázek, který se dá rozdělit na 3x3 čtverce. Jejich kraje vložím do rohů a zbytek vydlaždicuji. A zde narážím - jak mám navrhnout interface tak, aby to řešilo teto problém, co nejefektivněji? Jedna z možností je renderování do obrazovky (v zadním bufferu) a pak data vyjmout (v podstatě renderování do textury "postaru"). Nicméně na druhou stranu mohu použít SDL surface a renderovat do jiného surface - na obrazovku ani nešáhnu. Mohu tedy např. vykreslit složitou scénu (jak víme, úkon neskočí po skončení volání dané funkce, ale vloží se do fronty) a než grafická karta dokončí, co má, mohu generovat prvky. Nebo v jiném vlákně. Zároveň ovšem potřebuji, aby objekty typu IImage byly renderovatelné, jako 2D obrázky (ve 2D módu). Pokud tedy budu mít sadu tříd založenou na OpenGL, IImage bude vlastně textura s informacemi o původních rozměrech. Navíc takovou třídu mám navrhnutu tak, že umožní načíst obrázky, jejichž rozměry nejsou mocninou 2: při tvorbě textury se zbylé místo doplní např. bílou barvou a při vykreslení jen upravím texturovací koordináty. Takže další řešení, které mě napadlo je, vytvořit nové rozhraní a to IRenderImage či tak nějak. Pak by IRenderImage byl nezávislý na ovladači grafiky (např. takto by se načítal ze souboru, vytvářel, generoval, ...) a ovladač grafiky by pak z něj generoval IImage a ITexture. Ale nikdy jsem se s tímto návrhem nesetkal. Takže, prosím vás, jak se tohle řeší? Nejsem si jist, co z toho je nejlepší a zda neexistuje ještě něco lepšího.

[Ladis]

Ani jsem to nečet celý:

• Tlačítka s orámováním: ve 3D ti stačí mesh s 3x3 obdélníky namapovanými na texturu, kde je ten obrázek s 3x3 dlaždicema. Pak v tom meshi roztahuješ podle velikosti tlačítka jen ten vnitřek (pozice vertexů), okraje zůstanou stejně široké resp. vysoké (texturové souřadnice vertexů neměníš)).
  
• Na co potřebuješ ve 3D verzi enginu, aby obrázky IImage byly renderovatelné ve 2D módu?! Šlo by to jedině tak, že bys je měl 2x, jednou v paměti aplikace a jednou nahranou do 3D API (textura).
  
• Jak moc staré stroje chceš podporovat? OpenGL 1.1 jsou grafiky s rokem výroby tak 1996. Obvykle není důvod podporovat starší stroje než 4-5 let. Pokud je aplikace free, může běžet, na čem si zamaneš (klidně jen SM 4.0). Pokud má být komerční, targetuj jen cílovou skupinu, která je ochotna za takovou aplikaci zaplatit (tj. zjisti si, jaké mají stroje ti, co občas za něco zaplatí).

_________________
Award-winning game developer

[Laethnes]

[bolejt]

ad UTF16 nebo UTF8: Windows nativně používá UTF16, Java UTF16, o Linuxu se říká, že UTF8, ale Qt a tím pádem i KDE používá UTF16, wxWidgets mám dojem taky UTF16.

takže proč to nemáš rád? UTF16 je oproti UTF8 imho skvělá věc.

když se implementující programátor vykašle na hieroglify a klingonštinu (tj. bude podporovat jen UCS2), má s docela běžnou prací se stringem konstatní složitost.

a myslím si, že tvá starost o paměť je zbytečná pro UTF32. kolik textu hry bude mít engine v paměti v jeden okamžik?

já se omlouvám, že se v tom hrabu, ale nechápu tvůj odpor k UTF16...
_________________
Ball ball8;

[Laethnes]

[Laethnes]

Mimochodem, i když tento problém vlastně řeším už dlouho (takže mám už udělané dva funkční základy GUI a asi tak 3 různé třídy návrhu grafiky), dneska mě napadlo ještě jedno řešení. Možná trochu ve stylu Javy... IVideoDriver2D by měl metodu CreateImageRenderer(), která by vytvářela objekt nového typu IImageRenderer a tato třída by měla na starosti tvorbu obrázku. V případě třeba takového SDL by vnitřně používala SDL_Surface a nakonec na výstup by generovala objekt typu IImage. Pochopitelně, takový návrh jsem taky ještě neviděl, tak bych se chtěl zeptat, zda si myslíte, že to je dobrý nápad. Kdyby jo, tak bych asi měl udělat i metodu DestroyImageRenerer(), protože tu mám vlastně dva samostatné balíky "video" a "GUI" a tak GUI neví nic o tom, jak se vlastně objekty vytváří, že? (Tudíž, jestli má použít free, delete nebo delete[] a jestli třeba není nějaká třída, která sleduje paměť a chce jí to zahlásit. Osobně mám teď třeba přetížený operátor new a tak sleduji pamět a její úniky.)

[Ladis]

Nepotřebuješ vedle sebe ITexture a IImage, měj jen IImage (bude se používat místo ITexture). Kreslení pak můžeš mít takt, že IImage bude mít metody beginPaint a endPaint, kterými obalíš 2D kreslení do obrázku. beginPaint vytvoří v paměti surface pro kreslení, endPaint jej doplní na rozměry mocniny dvou (pokud karta neumí now-power-of-two textury) a nahraje do OpenGL. beginPaint jeste může mít optimalizaci, že bude mít parametr, zda má být obsah obrázku při začnutí kreslení nedefinovaný nebo dosavadní. Dosavadní znamená přečíst si data textury z OpenGL, nedefinovaný znamená tohle přeskočit.

Obecně pokud chceš softwarově kreslit do textury, jediné řešení je kreslit si to v system-RAM, a pak jako celek poslat do 3D API (a moje navrhované řešení tak funguje; bylo to tak i v Direct3D v dobách Lock/Unlock - nevím, jak je to tam teď).
_________________
Award-winning game developer

[JohnyDog]

[rezna]

[bolejt]

Laethnes: klingonština a hieroglify = umělé a prastaré jazyky. pokec o unicode byl tady.

to, že zatracuješ Irrlicht engine kvůli OpenGL > 1.1, to ještě s lehkým nepochopením beru, ale UTF16? to ne. vždyť je ve věcech, které se vsadím i ty používáš: Windows, Linux s KDE nebo Java.
_________________
Ball ball8;

[Laethnes]

[rezna]

WTF? proc bys musel michat vicero kodovani v jednom souboru kvuli cestam k externim filum - proste nactes XML ktere je v UTF-16 a zavolas odpovidajici systemovou funkci OpenFile - bud OpenFileA kdyz jedes v ANSI nebo OpenFileW kdyz jedes v UNICODE (UTF-16 bez viceznaku).

navic nemuzes michat vic kodovani v jednom souboru ze

mel by sis jeste uvedomit rozdil mezi kodovanim souboru, kodovanim dat v pameti, a vubec to ze to neni nijak zavisle na tom jak si to interne uklada filesystem - to za tebe resi funkce filesystemu - preci proto, ze filesystem uklada nazvy souboru v HATLA-PATLA-41 nebudu delat celou aplikaci v HATLA-PATLA-41 ne?

[Laethnes]

[Laethnes]

[rezna]