dgVoodoo V1.31 - Készítette DÉGÉ, 2004 ====================================== A dgVoodoo egy Glide Wrapper, amely a Glide 2.11-nek és Glide 2.43-nak egy DirectDraw7-et és Direct3D7-et használó megvalósítása. A dgVoodoo támogatja a Windows-os és a DOS-os Glide-alkalmazások futtatását. A DOS-os programokat WinXP alatt egyelőre csak VESA-emuláció nélkül képes futtatni. ----------------------------------------------------------------------------- I. Követelmények II. A dgVoodoo 1.31-hez tartozó fájlok III. Általános tippek és megjegyzések a dgVoodoo-hoz IV. Újdonságok az 1.31-es verzióban V. Telepítés VI. Technikai megjegyzések (ez a rész átugorható) VII. DOS-os programok futtatása Windows XP alatt VIII. Az LFB közvetlen elérése IX. VESA (csak Win9x/Me -hez) X. Felbontás beállítása XI. Képernyőmentés XII. A dgVoodooSetup használata ----------------------------------------------------------------------------- I. Követelmények ---------------- - Windows 95/98/Me/2000/XP windows-os alkalmazásokhoz - Windows 95/98/Me/XP DOS-os alkalmazásokhoz - DirectX 7.0 vagy újabb - mi fontosat szoktak még ide írni? mittomén... ==================================================================================== FONTOS: ismeretlen okok miatt a dgVoodoo nem működik az ATI Catalyst 4.7 és újabb verziókkal DOS-Glide esetén (és valószínűleg a jövőben sem fog)!! Szerver módban talán igen, de az esetleges károsodások megelőzése érdekében: ezt az egész cuccot kizárólag csakis a saját felelősségedre próbáld ki!!! ==================================================================================== II. A dgVoodoo 1.31-hez tartozó fájlok -------------------------------------- glide.dll - Glide 2.11 driver a windowsos alkalmazásokhoz glide.ovl - Glide 2.11 driver a DOS-os alkalmazásokhoz (lásd a megjegyzéseket a tippek között) glide2x.dll - Glide 2.43 driver a windowsos alkalmazásokhoz glide2x.ovl - Glide 2.43 driver a DOS-os alkalmazásokhoz dgVoodoo.exe - Glide szerverprocessz a DOS-os alkalmazásokhoz dgVoodoo.vxd - Kernelmodul a DOS-os alkalmazásokhoz (Win9x/Me) dgVoodooSetup.exe - Konfigurálóprogram dgVoodooSetup.exe.manifest- Ha a setup-ot XP-stílusban szeretnéd látni, másold ezt a fájlt pontosan oda, ahova a dgVoodooSetup.exe-t is readme_eng.txt - dgVoodoo leírása, angol változat readme_hun.txt - dgVoodoo leírása, magyar változat III. Általános tippek és megjegyzések a dgVoodoo-hoz ---------------------------------------------------- - Ha ATI kártyád van, könnyen meglehet, hogy a W-pufferelést nem támogatja. Ez esetben használd a W-puffer emulációját!! Ez az emuláció azonban nem tökéletes, így hibákat okoz(hat) a látványban. :( - Amikor villog a képernyő, próbáld a wrappert a "közelebb az igazi hardver" engedélyezésével használni. A villogás akkor fordul elő, amikor egy játék nem várt módon viselkedik, miközben a wrapper az LFB-t a legoptimálisabb módon zárolja (legvalószínűbb eset a 16 bites teljes képernyő). - Ha elindítasz egy DOS-játékot, majd megjelenik a glide-ablak, aztán semmi sem történik, próbáld a cuccot nem elrejtett konzolablakkal futtatni. Lehet, hogy a játék egy hibaüzenettel kilépett, de ezt nem veszed észre, mert a konzolablak el van rejtve. - Ha a legfinomabb animációt akarod elérni, próbáld a frissítési frekvenciát az alkalmazás által igényelthez legközelebbire állítani (ld. setup) - A mipmap-ek automatikus generálása komoly műtermékeket idézhet elő a látványban, ezért általában véve nem ajánlott a használata. A mipmap egyes szintjei az eredeti textúra újramintavételezésével vannak előállítva, emiatt az alakzatok körüli colorkey színű pixelek elromlanak (colorkeying esetén gondot okoz), alfa-csatornás textúrák esetén pedig a pixelek alfája módosulhat úgy, hogy az már nem felel meg egy alpha-testinget használó programhoz. Ráadásul ha egy program folyamatosan frissítget textúrákat, akkor a sebesség az összes szint állandó kiszámolgatása miatt lecsökkenhet. - Az 2.11-es Glide library-t sajnos statikusan szerkesztették a DOS-os programokhoz (legalábbis a Glide 2.11 SDK szerint). A glide.ovl csak dinamikus esetben használható, ezért nem mellékeltem ezt a fájlt. IV. Újdonságok az 1.31-es verzióban ----------------------------------- - Glide 2.11 támogatása - Az LFB-kezelés újraírva, ez új konvertereket jelent, stb. Ez a verzió alapból támogatja az RGB565, RGB555 és ARGB1555 írási formátumokat. - A többszálúsággal kapcsolatos korábbi megoldások hibát okoz(hat)tak, pl. a Red Baron 3D-ben, javítva (legalábbis remélem, hogy most már tényleg) - Több kisebb hiba javítása - Ha egy alkalmazásból átváltunk egy másikba, majd vissza, textúrakorrupció léphet fel. Az én videodriverem pl. ilyenkor nem állítja be a textúrák állapotát "lost"-ra, holott a videómemóriának az a része, ahol azok vannak, láthatóan felülíródik. Emiatt a cooperative level helyreállásakor minden textúrát újratölt a legelső használatkor (Windows-os programok esetén lehet, hogy az alt-tab miatti váltást maga az alkalmazás is észreveszi, és emiatt nem hívja meg a wrapper függvényeit. Ekkor ez az egész sajnos nem működik). - A textúrák szűrése alapértelmezés szerint többé nem a bilineáris szűrés (elmosás), hanem a "point sampled" (nincs elmosva). - A setup viselkedése egy kicsit megváltozott: mivel most már állítgathatjuk a 2.11-es drivert is, ezért a dgVoodoo-példányok kiválasztásához már egy lista áll rendlekezésünkre. Induláskor ebbe beleteszi a megtalált driver-példányokat, de mi is adhatunk hozzá továbbiakat a "Keresés", "./" és "Win dir" gombokkal. A másik dolog, hogy most már mindkét konfigurációt (a Windows- és DOS-konfigot) beolvassa és kiírja egyszerre, ezért amikor a platformok között váltogatunk, az egyes platformokhoz tartozó beállítások többé nem vesznek el (ez a viselkedésforma még a régi időkből maradt meg, amikor a két platform beállításai külön-külön fájlban kaptak helyet). - Hibajavítások, pl. a képernyőmentés egyáltalán nem működött, stb. - Konfiguráció elmentése és betöltése a setup-ból/ba (jobb klikk, menü) - Egy-két még lényegtelenebb dolog biztos van még, de már nem emlékszek rá V. Telepítés ------------ Ha a gépen megvan az előző verzió, akkor minden komponenst írj felül az újakkal, de ne keverd őket, mert nem kompatibilisek egymással! Ha nem ezt a wrappert akarod használni, és/vagy csak ki akarod próbálni egy játékkal, akkor természetesen az említett fájlokat a kérdéses játék könyvtárába is másolhatod! Telepítés Windows-alkalmazásokhoz --------------------------------- Másold be a windows-könyvtáradba (leggyakrabban C:\WINDOWS) a GLIDE2X.DLL fájlt. Ezután a Windows-os alkalmazásoknak futniuk kell(ene). Fontos, hogy a futtatandó program könyvtárában ne legyen más wrappertől semmilyen fájl GLIDE2X.DLL néven! A GLIDE.DLL-t és tanácsos mindig az adott alkalmazás könyvtárába másolni, különben nem fogja megtalálni. Telepítés DOS-alkalmazásokhoz ----------------------------- Windows 9x/Me ------------- Másold be a Windows-könyvtáradba a következő fájlokat: DGVOODOO.EXE, DGVOODOO.VXD, GLIDE2X.DLL, GLIDE2X.OVL Az esetleges Glide2.11-hez jobb, ha a következő fájlokat mindig az adott alkalmazás könyvtárába másoljuk: DGVOODOO.EXE, DGVOODOO.VXD, GLIDE.DLL, GLIDE.OVL Használat - - - - - A megfelelő konfigurálás után indítsd el a DGVOODOO.EXE-t. Ha valami hiba történik, arról egy message box-ban értesítést kapunk. Ha a szerver talál GLIDE2.11-es és GLIDE2.43-as verziójú driver-t is, akkor felajánlja a kettő közötti választás lehetőségét. Ha a szerver sikeresen elindult, akkor az adott DOS-os programok minden további nélkül indíthatóak Glide-módban (elméletileg). Fontos, hogy a futtatandó program könyvtárában ne legyen más wrappertől semmilyen fájl GLIDE2X.OVL néven! Windows XP ---------- Másold be a Windows-könyvtáradba a következő fájlokat: DGVOODOO.EXE, GLIDE2X.DLL, GLIDE2X.OVL Az esetleges Glide2.11-hez jobb, ha a következő fájlokat mindig az adott alkalmazás könyvtárába másoljuk: DGVOODOO.EXE, GLIDE.DLL, GLIDE.OVL Használat - - - - - Ha a megfelelő konfigurálás után a wrappert VDD-módra állítottuk be, akkor a szerverprocesszt nem kell (és nem is tudjuk) elindítani, a DOS-os programok minden további nélkül indíthatóak. Ha nem VDD-módban használjuk a wrappert, akkor indítsuk el a szervert (DGVOODOO.EXE), majd futtassuk a DOS-os prg-ket. Fontos, hogy a futtatandó program könyvtárában ne legyen más wrappertől semmilyen fájl GLIDE2X.OVL néven! A konfigurálóprogram telepítése ------------------------------- Másold be a Win-könyvtáradba a dgVoodooSetup.exe fájlt, s kedved szerint készíts ehhez is egy parancsikont. Ha a setup-ot XP-stílusban szeretnéd "élvezni", akkor a dgVoodoo.exe.manifest fájlt szintén másold oda. VI. Technikai megjegyzések -------------------------- - A "közelebb az igazi hardver" opció automatikusan engedélyezve van, amikor Glide 2.11-et használsz, hogy meglegyen a kompatibilitás a Voodoo1-gyel. Ez azt jelenti, hogy a stride (azaz pitch vagy logikai sorhossz) az LFB műveletekhez mindig 2048 bájt, és az írási/olvasási pointerek a pufferekhez "állandóak" egy adott formátum esetén. - Egy bizonyos rejtett opció, a "Nincsenek egyező LFB-formátumok" szintén automatikusan engedélyezve van Glide 2.11 esetén, hogy elkerüljük a nem egyező pufferpointerek problémáját. Ez tulajdonképpen megakadályozza a dgVoodoo-t abban, hogy közvetlenül használja valamelyik belső, optimalizációhoz létrehozott pufferét. Mindezt azért, hogy az egyes pufferek írási/olvasási pointerei mindig egy adott területre mutassanak (ez fontos a Glide 2.11-ben). - A "Nincsenek egyező LFB-formátumok" akkor is engedélyezve van, amikor a wrappert egy DOS-os programhoz használod WinXP alatt szerver-módban. Ez azért van, mert egyező formátumok esetén a wrapper közvetlenül az egyik, videómemóriában levő pufferét használná, így a DOS-os program és a zárolt puffer külön-külön címtérben helyezkednének el. Megjegyzendő, hogy amikor ez az opció engedélyezve van, nincs felesleges konvertálás az adott formátumról ugyanarra a formátumra, csak egy sima másolás történik. VII. DOS-os programok futtatása Windows XP alatt ------------------------------------------------ A dgVoodoo XP alatt kétféle üzemmódban is képes futtatni a DOS-os programokat: - VDD-mód: ebben az esetben a wrapper file (glide2x.dll) egy VDD-ként (Virtual Device Driver) közvetlenül a DOS-os programot futtató NTVDM processzhez van csatolva. Előnye, hogy ilyenkor nincs szükség a szerverprocessz futtatására, a program és a wrapper egy processzt alkot, egy címtérben futnak, ugyanúgy, mint ahogy a Windows-os programok esetében, ezért akár több DOS-os program is használhatja a wrappert egyidőben (egyelőre sajnos ugyanazokkal a beállításokkal). - Szerver-mód: ilyenkor a hagyományos módon el kell indítanunk a szerverprocesszt, amely kiszolgálja a DOS-os programot. Hátrányok: mivel a program és a wrapper külön programokként külön címterekben futnak, az LFB-írás estén nem tudja kihasználni az egyező formátumok kínálta előnyöket (ilyenkor úgy veszi, hogy a két formátum soha nem egyezik, lásd LFB elérése), a szervert csak egy program használhatja. Ezt a módot akkor érdemes kipróbálni, ha a VDD-móddal valamilyen probléma lépne fel. Szintén lehetőségünk van a DOS-os programokat a háttérben is futtatni, ezzel azonban vigyáznunk kell, mert bizonyos helyzetekben (amikor a cooperative level nem megfelelő, pl. ha egy játékot teljes képernyőn futtatunk, de átkapcsolunk egy másik alkalmazásra) a wrapper bizonyos Glide-függvényeket nem képes végrehajtani, így azok hibával térnek vissza. Ennek következménye lehet, hogy a játék ezt észlelve kilép, stb. VIII. Az LFB közvetlen elérése ------------------------------ A Linear Frame Buffer elérése a videómemória közvetlen írását és olvasását jelenti. Ha egy program közvetlenül akarja elérni az LFB-t, akkor szükség szerint konvertálni kell a 3Dfx-es és a DirectDraw-puffer formátuma között. Az igazi probléma az, hogy a DirectDraw-puffert sok esetben még akkor is ki kell olvasni (a konverzió miatt), amikor az adott program csak írni akar az LFB-be. Az átalakítás elég gyors, nem nagyon okoz sebességcsökkenést, viszont maga a videómemória olvasása gyilkos lassú. A dgVoodoo megpróbálja ezt elkerülni a puffertartalom tárolásával (cache-elésével), de ez sem mindig használható. 16 bites színmélység esetén előfordulhat, hogy a két formátum megegyezik, ekkor nincs semmi konverzió, semmi olvasás, a program max. sebességgel fut. Ha azonban más felbontást adunk meg (ld. lentebb), mint amit az adott program használ, akkor a kép átméretezése miatt szintén olvasni kell a videómemóriát, tehát az LFB elérése ismét lassú lesz. Ez a verzió azonban képes arra, hogy hardveres puffereket használjon a gyorsítás érdekében. Ilyenkor már maga a videókártya olvassa a memóriát, ami gyors, bár ha egy program egy frame alatt sokszor zárolja az LFB-t úgy, hogy a tárolt puffer-tartalom (cache) nem használható, akkor így is lelassulhat (a videókártya sebessége sem végtelen). A hardveres gyorsítással különleges esetekben probléma lehet (a kártya típusától függően), ekkor kapcsoljuk ki ezt a lehetőséget, így mindig szoftveresen megy a kiolvasás, ugyanúgy, ahogy az előző verziókban. Ha nincs elég videómemória, akkor mindig szoftverből megy a dolog (bár a mai kártyákon ez igencsak valószínűtlen). MEGJEGYZÉS: Windows XP alatt, ha a DOS-os programot nem VDD-módban, hanem szerver-módban futtatjuk, az egyező formátumokkal a wrapper nem tud mit kezdeni, lásd technikai megjegyzések. Az alábbiakban ismertetett gyors írási mód azonban használható. Az 1.15-ös verziótól kezdve lehetőségünk van a nem egyező formátumokhoz gyors írási módot használni, ez a módszer azonban speciális esetben hibákat okozhat a látványban. Ez a módszer nem igényli, hogy a videómemóriát kiolvassuk és konvertálgassuk, ezért tud gyors lenni. Ha azonban a felbontás eltér a program által megadottól, akkor sajnos ismét olvasni kell a videómemóriát az átméretezés miatt. Szerencsére azonban ez ebben az esetben is történhet hardverből, ehhez a hardveres gyorsítást engedélyeznünk kell. Bevezettem egy újabb lehetőséget is, ami a puffereket olyan tulajdonságokkal ruházza fel, amelyek közelebb állnak az igazi hardveréhez, azaz egy valódi Voodoo kártyáéhoz. Ez független attól, hogy a gyorsítás hardverből vagy szoftverből megy, és abban az esetben használandó, amikor egy programot (sajnos) úgy írtak meg (a specifikációtól eltérően!), hogy kihasználja ezeket a jellemzőket. Ilyen prg pl. az Extreme Assault. Ez a többi programnál sem okoz működésbeli zavart, de azoknál nem érdemes alkalmazni, mert lassabb puffertartalom tárolást tesz lehetővé, és több memóriát is eszik. Megjegyzés: Glide 2.11 esetén ez a működési mód automatikusan engedélyezve van azért, hogy a Voodoo1-gyel kompatiblis LFB-kezelést kapjunk. Lásd még setup. IX. VESA (csak Win9x/Me -hez) ----------------------------- Ez a verzió képes a DOS-os programok számára egy 2.0-ás VESA-interfészt emulálni a szerverprocon keresztül. Az emulált VESA csak akkor érhető el, ha a szerverproc fut (mint a glide esetén), és csak olyan DOS-ablakban, ami akkor lett megnyitva, amikor a szerverproc már futott. Mindez történhet ablakos és teljes képernyős módban is. Az utóbbinak nincs sok értelme (hacsaknem a képlopáshoz, egyébként használható az eredeti VESA-driver is), de a lehetőség megvan rá. A dgVoodoo támogatja az összes felbontást 320x200-tól 1280x1024-ig 8, 16 és 32 bites színmélységben. A 320x200x256color egy standard VGA-mód, amelyet külön kell engedélyeznünk. A VESA-ra különböző paramétereket adhatunk meg, lásd setup. Ismert problémák a VESA-val kapcsolatban: - Bár azt hirdeti magáról, hogy VGA-kompatibilis, ezt csak azért teszi, hogy a programok be tudják állítani a palettát a szabványos VGA-regisztereken keresztül, és tudják magukat szinkronizálni a függőleges visszafutáshoz a státuszregiszteren (3DA) keresztül. Ezen kívül azonban semmilyen más módon nem kompatibilis a VGA-val, pl. nem tud X-módot emulálni, stb. Az SVGA-s programok többségénél ez nem gond. - Ha egy DOS-ablakban először a dgVoodoo-t használjuk, majd a szerverprocot kilőve az igazi VESA-drivert, akkor valószínűleg csak szemetet látunk a képernyőn. Ez azért van, mert a dgVoodoo felülírja a VDD (Virtual Display Driver) által a videomemóriához beállított mappinget (memória-leképezést), és azt nem bírja teljes mértékben helyreállítani. A javaslat az, hogy ebben az esetben zárjuk be az adott DOS-ablakot, és használjunk egy másikat. - A szerverproc indításakor a VESA-init könnyen sikertelen lehet. Ennek oka, hogy a videomemóriának használt memóriaterület allokálása akkor történik, amikor a kernelmodul betöltődik. (Ha a modult kiszedjük a kernelből, akkor a területet eldobja.) Alapesetben a kernelmodul dinamikus VXD-ként viselkedik, azaz a szerverproc tölti fel és szedi ki a kernelből. A fő probléma az, hogy az említett memóriaterületnek fizikailag folytonosnak kell lennie, és ezt a Windows nem biztos, hogy tudja teljesíteni, ha a fizikai lapok nagy része már össze-vissza ki van osztva különböző programok között. Ha valakit ez a jelenség felettébb idegesít, akkor tegye be a SYSTEM.INI [386Enh] szekcióbjába az alábbi sort: device = glide2x.vxd Ilyenkor a kernelmodul statikus VXD-ként működik, azaz a Windows indulásakor kerül be a kernelbe, lefoglalja a memterületet (ami ilyenkor mindig 2MB, mert a konfigot nem bírja olvasni), s csak a Windows leállításakor lövődik ki. X. Felbontás beállítása ----------------------- Ha egy adott program nem támogatja a felbontás beállítását, akkor azt mi megtehetjük a dgVoodoo-n keresztül. Ha egy adott program "túl gyakran" zárolja az LFB-t, akkor a képet állandóan újra kell méretezni és szükség szerint kiolvasni, de ha az LFB-elérés hardveres gyorsítása használható, akkor ez nem feltétlenül okoz számottevő lassulást, ellentétben az előző verziókkal, ahol ez mindig szoftverből ment. A videokártya által támogatott összes felbontást használhatjuk az eredeti helyett. Ezt a lehetőséget tényleg csak akkor használjuk, ha az adott alkalmazás nem engedi változtatni a felbontást!! XI. Képernyőmentés ------------------ Ha engedélyezzük, lehetőségünk van a képernyő tartalmát elmenteni. Ez mehet egy fájlba vagy a vágólapra egyaránt. Windows-ok programoknál a Pause gombbal, DOS-osoknál pedig a Scroll Lock gombbal menthetünk. Tudom, legalább lenne ugyanaz mindkét esetben, de technikai okok miatt egyelőre csak így bírtam megoldani. A művelet eredményét a képernyő közepén egy zöld feliraton láthatjuk. Ez alól egy kivétel van: egy 8 bites VESA-mód teljes képernyőn. Ekkor nem látunk semmit, mert 8 bites módban nem lehet a 3D-hardverrel rajzolni, márpedig a szöveg ennek segítségével kerül képernyőre. Ha fájlba mentünk, akkor a fájl neve a program neve megtoldva egy sorszámmal lesz, és a "temp" könyvtárba kerül ugyanazon a meghajtón, amelyiken a progi van. Ha a program neve nem ismert (DOS esetén lehetséges), akkor mindig a C:\temp\dgVoodoo_xyz_.bmp nevet használja (ahol _xyz_ egy sorszám). Lehet, hogy ez sem a legjobb így, később még változhat. Az elmentett bitkép 8 (teljes képernyő, VESA), 16 vagy 32 bites, attól függően, hogy hány bites módban futtatjuk a programot, és mindig .BMP formátumú. Más formátum támogatása nincs és nem is lesz betervezve. Csak mentsd el a szükséges dolgokat, aztán konvertáld, amire akarod. XII. A dgVoodooSetup használata ------------------------------- A dgVoodoo nem használ külön konfig-fájlt, amiből a mindenkori beállításokat beolvasná. Ehelyett ezek magában a GLIDE2X.DLL és GLIDE.DLL fájlban tárolódnak (a Windows-os és Dos-os beállítások egyaránt!). A setup program is ezeket a fájlokat fogja keresni, de lásd később. A setup három lapot használ, amelyen különböző opciók találhatóak. A "Global" lapon azok a beállítások vannak, amelyek a Glide-ra és a VESA-ra egyaránt vonatkoznak. Értelemszerűen a "Glide" lap csak a glide beállításait, míg a "VESA" lap csak a VESA-emuláció opcióit tartalmazza. A setup-dialóg felépítése: Platform Itt választhatjuk ki, hogy a Windowsos vagy DOS-os drivert szeretnénk-e állítgatni. Language / Nyelv A setup és a wrapper nyelvét adhatjuk meg. Beállítások a dgVoodoo alábbi példányára Ebben a combo box-ban a lehetséges konfigurálandó wrapper-fájloknak a neveit láthatjuk. Alapesetben az aktuális könyvtárban keres ilyen fájlokat, ha ott nem talál, akkor a Windows-könyvtárban. A listához további fájlokat adhatunk a "Keresés" gombbal. A "Win dir" a Windows-könyvtárában, a "./" az aktuális könyvtárban keres wrapper-fájlokat, s ha talál, azokat hozzáadja a listához. Normál esetben ezzel a résszel nem kell foglalkoznunk. Ezen elemek alatt látható az aktuális lap. Az egyes lapok között a megfelelő fülek segítségével választhatunk. "Global" lap ------------ Megjelenítőeszköz Az adott képernyőadapter kiválasztása Meghajtó A megjelenítést végző driver kiválasztása (a szoftveres meghajtókkal valószínűleg nem fog jól működni, de gondolom, ez nem túl nagy baj) Ezen két opció csak a teljesség kedvéért létezik. Képernyőmód Ablakos vagy teljes képernyős mód közül választhatunk. Kép bitmélysége A színmélységet adhatjuk meg teljes képernyős módban. Ablakos mód esetén ezt a képernyő aktuális beállítása határozza meg, amelyet meg is tekinthetünk a lapok fülei felett. Ha ez inkompatibilis a dgVoodoo-val (azaz nem 16 vagy 32 bites), akkor erre figyelmeztetést kapunk. A 16 bites mód hasznos lehet a gyors LFB-elérésekhez, ld. lentebb. Képlopás Itt engedélyezhetjük a képernyőmentést. Mentés állományba A fájlba való mentést teszi lehetővé. Mentés a vágólapra A vágólapra való mentést teszi lehetővé. Konzolablak elrejtése Csak DOS-hoz: elrejti a program konzolablakát. Egérfókusz az alkalmazásnál Csak DOS-hoz és Win9x/Me alatt: ha az adott program fut, akkor az egérfókusz a Windows-tól a programhoz kerül. Ez az opció teszi lehetővé az egér használatát. Ctrl-Alt engedélyezése Csak DOS-hoz: ha engedélyezve van, ezzel a billentyűkombinációval elengedhetjük az egérfókuszt. Működés VDD-módban Csak DOS-hoz és Windows XP-hez: a wrappert ezzel az opcióval állíthatjuk be VDD-módba. Háttérben is fut Csak DOS-hoz és Windows XP-hez: a programok a háttérben is futhatnak. "Glide lap" ----------- DirectX-textúrák bitmélysége A Direct3D-ben létrehozott textúrák bitmélysége. A dgVoodoo most a következő textúraformátumokkal képes dolgozni (a komponensek sorrendje tetszőleges): - 16 bit ARGB_4444 - 16 bit ARGB_1555 - 16 bit RGB_555 - 16 bit RGB_565 - 32 bit ARGB_8888 - 32 bit RGB_888 - 8 bit P8 Induláskor megnézi, hogy az adott videokártya ezek közül melyeket támogatja, ezeket felveszi egy listába, majd futás közben ezek közül válogat, amikor el kell döntenie, hogy egy adott 3Dfx-es textúraformátumhoz melyik felel meg a legjobban. A lehetséges opciók: - 16 bit: csak 16 bites formátumokat használjon - 32 bit: csak 32 bites formátumokat használjon - Legjobban illeszkedő: az összes formátumot figyelembe veheti, beleértve a palettás (8 bites) textúrákat is Frissítési frekvencia A monitor frekvenciája mindig a legközelebbi támogatott frekvencia: Induláskor a glide-alkalmazás megadja, hogy milyen felbontás mellett milyen frissítési frekvenciával akarja meghajtani a monitort. Ha ez az opció engedélyezve van, akkor a wrapper az adott felbontás mellett támogatott frissítési frekvenciák közül azt fogja kiválasztani, amelyik az alkalmazás által igényelthez a legközelebb esik. (Gyakorlatban azonban nem érdemes ezt használni, mert a programok többsége 60-70Hz körüli frissítést igényel, amelynél használhatunk nagyobbat is (>=85Hz), ha rendelkezésre áll.) Ha az opció nincs engedélyezve, akkor a monitor frissítési frekvenciája az általunk megadott érték lesz (alapértelmezett=a videókártya drivere dönti el, hogy ténylegesen mennyi, általában a legnagyobbat szokta kiválasztani). Képfrissítés: a tényleges függőleges visszafutáshoz igazodjon, ezzel esetleg más frekvenciát használva, mint amekkorát a program igényelt (első opció), vagy korlátozza is a frissítést a program által megadott frekvenciára (második opció). Ez remegést idézhet elő, mivel ilyenkor egyes frame-ek kimaradhatnak. Összefoglalva tehát: - Ha nem érdekes, hogy a wrapper ténylegesen azt a frekvenciát használja, amelyet a program megad (ez a nagy általános eset), akkor a monitor frekvenciáját ne állítsd a legközelebbi támogatottra, és a képfrissítéshez az első opciót használd. - Ha igenis azt akarod, hogy ugyanazt a frekvenciát használja (ez nem jellemző, bár a legfinomabb animációhoz ez ajánlott), akkor ugyanaz, mint az előbb, csak a második opciót válaszd a képfrissítéshez. - Ha az előbbi nem jó, mert ocsmány remegést látsz, akkor a monitor frekvenciáját állítsd a legközelebbi támogatottra (ha szerencséd van, tényleg közel fognak állni egymáshoz), s a képfrissítéshez használd az első opciót. - A negyedik lehetőségnek, azaz legközelebbi tám. frekv. és korlátozás a program által megadottra, nincs semmi értelme. Egy Függőleges visszafutást mindig megvár: A képbufferek cseréjekor mindig megvár legalább egy függőleges visszafutást (frissítést) akkor is, ha a program ezt nem igényli. Akkor lehet hasznos, ha egy program nem szinkronizálja magát a frissítéshez, és emiatt gyorsabban fut a mai gépeken, vagy a látvány nem túl szép. Mélységi pufferek Mélységi pufferek: mi történjen, ha egy program W-buffert használ (van egy pár ilyen): - W-buffer használata - W-buffer emulálása Z-bufferen keresztül Ezek a lehetőségek azért lettek bevezetve, mert a valódi W-pufferelés az előző verziókban rosszul működött. Amikor a W-puffer emulálva van (de még igazi W-pufferelés esetén is) lehetnek hibák a látványban a W-pufferelésben használt nagy távolságnak (Zfar) köszönhetően. Elképzelhető, hogy ezen két opció a jövőbeli verziókban teljesen eltűnik. LFB elérése Itt adhatjuk meg az LFB-elérés működésének jellemzőit. - LFB elérésének tiltása az adott művelet(ek)re (írás,olvasás) Az LFB elérése egy lassú művelet lehet. Ha az elérést letiltjuk ebben a check box-ban, akkor a programok továbbra is úgy érzékelik, mintha elérnék az LFB-t, de a valóságban egy használaton kívüli puffert látnak. A látvány emiatt hiányos lesz (olvasás esetén el is romolhat), de legalább jelentősen felgyorsul a program. - Hardveres gyorsítópufferek használata, amikor lehet Ha a 3Dfx és a DirectDraw-puffer formátuma egyezik, akkor a DirectDraw-puffer kiolvasásához magát a videókártyát használhatjuk (hardver-pufferekkel) - Gyors írás nem egyező formátumokhoz Ezzel lehet a gyors módszert engedélyezni, lásd "LFB elérése" - Csak a változások átméretezése Ha eltérő felbontást használunk, mint amit a program megad, akkor lfb-írás esetén csak a kiírt pixeleket méretezi át, nem az egész képet, azaz nem mosódik el a kép, mint a korábbi verziókban. Ez a mód csak gyorsírással használható. Egyező formátumok esetén is a gyorsírást fogja erőltetni. - Közelebb az igazi hardverhez A LFB-nek olyan tulajdonságai lesznek, amelyek közelebb állnak az igazi Voodoo kártyáéhoz. (ez az opció csak Glide 2.43 esetén érhető el) Megjegyzés: ha egy program az aux-puffert akarja írni/olvasni, amikor az mélységi- vagy alpha-pufferként működik, akkor mindig a használaton kívüli puffert fogja látni (ezen típusú pufferek zárolása még nincs implementálva :-| ). Felbontás Itt bírálhatjuk felül programok által használt felbontást. Ez a lista tartalmazza a videokártya által támogatott felbontásokat, ezek közül válogathatunk. Ha a felbontást nem akarjuk megadni, akkor a legelső elemet, a "set by the application"-t kell választanunk. Frissítési frekvencia Itt adhatjuk meg, hogy mekkora legyen a monitor frissítési frekvenciája. Ablakos módban, ill. ha a legközelebbi támogatott frekvenciára állítjuk (lásd fentebb), akkor ezt nem tudjuk kiválasztani. Textúramemória mérete Az emulált textúramemória mérete. Teljes textúramemória-emuláció Ezzel az opcióval engedélyezhetjük a tökéletes texmem-emulációt. Ilyenkor a wrapper képes mindig pontosan azt a mipmap-et használni, amit a program megad. A textúrák újraallokálása és -töltése is mindig megtörténik, ha szükséges. Ha ez az opció nincs engedélyezve, akkor a textúramemória emulálása ugyanúgy történik, mint az előző verziókban. Mipmapping tiltása Ha valamelyik programban/játékban a mipmapping esetleg csúnyán nézne ki, akkor letilthatjuk, visszaesve arra a szintre, mintha csak egyszintű textúrákat használnánk. Mindig trilineáris mipmapping A mipmap egyes szintjei között is interpolál, így nem látszódik a "határvonal" közöttük. (Ez az 1.23-ban egy rejtett opció volt.) Mipmap-ek automatikus generálása Az mipmap összes szintjének generálása, ha a mipmap csak egyetlen textúrából állna. Ha tehát egy program eleve többszintű tetúrákat használ, akkor azt nem bírálja felül. Ha ez az opció engedélyezett, mindig trilineáris mipmapping történik, ha a mipmappinget a program letiltja. Mindig bilineáris szűrés Ezzel az opcióval kikényszeríthetjük, hogy a textúrák mindig elmosva jelenjenek meg. Gamma-korrekció A kép fényerősségének megadása: ezt 0%-tól - 400%-ig állíthatjuk. Ez már ablakos módban is működik! Módszer a colorkeying-hez A colorkeying az az effekt, amikor nem jelennek meg azok a pixelek, amelyeknek a színe megegyezik a kulcsszínnel (colorkey). Háromféle módszer a colorkeyinghez: 1-es módszer: Ez egy speciális módszer a TNT-kártyákhoz (ezen kártyák egy alfa alapú elgondolás szerint valósítják meg a colorkeyinget, egy-két többlet- beállítással jár, és nem is mindig működik) 2-es módszer: Általános colorkeying módszer, amely a videókártya natív colorkeying képességét használja Alfa alapú: Általános colorkeying módszer, amely alpha-testinget és árnyék-textúrákat használ Az 1-es és 2-es módszer a videókártya natív colorkeying képességét használja ki. Ha ezek nem működnek (vagy nem adnak valami szép látványt), akkor érdemes megpróbálni az alfa-alapú colorkeyinget, amely sokkal közelebb áll a valódi Glide-colorkeyinghez. Hátránya, hogy nem tud colorkeyinget biztosítani, ha az alpha-testing engedélyezve van (ez nem teljesen igaz az 1.21-es és az afeletti verziókra), és rossz eredményt is adhat bizonyos alpha-blending módok esetén. Mindig triplapufferelés Ezzel az opcióval rákényszeríthetjük a wrappert, hogy mindig három puffert használjon az animációhoz, függetlenül attól, hogy a program mennyit ad meg (2-t vagy 3-at). Ez felgyorsíthatja a futást, azonban hibákat is okozhat a látványban, ha a program felhasználja az előző frame-ek (képkockák) tartalmát. A TR árnyék-hibájának javítása A Tomb Raider 1-ben manuálisan korrigálhatjuk az árnyékhibát. Ha ez más Dos-os programot megzavar, akkor kapcsold ki! A vágást a Direct3D végzi Ha egy program nem saját maga végzi el a geometriai vágást, hanem a wrapperre bízza, akkor az továbbpasszolja a Direct3D-nek, ha ez az opció be van állítva. A Direct3D mindig 3D-ben végzi a vágást (bár a Glide szerint csak 2D-vágás szükséges), de ezzel gondok lehetnek (eltorzult poligonok, stb.). Ha ezt nem engedélyezzük, akkor a wrapper a saját 2D-vágóalgoritmusát használja. (A 2D vágás sem tökéletes, mivel ha egy adott poligonnak pl. negatív W-koordinátái is vannak, akkor már 3D-ben kellene vágni... Ez a kérdés számomra még nem tisztázott.) Glide-gammaramp engedélyezése Engedélyezhetjük a kép fényerősségének Glide-on keresztüli állítását. Ez az előző verziókban automatikusan így történt. Hardveres vertex pufferek használata Ha engedélyezzük, a wrapper a geometriai adatokat egyből a videókártya hardveres pufferébe dobálja. Ez kiküszöböli a felesleges másolgatásokat, viszont különböző problémákat is okozhat, ezért most már nincs automatikusan engedélyezve. "VESA-lap" ---------- Ez a lap csak DOS platformnál jelenik meg. A beépített VESA-támogatás használata Ezzel engedélyezhetjük a VESA-emulációt. Frissítési frekvencia A kép frissítésének frekvenciája. Minél nagyobb, annál finomabb animációt kapunk. Vigyázz azonban, találd meg az optimumot: a frissítés időigényes művelet, nagyobb frekvencia több időt igényel, azaz kevesebb idő jut a program futására, lassabb lehet az egész! Az emulált videómemória mérete Mekkora legyen a virtuális SVGA kártya memóriája. (Az ezzel kapcsolatos problémákat lásd korábban) Vigyázz, nehogy kisebb legyen, mint amekkorát egy adott videomód igényel. 13h-as mód támogatása A szabványos 320x200 256 színű VGA-módot is emulálhatjuk. Az "OK" gombbal mentjük az aktuális beállításokat, míg a "Cancel"-lel nem. Fókusz-probléma --------------- Ha szerverproc elveszti a fókuszt, akkor az adott DOS-program futását felfüggeszti. Ha visszakapja, akkor felébreszti. Vannak esetek, amikor a szerverproc visszakapja a fókuszt, de a Windows ezt nem közli vele. Ilyenkor a program sem fut. Ebben az esetben nekünk kell inaktiválni, majd újraaktiválni a szerverproc ablakát. Teljes képernyőn ezt úgy is megtehetjük, hogy a láthatatlan egérkurzort elvisszük a kép szélére és az ablakot elkezdjük átméretezni (csak akkor, amikor az egérfókusz nem a DOS-ablaknál van). Bizonyos esetekben bosszantó lehet, hogy az egérfókusz a DOS-ablaknál van, például akkor, ha ablakban futtatjuk a programot, és azt át akarjuk méretezni. Ezt nem tudjuk megtenni (legalábbis nem túl egyszerűen), ezért bevezettem, hogy a Ctrl-Alt kombinációra az egérfókuszt engedje el a DOS-os program. Ha az ablakra kattintunk, akkor ismét visszakapja. Dégé Ha bármi problémád, kérdésed, stb. van a dgVoodooval kapcsolatban, nyugodtan küldj egy emailt a "slonderin@freemail.hu" címre. ----------------------------------------------------------------------------------------- A régebbi verziók fejlődése Hibajavítás az 1.30c verzióban ------------------------------ - Egy kisebb módosítás, aminek köszönhetően megjelennek a hiányzó textúrák a POD-ban - A többszálúsággal kapcsolatos megoldások nem működtek Win98/Me alatt, javítva Hibajavítás az 1.30b verzióban ------------------------------ - A valódi palettás textúrák egyetlen közös palettát használtak, ami érezhető sebességcsökkenést okozott. A kódot átírtam, most már mindegyiknek saját palettája van. Ez a dolog csak a GeForce kártyákat érintette (és talán a Volarikat, ha azok támogatják a palettás textúrákat, de ezt nem tudom). - Pár, az 1.30-ban elfelejtett apró dolog implementálása, pl. a lod bias használata utility-textúrákkal és DOS-ból. Újdonságok az 1.30-as verzióban ------------------------------- - Új lfb-visszaírási rendszer (a korábbi verziók hülye-módban működtek egy kicsit) - A hiányzó Glide-függvények pótlása és némelyikük implementációja - A több bázisú textúrázás támogatása (multibase texturing) - Az alkalmazások többszálú működésével kapcsolatban néhány probléma megoldva - az lfb elérését külön-külön tilthatjuk írásra és olvasásra (hasznos pl. a Screamer2-nél) - A mélységi puffer bitmélysége mindig a lehető legnagyobb (a korábbi verziókban mindig megegyezett a képbuffer bitmélységével, mert a régebbi kártyák csak ezt a felállást támogatták) - Delta0-mód implementálva - Két rejtett opció már elérhető a setup-ból is (ld. setup) - Mipmap-ek automatikus generálása - Egy csomó belső dolog átírása, javítása és egyszerűbbé tétele (a verziószám szerinti ugrás igazából ennek a mértékét tükrözi) Újdonságok az 1.23-as verzióban ------------------------------- - egértámogatás a DOS-os programokhoz WinXP alatt - Az XP-s DOS-os IRQ- és sebességproblémára egy jobb megoldás született - továbbfejlesztett pufferkezelés (zárolás), amely már kompatibilis a Carmageddonnal - hibajavítás - és újabb hibák előállítása, amelyekre csak röviddel azután fog fény derülni, amint elengedtem ezt a verziót, arra kényszerítve, hogy csináljak egy 1.23b vagy valami hasonló új verziót. Újdonságok az 1.22-es verzióban ------------------------------- - Teljesen újraírt és fejlesztett color-, alpha- és texture-combining - Az AP88 és AYIQ8422 3Dfx-es textúrák közvetlen támogatása az új multitextúrás rendszerrel, ha a videókártya támogatja a palettás textúrákat (GeForce), és van elég videómemória Ezáltal a GeForce-okon többé nem lassít egyes játékokat az állandó palettaváltás miatti textúraújratöltögetés (pl. Blood). - A depth bias implementálva (köszi az információért Zeckensacknak, remélem, most már tényleg jól működik) - pár idegesítő bug remélhetőleg kijavítva Megjegyz: a W-pufferelés emulálása esetén a depth biastól ne várjunk túl sokat, ott ezt egyelőre a wrapper nem tudja tökéletesen emulálni (mint ahogy maga w-puffer emulációja sem lehet tökéletes). Újdonságok az 1.21-es verzióban ------------------------------- Ez leginkább egy hibajavításokat tartalmazó verzió az 1.20-hoz: - A WinXP alatt DOS-os programok futtatásakor jelentkező IRQ-probléma javítása - Az LFB-t gyors írás használatakor is lehet egyszerre írásra és olvasásra is zárolni - Backface culling hibák javítása - A YIQ-táblák helyes kezelése (9 bit) - Hibák a vertexátalakító rutinokban - Az alfa alapú colorkeying bizonyos fokig akkor is képes biztosítani a colorkeyinget, amikor az alpha testing engedélyezve van - A frissítési frekvencia beállítása az egyes felbontások használatakor Újdonságok az 1.20-as verzióban ------------------------------- - Kísérleti Windows XP-támogatás a DOS-os programokhoz - Teljes textúramemória-emuláció: ha ez engedélyezve van, akkor a wrapper fenntart egy példányt a teljes textúramemóriából, és szükség esetén képes a belső textúracache-t (az éppen eltárolt tényleges textúrákat) a textúramemória alapján frissíteni. Mindez azért lett bevezetve, mert ha a wrapper csak a belső textúracache-t tartja fenn, akkor esetenként nehéz kitalálni, hogy az adott alkalmazás pontosan milyen textúrákat használ. Ez a probléma pl. akkor fordul elő, ha egy adott mipmap (többszintű textúra) egyes textúrái külön-külön kerülnek letöltésre, de egyetlen mipmapként használják őket (mint pl. az Unreal-ban vagy az Unreal Tournament-ben). Amikor a teljes textúramemória-emuláció engedélyezve van, a textúrák esetleges újratöltése mindig megtörténik. Megjegyzés: A többbázisú textúrázást (multibase texturing) ez a verzió még nem támogatja. - A mipmappinget le is tilthatjuk. - A belső textúratároló elegendően sok textúrát képes egyszerre nyilvántartani, ezért a "textúrák max száma" opciót töröltem. A tároló mérete dinamikusan változik. - A gamma-ramp (a kép fényerőssége) Glide-on keresztüli állítása letiltva (bár van lehetőség az engedélyezésére), mivel úgy vettem észre, hogy az alapértelmezett gamma-ramp (ami lineáris) túl sötét, érdemesebb meghagyni a DirectX által alapból beállított gamma-rampot. - A "W-puffer tiltása" opciót szintén töröltem, mivel nem volt semmi értelme. - Egy új módszer került a wrapperbe a colorkeyinghez: Az alfa alapú colorkeying nem a videókártya natív (természetes) colorkeying képességére támaszkodik, hanem alpha-testinget és árnyék-textúrákat használ. Ezen módszer előnye, hogy minden videókártyán ugyanazt az eredményt adja, és sokkal közelebb áll az igazi Glide-colorkeyinghez. Van azonban egy-két hátránya is: ez a módszer nem tud colorkeyinget biztosítani, amikor az alpha-testing engedélyezve van, és rossz eredményt is adhat bizonyos alpha-blending módok használatakor. Lásd még setup. - Egy 2D vágóalgoritmus implementálva: a vágást alapból a DirectX végzi 3D-ben, de ezzel néha gondok lehetnek (pl. Red Baron), ekkor a vágás kipróbálható ezzel az algoritmussal. A 2D vágás szintén nem mindig tökéletes, pl. 3D-vágás kell egy olyan háromszöghöz, amelynek negatív w-koordinátái is vannak. - Hardveres vertex pufferek használatának engedélyezése/tiltása: az előző néhány verzióban mindig engedélyezve volt, de mivel ezzel is lehetnek bizonyos gondok, ezért most már tiltani is lehet. - Palettás textúrák támogatása: ha a videókártya támogatja a palettás textúrákat (azaz egy GeForce-ról van szó), és a textúrák bitmélysége a "legjobban illeszkedő"-re van állítva, akkor az alfa nélküli P8 és YIQ422 3Dfx-es formátumokhoz palettás textúrákat használ fel a wrapper. - A Setup viselkedése kicsit megváltozott: induláskor először az aktuális könyvtárban keresi a wrapper fájlt (glide2x.dll), s ha ott nem találja, akkor nézi csak meg a Windows könyvtárában - szokásos hibajavítások - valószínűleg egy halom új hiba Az 1.15b-s verzió ugyanaz, mint az 1.15-ös, csak egy fatális és néhány kisebb hiba javítása történt meg. Újdonságok az 1.15-ös verzióban ------------------------------- Igazából semmi, ez a verzió csak azért jelent meg, mert a fejlesztés kb. 6 hónapig szünetelni fog, és ez tükrözi a jelenlegi, legfrissebb állapotot. - LFB-elérés: gyors írás a nem egyező formátumokhoz - Textúrakezelés: az yiq422 és ayiq8422 3Dfx-es formátumok támogatása - palettás (alfa nélküli) textúrák használata, ha a videókártya támogatja (nincs tesztelve) - DOS: egérfókusz elengedése a Ctrl-Alt billentyűkombinációra - Hibajavítások (Rémlik, mintha csináltam volna még valamit, de most nem jut eszembe.) Újdonságok az 1.14-es verzióban ------------------------------- Sok hibajavítás: - Textúrakezelő és -átalakító függvények - Az AP_88 3Dfx-es textúraformátum helyes kezelése és táblás (palettás) formátumok beolvasása 3DF fájlból - Alpha blending, color & alpha combine függvények - VESA-emuláció - Apróbb hiba az LFB-kezelésben - a grDepthBias függvény már nincs implementálva (rosszul működött) - A W-pufferelés most már használható (lásd "Mélységi pufferek"), de a biztonság kedvéért meghagytam az emulációs lehetőséget is A wrapper már működik a Blood-dal is, de ehhez a VESA-emulációt érdemes bekapcsolni, különben a program nem tisztázott okok miatt megfagyaszthatja a gépet. Újdonságok az 1.13-as verzióban ------------------------------- - Gyorsított és fejlesztett LFB-elérés (lásd az "LFB közvetlen elérése" résznél) - Hardveres vertex-pufferek használata, amikor lehet - Egy-két belső hiba javítása (köd, grBufferClear, stb.) Ezt a verziót egyelőre még annyira sem tudtam letesztelni, mint a többit! Ha valami nagyon nem akar működni, akkor próbáld az 1.12-est! Újdonságok az 1.12-es verzióban ------------------------------- Hibajavítás az 1.11-hez: - a 2-es módszer a colorkeying-hez nem működött, javítva (ennek GeForce kártyákon már működnie kell, ha nem is minden körülmények között) - ha nagyobb felbontást használunk, mint amit az adott prg alapesetben, akkor a vonalakat a megfelelő vastagsággal rajzolja - egyéb, a képlopás címkéjéhez tartozó hibák javítása - hibák a setupban - a nyelv kiválasztása már nem csak a setup-ra van hatással, hanem a wrapper nyelvére is (pl. képlopásnál) Újdonságok az 1.11-es verzióban ------------------------------- Ez a verzió érdemben semmi újat nem tartalmaz (inkább csak bugfix változat): - azon hibák kijavítása, amikor teljes képernyőn az init nem sikerült - belső átalakítások: az összes munkát a GLIDE2X.DLL végzi, most már ezt használja a szerverproc is (a setup is mindig a dll-t fogja keresni); ennek okai: könnyebb fejlesztés és rugalmasabb illeszkedés a majdani XP-verzióba - pár új setup opció, ebből egy rejtve eddig is megvolt, csak nem beszéltem róla: A Tomb Raider 1 Glide-hívásai nekem kicsit furcsák... alapállapotban Larának nincs árnyéka és a szöveg háttere sem sötétül el. Sokat gondolkodtam és debuggoltam, de egyelőre arra jutottam, hogy a hiba nem nálam van (persze valószínűleg igen, mert nem hiszem, hogy az eredeti Voodoo kártyákon is hibásan futott volna). Mindenesetre ha az új setup opciót bekapcsoljuk, akkor a wrapper korrigálja a hibát. Ez eddig is így volt, de most már különvettem, nehogy ez más Dos-os programot "bezavarjon". - A setupot már magyarul is elvégezhetjük - Néhány screenshot a programról Újdonságok az 1.1-es verzióban ------------------------------ - VESA-emuláció a DOS-os programokhoz - Felbontás megválasztása - Képernyőmentés - Belső optimalizációk, kicsivel gyorsabb megjelenítés - Egyéb apróságok