Ha az ember lánya netán hirtelen felindulásból demókészítésre adja a fejét, hamar szembejönnek mindenféle bosszantó technológiai problémák, amikre úgy tűnik még így 2008-ban sincsenek kielégítő megoldások, pedig ez már a jövő… Ilyesmikre gondolok, mint: “mivel játsszak le hangot?”, “hogyan töltsek be képet?”, “mitől lesz teljesképernyős a csodálatos demóm?”, “miért van ott a kurzor?” :), stb.
Mai rövid jegyzetünkben a második kérdésre szeretnénk egy praktikus megoldást ajánlani, legalábbis azoknak akik nem a D3DX10CreateTextureFromFile függvényt (ami ugye igazából nem is függvény :) használják erre a célra.
Előtte azonban nézzünk kicsit körbe, milyen lehetőségeink vannak (itt rögtön kiderül majd, hogy a szerző teljesen ignoráns, de ez nem baj :). Az elterjedt operációs rendszerek mély és sötét bugyraiban állítólag vannak megoldások a problémánkra, azonban ezek vagy nem jöttek szembe, vagy nem találtam őket kielégítőnek. Arról nem is beszélve, hogy abban az esetben, ha hirtelen másik rendszeren találja magát az ember (micsoda?! krosszplatform?? noooormáááááááliiis???), kezdheti elölről a mókát… Mindenütt sok helyen működő open-source library-kkel első ránézésre ugyan Dunát lehetne rekeszteni, azonban közelebbről megvizsgálva az derül ki, hogy 1) ezek mind az IJG (Independent JPEG Group) kódjára épülnek; 2) némileg túlkapás egy hatalmas library-t linkelni ami sok másik hatalmas library-re épül, amik mind külön-külön további library-kre épülnek… arról nem is beszélve, hogy ezek sikeres lefordításához és linkeléséhez minimum 5 éves intenzív tanulmányok szükségesek (Windows alatt legyen inkább 10 év).
Marad tehát az a lehetőség, hogy közvetlenül az IJG kódját használjuk, amiről elöljáróban csak annyit említenék, hogy érdekes egybeesésként ugyanezt a rövidítést alkalmazza az Islamic Jihad Group is… Tehát, ezt a C nyelven íródott, libjpeg néven futó kódot utoljára 98-ban frissítették, nagyjából mindenki erre épít, és a mazochizmus extrémebb irányzatait képviselő kódereknek kiváló szórakozás. Igazából nem lehetetlen müködésre bírni, a “we are lo-fi”-nak az a verziója, ami még szeptemberben lefutott egyszer, ezt a kódot tartalmazta, de a cikk szerzőjének várható élettartama kimutatható mértékben csökkent ennek folyományaként.
Szerencsére másoknak is feltűnt már, hogy a helyzet nem éppen kielégítő, és egy Sean Barrett nevű fiatalember, mintegy kezébe véve a sors fonalát, gyorsan összedobott egy quick-and-dirty JPEG/PNG betöltőt, amivel kb. le is fedte a használt képformátumok 90%-át. A kód nem tud sokat, de azt jól, ráadásul szerzője rögtön a Public Domainbe helyezte, ami magyarul azt jelenti, hogy azt csinálunk vele, amit akarunk (továbbá azt is, hogy lelkes amatőrök rögtön nekiálltak bővítgetni). Az egész egyetlen C file, könnyen lefordul mindenféle rendszeren (amit a fenti libjpeg-ről nem mondhatunk el), könnyen illeszthető más nyelvekhez (dettó). Dokumentáció az nem igazán van, de szerencsére nem is igazán szükséges, amikor ilyen deklarációk jönnek szembe mint:
vagy
(megjegyzem, utóbbit a libjpeg-gel elérni több napnyi hekkelés, amit feltehetőleg felad az ember félúton…).
Szóval, azon kedves olvasók, akik mindig erről álmodtak (ha van egyáltalán ilyen a szerzőn kívül :), töltsék gyorsan és használják egészséggel!
Ugyanitt Ogg Vorbis dekóder is található.
Erről álmodtam má mióta élek \o/ köszi blala kivetél az enginemböl 2 dll-t :) O_o–b
ja d–O_O–b Ogg Vorbis dekóder még egyet ;)
reméljük sok újonc csapat demoiban lesznek szép jpg texturák \o/
Az a szitu, hogy libjpeg nem olyan vad dolog. Es bar nem jut eszembe az url, van MMX optimalizalt valtozata is, ami legalabb dupla sebesseggel bir, mint az eredeti valtozata. Amugy mivel maga a “szabvany” nem valtozott 10 eve, es egy sechole-on kivul nem volt benne nagyobb gaz sem, igy ertheto miert nem frissitettek azota.
Mellesleg jpg/png/tga/bmp/dds loaderrel az igenyek 99.6%-a lefedheto.
Naja, végre valaki megemlíti a DDS-t. Végleges demóba én csak akkor használnék DDS-en kívül mást (is), hogy ha fileméret korlát közelében járnék…. Zippelt dxt1 többnyire nem is sokkal nagyobb mint egy jobb minőségű jpg.
Fresh demokba mar ezer eve DDZ van. Nem is emlekszem mikor talaltam ki ezt a formatumot. :)
pontsch: ezek szerint dolgoztál az S3-nál? :)
Itt jegyezném meg, hogy:
– GDI+-szal nagyjából 5 rövidke sor kód betölteni bármilyen, Windows által ismert képfile-t
– FreeImage crossplatform, és a blala által találthoz hasonló pofonegyszerűséggel bír
– picopng-re guglizva egy olyan (nagyjából 500 soros) cpp file-t találunk, amelyben egy darab png betöltő függvény van. 64k-hoz lehet jó.
komolyan elosszor nem akartam elhinni, hogy ez 2008-ban barkinek gondot okozhat, de mar latom a vegen en kerek elnezest…
es ez egyre csak elszomoritobb lesz :(
– a libjpeg nagyon vad dolog. Hajamat kiteptem mire Windows alatt mukodesre birtam. Tobbek kozott csunyan szet kellett hekkelni, mert magatol fagyott (!!)… Masreszt a memoriabol kitomoritest belehekkelni, az se leanyalom (elvileg fel van ra keszitve, de akik csinaltak nem ereztek letfontossagunak hogy konkretan benne is legyen, mint a filebol toltes, vagy legalabb example kodkent mellerakjak…)
– GDI+ az ugye nem eppen crosszplatform, masreszt azzal kezdtem hogy ignorans vagyok mint allat.
– DDS-t ugyan mar az OpenGL is tamogatja valami extension-on keresztul, de alapvetoen megis textura formatum. Mivan ha szukseged van a tenyleges kepre valami 2D manipulaciohoz?
– FreeImage pontosan olyan orias-library, sok masikra epitve, amit el szeretnek kerulni. Ilyenbol sok van viszonylag egyszeru API-val.
– picopng szimpatikusan hangzik, de C++ -t nem szeretem ilyen celra, jelentosen nehezebb osszelinkelni barmivel mint egy pure C kodot, es 500 sornal most igazan kurvara lehetne tiszta C is. (Kozben beirtam a gugliba, es bar a picopng maga az C++ only, de a kod amire epul az C)
– ezt talaltam meg (FreeImage hasznalja pl) OpenJpeg, ez meg JPEG2000
– a libjpeg nagyon vad dolog. Hajamat kiteptem mire Windows alatt mukodesre birtam.
Akkor valamit elcsesztel, nekem anno egy sima make volt. OSX-en is annyi leforditani W32-re.
Tobbek kozott csunyan szet kellett hekkelni, mert magatol fagyott (!!)…
Szinten.
Masreszt a memoriabol kitomoritest belehekkelni, az se leanyalom (elvileg fel van ra keszitve, de akik csinaltak nem ereztek letfontossagunak hogy konkretan benne is legyen, mint a filebol toltes, vagy legalabb example kodkent mellerakjak…)
Francot, a j_decompress_ptr structban kell kitolteni a jpeg_source_mgr structot kell csak kitolteni. Igy akar a holdrol is kepes betolteni jpeget.
– DDS-t ugyan mar az OpenGL is tamogatja valami extension-on keresztul, de alapvetoen megis textura formatum. Mivan ha szukseged van a tenyleges kepre valami 2D manipulaciohoz?
Ket dolgot tehetsz:
– development fazisban nem DDS-t hasznalsz, final buildnel cserelsz arra. (Nem veletlen van fresh TL-ben formatum felismeres, igy koddal szorakozni sem kell textura cserenel.)
– hasznalod az nVidia DDS Photoshop plugint vagy GIMP-et, ami nem tul celszeru, leven DDS (ha kis mertekben is), de veszteseges.
– FreeImage pontosan olyan orias-library, sok masikra epitve, amit el szeretnek kerulni. Ilyenbol sok van viszonylag egyszeru API-val.
En inkabb irtam sajatot, az legalabb ugy mukodik ahogy en kepzelem, es nem ugy, ahogy mas. :)
pontsch: ezek szerint dolgoztál az S3-nál? :)
Murphy: nem, de azota foglalkoztunk vele, miota megjelent az elso S3TC/FXTC/DXTC doksik. :)
S mivel DDS kvazi szabvannya valt, barmilyen fos is a formatum, igy celszru volt azt implementalni.
Ja. Van nemi felreertes. Nem a DDS-t, hanem a DDZ-t. Nem elirasvolt. :)
Ui: hova a francba tunt az edit gomb ? :)
(Gargaj kinyírta.)
hasznalod az nVidia DDS Photoshop plugint vagy GIMP-et, ami nem tul celszeru, leven DDS (ha kis mertekben is), de veszteseges
a GIMP-nek mar csak a nevenek emlitesere is egnek all az osszes szorszal a nyakamon :) Annal elcseszetebb szoftvert meg nem hordott a hatan a fold… Persze felinstallaltam, mert OSX-en nincs Paint Shop Pro, de mar egy kepkivagast is erosen negativ elmeny megcsinalni vele.
Izlesek es pofonok. Jelenleg Pixelmator-ral teljesen jol elvagyok. :)
(Amugy GIMP tenyleg szar.:)
jimmi has leading.
lehet am cikket irni ha mar egyszer jobban tudjatok :)
Ez nem igaz! A DDS egy gyűjtő formátum sok-sok pixel pixelformáttummal (pl float alapúakkal és a videokártya barát tömörítésekkel), mip-map támogatással, vagy épp volume textúrák supportjával.
A pixel formátumoknak csupán töredéke, pl a dxt1…5 ami veszteséges.
Sok előnye mellett az egyik, hogy semmiféle előfeldolgozást nem igényel. Nemk kell pl. minden egyes indításkor arra várni, hogy leszámold a mip-map fázisokat, mert azokat a textúra elmentésekor megtetted, illetve a tömörített formátumok spórolnak a kártya sávszélességével. Magyarán jobb vele fejleszteni.
Ettől függetlenül persze alap, hogy transzparens legyen a dolog, ha a modell fileban még .tga kiterjesztéssel van hivatkozás a textúrára, akkor se essen kétségbe a program.
Nem tudom, mi a bajotok a GIMP-el. Vannak funkciók, melyek könnyebben használhatóak, mint PS-ben.
A kijelölés pedig sokat javult. Aki a menük kavalkádjában nem igazodik el, annak pedig ott a GimpShop kiegészítés.
Suttogva megjegyzem a Paint Shop Pro-t nagyon szeretem én is, de ezt ne mondjátok el a többi linuxosnak :-)
Windows alatt egyszerű dolgokra szerintem: http://www.getpaint.net/
vajon tud cubemapot menteni a layerekbol ? :)
Megjegyzem, ugyanez tud lenni a hátránya is.
A normálisabb mipmap generálás (ezalatt főleg a rectangular filter-nél komolyabb megvalósításokat értem) nem csak a textúrától, hanem a felhasználástól is függ: nem mindegy, hogy a textúra wrap-es vagy clamp-es, pl. Ha több helyen használod ugyanazt a textúrát, akkor lehet hogy különböző paraméterekkel számolt mipmap-ek kellenének…
Ilyenkor persze lehet csinálni több verziót az adott textúrából, de az N-szer több resource, amiket utána frissíteniük kell szegény grafikusoknak, ha változik az eredeti textúra, stb. Egyszerűbb, ha a kód is tud generálni mipmap-eket, olyan paraméterekkel, amilyenre szükség van.
[ módosítva Mar. 4. 23:35 ]
Kipróbáltam az ott lévő ogg betöltőt is. Sajnos kb csak fele-harmad olyan gyors mint a gyári libvorbis+libogg+libvorbisfile triumvirátus, de még így is sokkal jobb, mivel nem egy ilyen ormótlan összevissza háromfelészedett licenszaggályos fos. Lassúsága ellenére is tudom ajánlani a használatát, nekem az 1250 mhz-s k7 processzoromon kb 1 mega/másodperc sebességgel dekódolja az ogg fájlokat, ez egy mai gépen azt jelenti hogy egy átlagos 3 perces ogg muzsikát fél – 1 másodperc alatt betölt.