České-Hry.cz :: Fórum :: Zobrazit téma - Návrh interface 2D/3D enginu

Návrh interface 2D/3D enginu - obrázky a textury
Jdi na stránku Předchozí 1, 2, 3, 4 Další

Obsah fóra České-Hry.cz -> 3D API / 3D Enginy

Zobrazit předchozí téma :: Zobrazit následující téma

Autor

Zpráva

Laethnes

Založen: 14. 02. 2008
Příspěvky: 38

Zaslal: 22. listopad 2009, 10:28:50 Předmět:

Ladis napsal:

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ď).

A jé. Velmi se omlouvám, nějakým způsobem se mi podařilo tuto tvoji odpověď přeskočit. Hm, tohle řešení je poměrně dobré (touhle cestou se určitě dám), nicméně to neřeší jeden z hlavních problémů v rámci režie (omlouvám se, že jsem to nenapsal dříve). Jde o to, že se mi velice dobře pracuje s SDL_Surface pro vytváření obrázků - je rychlé (dělal jsem si nějaké testy) a nemusím řešit formáty obrázků. Průšvih tedy nastává, když udělám tohle:

kód:

// Nacte obrazek pomoci SDL_Image a pak prekonvertuje na texturu
// a posle do OpenGL
image = video.LoadImage("...");

// Vytvori novy SDL_Surface pro bliting, pripadne do nej zkopiruje data
// z OpenGL textury.
image->BeginPaint();

image2 = video.LoadImage("part.tga");

// image 2 (nacteny jako SDL_Surface a po te zkonvertovany do
// OpenGL textury) se nyni jednorazove zkonvertuje do SDL_Surface
// a vlozi do editovane SDL_Surface. Pak se smaze (leda ze by si
// vysledek image2 cachoval).
image->Blit(image2, x, y, clip);

// Treba ho chci vykreslit znovu. Pokud necachuji, znovu dojde ke
// konverzi OpenGL textury na SDL_Surface.
image->Blit(image2, x2, y2, clip2);

// Konec kresleni, SDL_Surface se zkonvertuje do OpenGL textury.
image->EndPaint();

Je tam trošku moc konverzí, nemyslíš? I když mě napadá, že by bylo možno to udělat tak, že by ke konverzi došlo až v případě, že by bylo potřeba OpenGL texturu a do té doby mít vše uloženo jako SDL_Surface...

Kdybych se měl vydat touto cestou, chtěl bych se zeptat: mám řešit to, že velikost instance třídy obrázku bude o něco větší kvůli více pointerům na SDL_Surface a stav, nebo to nemám řešit vzhledem k tomu, že je ta velikost irelevantní vzhledem k tomu, že tam mám hromadu virtuálních metod a vzhledem k tomu, že samotný obrázek/textura zabírají mnohem víc?

JohnyDog napsal:

Laethnes napsal:

No, hlavně proto, že když už chci dělat multijazyčnou aplikaci, tak pořádně. Hlavně proto, že se nechci vybodnout na tu klingonštinu, tedy v mém případě Japonštinu. Dalším důvodem je to názor, který jsem se dočetl na internetu, když jsem se o unicode prvně zajímal, že vlastně UTF-16 nemá výhodu UTF-8 - kompatibilita s ASCII, ani výhodu UTF-32 - pevná délka znaku. Hlavní výhodou je, že při použití UTF-8 mám texty ve stejném kódování pro názvy adres/souborů i pro normální texty. Používám pro to tu samou třídu a ty samé metody. Třeba když mám v nějakém XML (bohužel se mě nepodařilo uspokojivě rozjet nějaký xml parser, tak jsem si napsal vlastní - ano vím, su blbý :3) data o adrese i nějaké texty. Např. kdybych měl GUI v XML, mohu tam mít adresu k obrázku a popisek ke tlačítku. No, ohledně toho, co píšeš o UTF-32 a paměti... asi máš pravdu... I když bych chtěl dělat adventuru (ne klik & point, spíš něco mezi akční adventurou alá Japonský hry, klik & point a visual novel, tak s těmi texty a pamětí by neměl být problém. To už je spíš psychická záležitost (cože? ze 4bajtového znaku budu průměrně používat cca 1 a 1/2 bajtu?).

No kdyz uz mluvime o japonstine tak UTF16 se pouziva prave proto ze drtiva vetsina CJK znaku se v UTF16 porad vleze do dvou bajtu, v UTF8 je to na 3. (I kdyz jestli teda mluvime o japonsku, tam se na nejake Unicode vesele kasle a vsichni porad pouzivaji shift-jis Smile

)

Omlouvám se, další odpověď, které jsem si nevšiml... (Asi bych neměl chodit na fórum pozdě v noci, kdy vidím písmenka značně rozmazane...) A jé - tohle je možná informace, kterou jsem si předtím špatně interpretoval. Právě to, že jsem se mj. dočetl, že japonské znaky už zabírají 3 byty je jeden z důvodů, proč jsem na 2bytový formát zanevřel. Neuvědomil jsem si, že v UTF-16 formátu je to kratší, takže může vyjít jen na 2, jak píšeš. Hm, to je zajímavé. Další informace, kterou jdu přehodnotit.

rezna napsal:

Laethnes napsal:

V podstatě snad všechny kódování mají do 127 znaku vše společně. A kvůli tomu se vyhýbám názvům souborů v UTF-16 a UTF-32, protože v tomhle se liší (ano, kód znaku je stejný, ale již na více bytů, takže se liší řetězce).

mno takze znovu Very Happy

- mozna si vsichni nadzvedneme prdele at nesedime tady panovi na vedeni

o tom v jakem kodovani budou nazvy souboru nerozhodujes ty, ale pouzity filesystem - to ze v tom ma linux bordel a umoznuje zapisovat UTF-8 nedejboze ruzne jine zvrhlosti je pouze jeho problem - to te nenuti to pouzivat.

filesystem muze kodovat treba v mnou uvedenem HATLA-PATLA-41 ve kterem se nazev souboru rezna.txt zapise jako XXXxxx.OOO

to ale nemeni nic na tom ze ty to takto musis nekde ukladat.

ty mas funkci filesystemu a ta to poresi.

mimojine na WIN platforme mas hned dve funkce na otevreni souboru OpenFileA a OpenFileW - prvni bere ASCII cestu druha cestu v UNICODE - a co myslis? musim kvuli funkci OpenFileW vsechny soubory prejmenovat na unicode nazvy aby je umela otevrit a potom az budu chtit otevirat pomoci OpenFileA tak zase vsechno predelat zpatky na ASCII - no to asi ne co?

P.S. kdyz uz pouzivas to STL tak k vetsine veci je i 'w' verze a nemusis nejaky UTF-16 resit Razz

No - neříkám, že nemívám často dlouhé vedení, ale pokud vím, jak jsem psal, že to hodlám přehodnotit. Já ty všechny názory a informace, co píšeš uznávám a beru. (I když první informace, kterou jsem o wide verzi streamů vyhrabal byly problémy :3.) Musím se rozhodnout, zda kompletně změním přístup k tomu, jak programuju řetězce, když v tom kromě konstantní velikosti nevidím výhodu :3. Zvlášť když UTF-8 naopak má něco, co UTF-16 ani UTF-32 nemají - je TAK pohodlné neřešit, jestli jsem na BIGENDIAN nebo LOWENDIAN stroji. Bohatě mě stačilo, když jsem psal loader na md2 (hodně jsem se inspiroval právě loaderem z Irrlichtu) a nakonec dospívám k závěru, že si stejně udělám pomocné metody, šablony, které to budou řešit za mě, místo toho, abych to měl při každém načítání něčeho, co má víc, jak jeden byte (jak to měli v tom Irrlichtu)...

	Obsah fóra České-Hry.cz -> 3D API / 3D Enginy	Časy uváděny v GMT + 1 hodina Jdi na stránku Předchozí 1, 2, 3, 4 Další
Strana 2 z 4

ČeskéHry.cz - KOMUNITA HERNÍCH VÝVOJÁŘŮ