dgVoodoo V1.50 Beta2 - Készítette DÉGÉ, 2007 ============================================ Üdv újra! Nem, a dgVoodoo nem támadt fel, csak szépítgettem rajta ezt-azt. Sajnos ez még mindig csak egy béta, mivel vannak ismert, kijavítandó hibák, és hiányzó fejlesztések a Vista-val kapcsolatosan. És akkor most az általam már rohadtul utált szöveg: A dgVoodoo egy Glide Wrapper, amely a Glide 2.11 és Glide 2.43 API-nak egy DirectX-et használó megvalósítása. A dgVoodoo támogatja a Windows-os és a DOS-os Glide-alkalmazások futtatását, illetve képes a DOS-os programok számára a VESA 2.0 interfészt emulálni. ----------------------------------------------------------------------------- I. Követelmények II. A dgVoodoo 1.50-hez tartozó fájlok III. Újdonságok az 1.50-es verzióban IV. A wrapper működése, használata V. VESA-emuláció VI. Telepítés VII. DOS-os programok Windows Vista alatt (új!) VIII. Általános tippek és megjegyzések a dgVoodoo-hoz (frissítve!) IX. A DirectX7- és DirectX9-megjelenítő közti különbségek X. Technikai megjegyzések (ez a rész átugorható) XI. Felbontás beállítása XII. Képernyőmentés XIII. A dgVoodooSetup használata (GUI) XIV. A dgVoodooSetup használata (Parancssoros) ----------------------------------------------------------------------------- I. Követelmények ---------------- - Windows 95/98/Me/2000/XP/Vista 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... ==================================================================================== Ez csak egy Béta2!! Vedd ezt figyelembe, ha/amikor nem akar működni, vagy rosszabb eredményt ad a korábbi verziókhoz képest!! A DX9 megjelenítőt még mindig csak a következőkön teszteltem: GeForce 5700 Ultra, Detonator 56.64 ATI X600, Catalyst 5.6 (Még mindig nem éppen a legfrissebb drivereket használom...) ==================================================================================== ==================================================================================== FONTOS: A dgVoodoo nem biztos, hogy működik minden ATI Catalyst verzióval, lehet, hogy a gép újraindul, amikor a wrappert VDD-módban indítod egy Dos-os Glide-alkalmazással. Szerver-módban viszont működnie kell(ene). Én 5.6-os Catalysttal (is) használom bármiféle gond nélkül, azonban kaptam visszajelzéseket újraindulásokról ugyanezzel a driverrel. Épp ezért azt kell mondanom: ezt az egész szarságot kizárólag csakis a saját felelősségedre próbáld ki!!! ==================================================================================== II. A dgVoodoo 1.50-hez tartozó fájlok -------------------------------------- glide.dll - Glide 2.11 driver a Windows-os alkalmazásokhoz glide.ovl - Glide 2.11 driver a DOS-os alkalmazásokhoz (lásd a megjegyzéseket a tippek között és a wrapper használatát) glide2x.dll - Glide 2.43 driver a Windows-os 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 (csak Win9x/Me-hez) dgVesa.com - VESA 2.0 driver DOS-os programokhoz dgVoodooSetup.exe - Konfigurálóprogram readme_eng.txt - dgVoodoo leírása, angol változat readme_hun.txt - dgVoodoo leírása, magyar változat III. Újdonságok az 1.50 Beta2 verzióban --------------------------------------- - Textúramemória skálázhatósága 4MB-ra. Csak a Red Baron 3D-hez. Az ötlet és az implementációs technika GabiLaseré! Thanxx GabiLaser!!! És most, hogy írom a rídmít, jut eszembe, hogy a beígért "Ignore Palette changes" funkciót elfelejtettem beépíteni... De most már késő, hehehe... - Palettás textúrák hardveres újragenerálása a DirectX9-es megjelenítővel, ha a videókártya támogat bizonyos textúraformátumokat (a mainstream kártyák támogatják...) - A DirectX9-es megjelenítővel előbukkanó és villogó desktop-elemek, egyéb szarságok elvileg kiküszöbölve. - VESA-emu: a wrapper nem ragaszkodik foggal-körömmel ahhoz a felbontáshoz és színmélységhez, ami a használandó VESA-mód paramétereiből jön. Ha az adott üzemmódot a videodriver nem támogatja, akkor megkeresi a hozzá legközelebb allót, és azt használja, szükség esetén konvertálva a színformátumot és skálázva a képet (hasonlóan az ablakos módhoz). Mindez igaz a frissítési frekvenciára is, a setup-ban a VESA-tabon megadott frekvenciához legközelebb eső támogatott frekvenciát használja. Mindezt azért csináltam, mert egyszer Vista alatt szívtam, amikor kiderült, hogy a videódriver azt hazudja, hogy 640x480-nál kisebb felbontást nem támogat. A korábbi verziók ezeket nem támogatták, és mindig 60Hz-cel hajtották meg a monitort. Az egyetlen kivétel a 8 bit-es üzemmódok 32 biten történő kezelése volt, minthogy a DirectX9 ilyen őskövület dolgokat nem támogat. - Asszem kb. ennyi, néha mintha még nyúltam volna valamit a dgVoodoo-hoz, de azok már annyira régen voltak, hogy nem emlékszek konkrétumokra + legurult pár sör is azóta... IV. A wrapper működése, használata ---------------------------------- A régi, 3Dfx videókártyákat a Glide nevű API-n keresztül lehetett meghajtani. A Glide-nak több verziója is létezett, ahogy folyamatosan fejlődött, és számos platformon voltak driverei. A dgVoodoo szempontjából a két fontos és támogatott platform a DOS és a Windows, a két legfontosabb Glide verzió pedig a 2.11 és a 2.43. Maga a driver egy library volt, amit vagy statikusan vagy dinamikusan csatolt magához egy Glide-ot használó program. - DOS, Glide 2.11, driver: statikusan linkelt lib - DOS, Glide 2.43, driver: glide2x.ovl - Windows, Glide 2.11, driver: glide.dll - Windows, Glide 2.43, driver: glide2x.dll Az egyes fenti platformok alatt tehát a Glide-os programokhoz elég volt a megadott fájlt mellékelni (kivéve, ha maga a driver nem igényelt további fájlokat), s a program már működött is. A glide wrapperek, s így a dgVoodoo is, "mindössze" annyit csinálnak, hogy a fenti említett fájl(oka)t lecserélik olyan(ok)nal, amely(ek) ugyanúgy megvalósítják a Glide API-t, de az egyes API-hívásokat átalakítják (wrappelik) OpenGL vagy DirectX-hívásokká, így ezen programok futtatásához nincs szükség valódi 3Dfx-kártyára. DOS esetén mindezt nem lehet közvetlen módon elintézni, mivel DOS alatt nincs és nem is volt soha sem OpenGL, sem DirectX, így a dgVoodoo DOS-os driverének szüksége van a Windows-os driverre is. A DOS-os driver feladata, hogy hidat képezzen a DOS-os program és a Windows között, minden hívást továbbdob DOS-ból Windows-ba. A DOS-ból Windows-ba történő kommunikációt a dgVoodoo kétféle módon tudja megoldani: - VDD-mód: Mindenféle szempontból (technikai, kényelmi, stb.) ez a preferált mód. Ilyenkor a DOS-os driver teljesen automatikusan "betölti" a Windows-os drivert, és használja azt. Ez a mód csakis WinXP alatt használható. - Szerver-mód: Ebben az esetben elindítunk egy szerverprogramot, ami magához csatolja a Windows-os drivert, és a DOS-os driver magával a szerverrel kommunikál. WinXP alatt maga az operációs rendszer támogatja a DOS-ból Windows-ba történő kommunikációt, Win9x/Me alatt azonban nem, ezért ott ezt is a wrappernek kell megoldania (ezért jön be a képbe a dgVoodoo.vxd fájl). A wrapper használata tehát: Windows esetén a megfelelő fájlok bemásolása és az esetleges setup (dgVoodooSetup) után az adott program minden további nélkül indítható. DOS esetén a megfelelő fájlok bemásolása és wrapper VDD-módra való konfigurálása után az adott program minden további nélkül indítható. DOS esetén a megfelelő fájlok bemásolása és wrapper Szerver-módra való konfigurálása után el kell indítanunk a szerverprocesszt (dgVoodoo.exe), s ez után az adott program futtatható. A DOS-os programokat a háttérben is tudjuk 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. V. VESA-emuláció ---------------- A dgVoodoo képes a DOS-os programok számára egy 2.0-ás VESA-interfészt emulálni, kisebb-nagyobb hibákkal (na jó, valószínűleg inkább nagyobbakkal, a halál se tesztelte ezt túl sok mindennel). A VESA-emuláció a Glide-emuhoz hasonlóan szintén vagy VDD- vagy szerver-módban használható, sőt, mindehhez a glide2x.dll fájlra van szüksége, azaz a VESA-emu kódja a 2.43-as Glide-driverbe van beépítve (kivéve Win9x/Me alatt, mert ott amit csak lehet, a kernelmodul (dgVoodoo.vxd) közvetlenül megvalósít, s csak a legszükségesebb dolgok hívódnak a dll-ből, pl. képrfrissítés a DirectDraw-n keresztül). [Tudom, hogy itt illett volna az implementációt kipakolni pl. egy dgVesa.dll-be, de a visszajelzések alapján sok embernek az (is) a baja, hogy a dgVoodoo túl sok fájlból áll, nem tudják, mire valók. OK, gondoltam, akkor nem tökölök vele, az integrálás az én dolgomat is megkönnyítette a VESA-Glide közti üzemmód-váltogatásokat illetően. Talán majd úgy 2010 magasságában rendbeszedem logikailag is, amikor ezen wrapper DOS-os része már nemcsak a gyakorlatban, hanem elméletben is használhatatlan lesz, minthogy a 64 bites Windows nem támogatja 16 bites kódok futtatását.] A dgVoodoo VESA-emu támogatja az összes felbontást 320 x 200-tól 1280 x 1024-ig 8, 16 és 32 bites színmélységben. A 320 x 200 x 256color egy standard VGA-mód, amelyet külön engedélyezhetünk. A VESA-ra különböző paramétereket adhatunk meg, lásd setup. A VESA-emu használatához szükséges a DOS-os driver, a dgVesa elindítása. Win9x/Me alatt, amikor a szerver fut, és az emu engedélyezve van, minden újonnan megnyitott DOS-ablakba automatikusan installálja a DOS-drivert, így ott ebben az esetben szükségtelen a dgVesa használata. (A VESA-emu DOS-drivere a Glide DOS-driveréhez hasonlóan, csak a DOS-Windows közti kapcsolattartásra kell.) VI. Telepítés ------------- Fontos: Ha a gépen megvan az előző verzió, akkor minden komponenst írj felül az újakkal, ne keverd őket a régiekkel vagy más szoftverből származó, megegyező nevű fájlokkal! Globális telepítés: a megfelelő fájlokat a Windows-könyvtárba másold Lokális telepítés: a megfelelő fájlokat az adott alkalmazás/játék könyvtárába másold Telepítés Windows-alkalmazásokhoz ................................. Az alábbi fájlokat másold a megfelelő helyre, attól függően, hogy lokális vagy globális módon akarod a wrappert használni: GLIDE2X.DLL GLIDE.DLL (ha Glide2.11-támogatásra is szükséged van, bár ez esetben tanácsos inkább lokális telepítést végezni!) DGVOODOOSETUP.EXE Ezek után az alkalmazás minden további nélkül indítható (na jó, esetleg még konfigurálhatsz egyet, ha kell, ld. a setup használatánál). Telepítés DOS-alkalmazásokhoz ............................. Az alábbi fájlokat másold a megfelelő helyre, attól függően, hogy lokális vagy globális módon akarod a wrappert használni: GLIDE2X.DLL GLIDE2X.OVL DGVOODOOSETUP.EXE DGVOODOO.EXE DGVOODOO.VXD (ez a fájl csakis Win9x/Me alatt szükséges, XP alatt nem fog a wrappernek hiányozni) DGVESA.COM (ha VESA-támogatásra is szükséged van) VII. DOS-os programok Windows Vista alatt ----------------------------------------- Sajnos a dgVoodoo nem teljesen kompatibilis még vele, van pár kényelmetlenség, amit nem volt kedvem eddig kiküszöbölni. A dgVoodoo elméletileg használható, de csak 32 bites Vistával (mint ahogy csak 32 bites XP-vel), erről egyszer élménybeszámoltam a Vogons-on: A két fő szívás XP-hez képest a következő: - A Vista csak a Windows\System32-ből hajlandó VDD-t betölteni, gondolom valami security-baromság miatt. A lényeg, hogy a Glide2x.dll-t mindig ide kell bemásolni, ha DOS-os cuccot akarunk használni. Sőt, fontos, hogy az adott játék könyvtárában NE legyen semmilyen Glide2x.dll, mert akkor a DOS-os driver nagy örömmel az arcán észreveszi, hogy ott vala egy, és aszondja a Windows-nak, hogy konkrétan azt a példányt töltse be VDD-ként. Erre a Vista visszaüzeni, hogy na ne durvuljunk má'. (Na pl. ezt kellene még megfejleszteni, + hogy a setup a system32-ben is keressen.) Egyébként hasonló a helyzet a VDMSound-dal is, a vddloader.dll-t be kell másolni a System32-be, és máris gyönyörűen működik. - Ha a desktop composition (Aero felület) engedélyezve van, azaz a Vista az új WDDM-drivermodellel hajta a kártyát, akkor semmiféle teljesképernyős módba nem tudunk váltani (kivéve persze DirectX-en keresztül), mivelhogy ez a drivermodel nem támogat ilyet. Azaz, nincs teljes képernyős szöveges mód, VGA-mód, stb., ehelyett feldob egy üzenetet, hogy 'Ez a rendszer nem támogat teljes képernyős üzemmódot'. Aztán szokás szerint vagy elutasíthatjuk a dolgot, vagy bezárhatjuk a renitens mitképzelmagáról programot, és az átlagjúzer be is zárja, mert érthető módon fogalma sincs, hogy miről van szó. A lényeg, hogy Vista alatt kénytelen vagy használni a dgVesát VGA-emuval, ami DirectX-en keresztül megkerüli a dolgot, mert nincs más út!! Nem mondom, hogy túl sokat teszteltem volna ezügyben, de azért a fentiek alapján sikerült futtatnom a Tomb Raider 1-et. VIII. Általános tippek és megjegyzések a dgVoodoo-hoz ----------------------------------------------------- - A textúramemória skálázása azt jelenti, hogy az alkalmazás felé 4MB-ot mutat, de a valóságban annyit használ, amennyit beállítunk a setup-ban. Ennek alapvetően semmi értelme, ez kifejezetten a Red Baron 3D-hez készült, abban ugyanis van egy hiba, textúrakorrupció lép fel, ha a memória nagyobb 4MB-nál. Semmi máshoz ne használd!!!! A korrekt működéshez az is kell, hogy az alkalmazás teljesen rábízza a textúrák méreteinek a számolását a wrapperre, ugyanis azok is skálázódnak!! Ha az alkalmazás saját maga is számolgat méreteket, akkor az nem lesz összhangban a skálázott memóriával, és textúrakorrupció lép fel, ezért kifejezetten a Red Baron 3D-vel használandó!!! (Az jól viselkedik.) - Ha engedélyezzük a palettás textúrák hardveres újragenerálását, akkor kicsivel több videómemóriát zabál a wrapper, szerencsére csakis annyival többet, amennyi minimálisan szükséges. Az egésznek csak olyan alkalmazások esetén van értelme, amelyek a textúrák palettáinak folyamatos és gyakori változtatgatásával leizzasztják a wrappert. Ilyen pl. a Blood, Red Baron 3D. Azonban pl. a Tomb Raider 1-hez semmi értelme, ott a textúrák elég statikusak, csak több videómemóriát pocsékolunk el feleslegesen. Egy hülye korlát van: ha menedzselt textúrákat használsz, akkor a hw-es újragenerálás nem használható. Ne kérdezd, miért, technikailag viszonylag nehezen lett volna megoldható. - A videokártya driverét NE kényszerítsd FSAA (akárhányszoros Full Screen AntiAliasing) alkalmazására valamelyik setup-dialógján keresztül, ha a dgVoodoo-t használod!! Vagy, csinálj hozzá egy külön profil-t (ha van rá mód), amelyben az FSAA alkalmazásvezéreltre van állítva. FSAA esetén az adott buffert nem lehet zárolni, és közvetlenül írni, márpedig ez Glide-alkalmazásoknál nem szokatlan dolog. De ez vagy látványbeli hibákhoz vezet, vagy a hiba miatt abortál az alkalmazás, stb., kifelé úgy fog látszódni, hogy a wrapper hibás. Pedig nem. Hehehehe.... - Nincsenek varázsbeállítások, azaz ha a dgVoodoo egyáltalán nem működik az alapbeállításokkal, akkor valószínűleg mással sem fog (az egyetlen kivétel talán a VDD- és szerver-üzemmód) - NE használd a szervert (dgVoodoo.exe) kompatibilitási módban (WinXP)!!!! Ez megzavarja az operációs rendszer típusának detektálását, így pl. azt fogja hinni, hogy Win98 alatt fut. - 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. - Néhány programot anno úgy írtak meg (a specifikációtól eltérően), hogy kihasználja egy valódi Voodoo-kártya tulajdonságait miközben az LFB-t zárolja. (Ilyen pl. az Extreme Assault Demo). Ha furcsán "elcsúszott" pixel-sorokat, vagy hasonló jelenséget tapasztalsz, próbáld meg a wrapper "közelebb az igazi hardver" opcióját beállítani. 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 (cache-elé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. - DOS esetén a wrapper Glide-módban járulékos időzítőmegszakításokat generál, emiatt az egyes játékok gyorsabbak lehetnek a normál sebességnél. Ez eredetileg amiatt lett bevezetve, mert a 3D megjelenítés sok időt elvihetett a DOS-tól, s ez alatt bizonyos megszakítások elvesztek, lassult az adott játék menete (mint a lassított felvétel). Azóta viszont javítottam valamit az egyes szálak közti együttműködésen, s lehet, hogy ez a probléma már nem áll fenn. A korábbi verziók minden 15ms után generáltak egy megszakítást, ez a verzió minden 80ms után teszi ezt alapesetben (az 1.40+ verzióban változott 80ms-re az 1.40 40ms-áról). Ez a periódusidő minden előző verzióban rejtett opció volt. Mivel a játékok gyorsabbak lehetnek a normál sebességnél, ezért a setup-ban kikapcsolhatod az időzítő-gyorsítást, vagy visszaállíthatod a már említett 80ms-ra. (Ez egy korlátozott választási lehetőség, mivel más értékekre is be lehetne állítani, de egyáltalán nem örülök annak, hogy ezt az opciót egyáltalán kivezettem.) - 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 lenne használható, ezért nem mellékeltem ezt a fájlt. - Fókusz-probléma (Win9x/Me): 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 (vagy csak én kódoltam szarul). Ilyenkor a program sem fut. Ebben az esetben nekünk kell inaktiválni, majd újraaktiválni a szerver 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. IX. A DirectX7- és DirectX9-megjelenítő közti különbségek --------------------------------------------------------- Az ember elsőre azt gondolná, hogy a 9-es mindenképpen jobb. Általában nézve talán így is van, de sajnos a 7-esnek van néhány előnye, amit a MS volt szíves kidobni vagy megváltoztatni a későbbi interfészeken (pl. a teljes DirectDraw vasvillával való kiganajozása a 8-astól kezdve, és a teli torokból sírók számára egy-két megmaradt húscafat ráaggatása a 3d-interfészekre). A DirectX9-es megjelenítőhöz legalább DirectX 9.0c installálása szükséges, ennél korábbi verziókkal az API-t elérhetetlennek fogja érzékelni!! A DirectX9 előnyei: - Pixel shaderek. A 9-es megjelenítő 1.4-es pixel shadereket használ a teljes 3dfx pipeline emulációjához. Ez nagyobb belső pontosságot (megszabadulunk a fixed function-ben meglévő, stage-ek közötti szaturációtól) és a 3dfx pipeline majdnem tökéletes emulálását jelenti (texture combine -> chroma keying -> alphaControlITRgbLingthing -> alpha/color combine). Az FF shaderek erre közel sem képesek. Legalább 1.4-es shaderek pedig a chroma keying miatt kellenek, ennél korábbi verziókkal nem lehetne megoldani. Ha a kártyád ezt nem támogatja, akkor a 9-es renderer még mindig működik FF shaderekkel is, ám ez esetben inkább a 7-es megjelenítőt használd (ld a hátrányokat). A GeForce FX széria, és kb. a Radeon 8500-as már mind támogatják az 1.4-es shadereket. - Az alfa alapú colorkeying az alpha testingtől és blendingtől teljesen független, nem akad össze semmivel, így minden körülmények között használható. A natív ck pedig egy jól definiált módon működik, nem a driveren múlik a végeredmény. - Vertex- és indexpufferek hatékonyabb alkalmazása. A 9-eshez a hardveres vertexpufferek használata (amely az indexpuffereket is magában foglalja) kifejezetten ajánlott, szebben működik, mint a 7-esben (sőt, a tapasztalatok alapján a 7-essel inkább nem is szabad használni). Ez valószínűleg a DirectX által belsőleg kezelt buffer renaming-nek köszönhető, ami tulajdonképpen egy az alkalmazás felé átlátszó duplapuffer-technika, a 7-esben ilyesmi nincs, és a wrapper sem csinál saját maga ilyesmit. A DirectX9 hátrányai: - A Fixed Function shader megvalósítás (amely a jövőbeli verziókban valószínűleg már nem lesz benne, hiszen erre ott a 7-es) nem képes a chroma keying-et natív módon emulálni. Ez sajnos még a textúracsempézéses Lfb-elérésre is hatással van, ezért a 9-es FF a legtöbb esetben használhatatlannak bizonyulhat. Ezért javasolt a régi kártyákhoz inkább a 7-es renderer. - Az Lfb-elérés a legtöbb esetben textúracsempézéssel történik nemalapértelmezett felbontásoknál, mivel a Direct3D9 csak egy egyszerű buffer-blittelést támogat. - A front buffer elérhetetlen. A legtöbb alkalmazás számára ez tökmindegy. Viszont, hogy legalább a lehetőség meglegyen vészhelyzetek esetére, a 9-es megjelenítő átkapcsolható egy másik üzemmódba, ahol a renderbuffer-láncot saját maga tartja nyilván, és az egyes pufferek között mindig másol, s így már a front buffer is elérhető. Ez azonban kicsit ront a teljesítményen, ezért vezettem ki választható opciónak. (Ennek az egésznek egyébként van egy kellemetlen mellékhatása: amikor a front buffer elérhetetlen, pillanatképeket sem tudunk menteni, hiszen az is ennek a tartalmát mentené le...) - Teljes képernyő esetén a bufferváltások közti időtartamot nem lehet váltásonként megadni, csak inicializáláskor (azaz, hogy szinkronizálja-e magát a függőleges visszafutáshoz, vagy azonnal váltson át). Emiatt alapból mindig kivár egy függőleges visszafutást, de itt is van egy opció az azonnali váltásos üzemmódhoz azokhoz az alkalmazásokhoz, amelyek ezt igénylik. - Palettás textúrák támogatásának hiánya. Bár a GeForce-ok az FX-szériával bezárólag hardverből támogatják, a driver a 9-es interfészen keresztül nem hajlandó ezt kivezetni valamilyen oknál fogva (tippeim éppen vannak...), ezért ezt a részt a 9-es megjelenítőben nem is tudtam volna letesztelni. Mivel nem akartam a wrapperben eleve halott és teszteletlen kódot hagyni, ezért a 9-es megjelenítő mindig letiltja a palettás textúrák használatát függetlenül a kártya képességeitől. - A teljes képernyős, 8 bites VESA módokhoz mindig 32 bites képernyőmódokat használ. A D3D9 teljesen a 3D-ről szól, emiatt 8 bites módokkal már egyáltalán nem is lehet működtetni. Colorkeying DirectX7-tel: - Natív: Általános colorkeying módszer, amely a videókártya natív colorkeying képességét használja - Natív TNT-hez: 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). - Alfa alapú: Általános colorkeying módszer, amely alpha-testinget és maszk-textúrákat használ - Automatikus: Alapesetben mindig alfa-alapú colorkeyinget próbál használni, de ha ez valami miatt nem megy (nincs elég videómemória, vagy az alfa alapú módszer megszorításai miatt), akkor visszaesik natív colorkeyingre. Az alfa-alapú módszer által adott eredmény áll a legközelebb egy igazi 3Dfx-kártya colorkeying-ezéséhez, az automatikus módszer ezért erőlteti mindig ezt. Ezen módszernek hátránya azonban, hogy nem tud colorkeyinget biztosítani, ha az alpha-testing speciális módokban engedélyezve van, és rossz eredményt is adhat bizonyos alpha-blending módok esetén. Colorkeying DirectX9-cel: - Natív: Csak pixel shaderekkel használható, a 3Dfx dokumentációiban található definíció szerint működik. - Natív TNT-hez: Ez itt egy értelmetlen opció, hatása ezért a natívéval ekvivalens. - Alfa alapú: Különálló maszk-textúrák alpha komponensei alapján dob el pixeleket, hasonlóan, mint a 7-esben, de itt ez a funkcionalitás az alpha testingből a pixel shaderekbe került (FF shaderek esetén persze nem). - Automatikus: Alapesetben a natív módszert részesíti előnyben, mivel az itt már megfelel a követelményeknek, és csak bizonyos körülmények között használ alfa alapút. A natívval egy baj van: ha egy textúra-konverzió miatt pontosságvesztés lép fel (pl. amikor 16 bites textúrákat kényszerítesz a setupban, akkor a 8 bites palettás 3dfx textúrákat is arra konvertálja, azaz a 32 bites színértékeket kénytelen lecsonkolni), akkor nemcsak a colorkey színű pixeleket szűri ki, hanem a colorkey körüli kis színtartományban levőket is. Az automatikus módszer éppen az ilyen és hasonló eseteket próbálja elkerülni. FF shaderek esetén mindig az alfa alapút használja. FF shaderekre ugyanazok a megszorítások érvényesek, mint a 7-esben. X. Technikai megjegyzések (ez a rész átugorható) ------------------------------------------------ Glide LFB kezelés ................. - 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. DOS Glide ......... - VDD-módban a wrapper egy VDD-ként (Virtual Device Driver) közvetlenül a DOS-os programot futtató NTVDM processzhez van csatolva. Előnye, hogy a DOS-os programot minden további nélkül futtathatjuk, 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. - Szerver-módbeli hátrányok WinXP alatt: 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. VESA Emu ........ - Az emuláció azt hirdeti magáról, hogy VGA-kompatibilis, azonban ez csak két nagyon fontos területre igaz, a palettaregiszterekre, és a 0x3DA státuszregiszterre, mivel szinte minden DOS-os program gátlás nélkül a VGA-regisztereken keresztül állította be a palettát a 8 bites módokban, és a legtöbb szinkronizálta magát a függőleges visszafutáshoz valamilyen módon. Tehát az emu nem képes pl. X-módot emulálni, stb. (De ez a project nem is a VESA tökélyre fejlesztéséről szól...) - WinXP alatt a Linear/Flat Frame Buffer mód nem élvez támogatást. - A Bank Switching Win98/Me alatt a tényleges memórialeképezés (memory mapping) megváltoztatásával történik, kernel módban. Mivel Windows XP alatt ez túlmenne a lehetőségeken, így ott a memóriatartalom cseréjével, azaz nagy, 64K-s memóriablokkok másolgatásával megy végbe, így lassabb, mint a W98/Me-s implementáció. - csak Win9x/Me: 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. - csak Win9x/Me: a szerver indításakor a VESA-init könnyen sikertelen lehet. Ennek oka, hogy a videómemó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ójába az alábbi sort: device = dgVoodoo.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. XI. Felbontás beállítása ------------------------ Ha egy adott program nem támogatja a felbontás beállítását, akkor azt megteheted a dgVoodoo-n keresztül. Tartsd szem előtt azonban, hogy ezt a legtöbb esetben nem lehet büntetlenül megtenni, mert azonkívül, hogy grafikus műtermékeket idézhet elő, a wrappernek sokkal keményebben kell dolgoznia a háttérben, tehát teljesítménycsökkenést okozhat (főleg akkor, amikor az alkalmazás közvetlen Lfb-elérést is használ). Éppen ezért: ezt a lehetőséget tényleg csak akkor használd, ha az adott alkalmazás nem engedi változtatni a felbontást!! A videokártya által támogatott összes felbontást használhatjuk az eredeti helyett. XII. 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-os 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. XIII. A dgVoodooSetup használata (GUI) -------------------------------------- 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 setup program is ezeket a fájlokat fogja keresni, de lásd később. A setup három fő és egy rejtett tablapot használ, amelyen különböző opciók találhatóak. "Globális" lap: A Glide-ra és a VESA-ra egyaránt vonatkozó opciók "Glide" lap: Csak a Glide beállításai "VESA" lap: Csak a VESA-emulációhoz tartozó cuccok "Megjelenítő-specifikus" lap: Az egyes megjelenítők speciális beállításai (kontext-menüből csalható elő) 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. 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. "Globális" lap -------------- Megjelenítő API Választhatunk a DirectX7- és DirectX9-megjelenítő között. 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) 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. Pillanatképek 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é. 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. Konzolablak elrejtése Csak DOS-hoz: elrejti a program konzolablakát. Egérfókusz az alkalmazásnál Csak DOS-hoz: 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. Az ablak méretét mindig megőrzi Csak DOS-hoz, ablakos módban: ha az ablakot már átméreteztük kényünkre-kedvünkre, akkor a további üzemmódváltások, új felbontások hatására sem áll vissza az alapértelmezett méretre. Kép méretarányát megőrzi A kép méretarányai változatlanok maradnak az ablak méretezése közben. "Glide lap" ----------- D3D-textúrák bitmélysége A Direct3D-hez létrehozott textúrák bitmélysége. A dgVoodoo 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 videóká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: Csak teljes képernyő esetén, a frissítési frekvenciát arra a monitor által támogatott értékre állítja be, amely az alkalmazás által igényelthez a legközelebb esik. A gyakorlatban a kettő valószínűleg egyenlő lesz, mivel a legtöbb Glide-alkalmazás 60Hz-es (esetleg 70, 72) frekvenciát kér, amelyet még a legpléhebb monitornak is támogatnia kell. Ez az opció természetesen felülírja a "Frissítési frekvencia" opcióban megadott értéket. A legtökéletesebb emulációhoz és a finom animációhoz ajánlott!! [A másik régi opció, amivel tetszőleges frissítési frekvencia mellett lehetett az alkalmazás által megadottat használni, eltűnt, nem volt kedvem foglalkozni vele, amikor újraírtam a 7-es renderer alját. Nem hiszem, hogy valaki használta volna, az egyetlen értelme talán az volt, hogy nagy fr. frekvencia mellett nem folyt ki az ember szeme, de azt virtuálisan mégis le tudta korlátozni pl. 60Hz-re.] - 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. Megjegyzés: Ez az opció a DirectX9-megjelenítőre nincs hatással!! Ott a megjelenítő-specifikus beállítások között tudjuk szabályozni a renderer viselkedését (ami sajnos egy globális megszorítást jelent). 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 egy adott típusú elérést letiltunk ebben a combo 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 Tartsd mindig engedélyezve - Gyors írás nem egyező formátumokhoz Tartsd mindig engedélyezve - Textúracsempék használatának tiltása A wrapper alapesetben az adott körülmények alapján dönti el, hogy egy közvetlen LFB-íráshoz textúra- csempéket használ-e vagy nem. Ha úgy találod, hogy nem mindig dönt optimálisan, és a rohadt textúrák csak teljesítménycsökkenést vagy műterméket okoznak, akkor ezzel az opcióval letilthatod az egészet, visszaesve a sima mezei puffer-másolgatásos szintre. - 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, az "alkalmazás adja meg"-et 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. 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 lineárisan interpolál, így nem látszódik a határvonal közöttük. 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ű textúrákat használ, akkor azokat 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. Texmem skálázás 4MB-ra Engedélyezhetjük azt, hogy a textúramemória látszólag 4MB legyen. Bővebb leíráshoz lásd az általános tippeket. Gamma-korrekció A kép fényerősségének megadása: ezt 0%-tól - 400%-ig állíthatjuk. Ez ablakos módban is működik! Colorkeying módszer A colorkeying az az effekt, amikor nem jelennek meg azok a pixelek, amelyeknek a színe megegyezik a kulcsszínnel (colorkey). Négyféle módszer a colorkeyinghez: - Natív - Natív TNT-hez - Alfa alapú - Automatikus Az egyes módszerek leírását lásd a megjelenítők közti különbségek taglalásában. 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. (Lásd a megjelenítők közti különbségeket.) W-pufferelés kényszerítése Ha a videókártyád támogatja, valódi W-pufferelést kényszeríthetsz ki (régi ATI kártyák és a GeForce 6xxx-t megelőző szériák). Időzítő gyorsítása Ki-bekapcsolhatod a időzítő-gyorsítást, lásd "Általános tippek" rész. "VESA-lap" ---------- Ez a lap csak DOS platformnál jelenik meg, meglepő módon, és ha el nem sztam valamit a szetapban. 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! (Ez itt igazából már régi szöveg, kőkori gépeknél jöhet elő.) 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. A Flat/Linear Frame Buffer módok tiltása (Win9x/Me) Mivel a VESA-emu implementációja fényévekre van a tökéletestől, bizonyos programok lehet, hogy nem működnek lineáris módban. Ilyenkor próbáld meg ezt a lehetőséget kikapcsolni, hogy a jó öreg bankváltásos technikát legyen kénytelen használni. "Megjelenítő-specifikus" ------------------------ DirectX9 - Bufferek másolásának kényszerítése a láncban Az opció lényege, értelme, hogy a front buffer elérhető legyen. Nem feltétlenül érdemes mindig bekapcsolva tartani, mivel valamennyit ront a teljesítményen. - Nem szinkronizálja magát a függőleges visszafutáshoz Képváltáskor azonnali váltás. Vannak olyan alkalmazások, amelyek ezt igénylik, DirectX9 esetén ezt csak ezzel az opcióval tudjuk kényszeríteni. - Fix funkciójú shaderek kényszerítése Ha a megjelenítő nagyon nem akar működni, ezzel megnézheted, hogy a hagyományos FF-shaderekkel működik-e. (Ezt ki kellene már irtani a wrapperből, de csak egy jelentős verzióugráskor lenne értelme.) - Hardveres gyorsítás a palettás textúrák újragenerálásához, ha elérhető Önmagáért beszél, és csak pixel shaderekkel használható. - Fekete-fehér megjelenítés Ez csak afféle meglepi, nincs sok értelme. Csak pixel shaderekkel használható, és csak akkor, ha a hw ad egy kis speciális támogatást. Az "OK" gombbal mentjük az aktuális beállításokat, míg a "Cancel"-lel nem. A "Névjegy" a szokásos gomb, amivel egyáltalán nem megyünk semmire, de legalább komoly alkalmazás látszatát kelti. XIV. A dgVoodooSetup használata (Parancssoros, a speciális beállítások piszkálásához) ------------------------------------------------------------------------------------- Ha a dgVoodooSetup parancssora nem üres, a grafikus ablak nem jelenik meg, az egyes setup-műveletekhez szükséges információt a parancssorból olvassa be. A konzolon semmiféle visszajelzést nem kapunk. (Windows alatt egy alkalmazás nem tud egyszerre grafikus és konzolos is lenni, legalábbis nem egykönnyen.) A parancssori interfésszel mintázhatjuk a grafikus munkafolyamatot, ami általában a következő: - Betöltünk egy konfigurációt, vagy a wrapper fájlból (glide2x.dll, glide.dll), vagy egy exportált konfig fájlból - A konfigot módosítjuk, ha szükséges - A konfigurációt elmentjük a wrapper fájlba, és/vagy exportáljuk egy külső konfig fájlba, szövegfájlba Parancssori opciók: dgVoodooSetup [wrapperfile] [/opt1] ... [/optn] ahol a wrapperfile az alábbi módokon adható meg: File Egy adott fájl $Win$[File]|[:0|1|2] A $Win$ prefix lecserélődik a Windows folderére Ha a File-t megadtuk, azt hozzáfűzi a Windows folderhez $FirstFound$[:0|1|2] Az a könyvtár, ahol a wrapper fájlt először megtalálja 1 = glide.dll, 2 = glide2x.dll, 0 = bármelyik alapértelmezett = 0 Magyarázat a leíráshoz: (E/T = Engedélyez/Tilt) (Dec = decimális szám) (Hex = hexadecimális szám egy 'x' vagy '0x' prefixszel) (A logikai műveletek (On|Off|Inv) alapértelmezettje = On) opciók az egyes műveletekhez /?, /h, /help Segítség a parancssoros interfészhez /NoSave Nem menti el a konfigot a wrapper fájlba /Import:configfile Betölt egy konfigot configfile-ból, kötelező paraméter /Export:configfile Elment egy konfigot configfile-ból, kötelező paraméter /ExportToText:textfile A konfigot kiírja egy szövegfájlba, kötelező paraméter /Platform[:Win|Dos] A kívánt konfig használata, alapértelmezett = Win /Lang[:Eng|Hun] Nyelv, alapértelmezett = Eng a konfigot módosító opciók: /Windowed[:On|Off|Inv] E/T ablakos mód /BitDepth[:16|32] Képbuffer bitmélysége teljes képernyő esetén Alapértelmezett: 16 /ScrShot[:On|Off|Inv] E/T pillanatképek /ScrShotToCb[:On|Off|Inv] E/T pillanatképek a vágólapra /VDDMode[:On|Off|Inv] E/T VDD mód /RunInBkgnd[:On|Off|Inv] E/T háttérben futás /CLIPOPF[:On|Off|Inv] CLI/POPF kezelése (Dos, XP) /HideConsole[:On|Off|Inv] Elrejti/mutatja a konzolablakot /Mouse[:On|Off|Inv] E/T egérfókusz DOS-ra állítása /MouseCtrlAlt[:On|Off|Inv] E/T egérfókusz elengedése Ctrl-Alt-tal /PreWinSize[:On|Off|Inv] E/T ablakméret megőrzése /PreWinAspRat[:On|Off|Inv] E/T ablak méretarányának megőrzése /MonFreq[:Hex|Dec] Monitor frekv., 0 = alapért. frekv., alapértelmezett = 0 /ClosestMonFreq[:On|Off|Inv] E/T az alkalmazás által kért frekvenciához legközelebb álló támogatott monitorfrekv. beállítása, felülbírálja a MonFreq beállítást /WaitOneRetrace[:On|Off|Inv] E/T legalább egy függőleges visszafutás megvárása /TextureBitDepth[:0|16|32] Direct3D-textúrák bitmélysége, 0 = legjobban illeszkedő, alapértelmezett = 0 /PerfectTexEmu[:On|Off|Inv] E/T tökéletes textúramemória-emuláció /StoreTexCopies[:On|Off|Inv] E/T textúramásolatok tárolása /DisableMipMap[:On|Off|Inv] E/T mipmapping /AutoGenMipmap[:On|Off|Inv] E/T mipmap-szintek automatikus generálása /ForceTriMipMap[:On|Off|Inv] E/T trilineáris mipmapping kényszerítése /ManagedTextures[:On|Off|Inv] E/T managed textúrák: a textúrákat a DirectX runtime kezeli, és szükség szerint ő állítja őket helyre /TexMemScaleTo4M[:On|Off|Inv] E/T textúramemória skálázása 4MB-ra /LfbAccess[:Enable|Disable|DisableRead|DisableWrite] Lfb elérhetőségének beállítása, alapértelmezett = Enable /HwCacheBuffs[:On|Off|Inv] E/T hardveres gyorsítópufferek /FastWriteUnmatch[:On|Off|Inv] E/T gyors írás nem egyező formátumokhoz /FastWriteMatch[:On|Off|Inv] E/T gyors írás egyező formátumokhoz /ColorFmtOnLfbFmt[:On|Off|Inv] E/T Lfb írási formátumát befolyásolja az általános színformátum /RescaleChangesOnly[:On|Off|Inv]E/T csak a változások átméretezése /FlushAtUnlock[:On|Off|Inv] E/T Lfb-változások állandó ürítése zárolás feloldásakor /NoMatchingFmt[:On|Off|Inv] E/T nincsenek egyező Lfb-formátumok /TextureTiles[:Auto|Disabled|Forced] Módszer kiválasztása a textúracsempék alkalmazásához Auto = automatikus, Disabled = tiltott, Forced = mindig textúracsempék kényszerítése, alapértelmezett = Auto /LfbRealHw[:On|Off|Inv] E/T közelebb az igazi hardver /CKMethod[:Auto|Alpha|Native|NativeTNT] A colorkeying módszer beállítása, alapértelmezett = Auto /CKTntInFallback[:On|Off|Inv] E/T Native TNT módszer, amikor auto módban az alfa-alapú nem használható (csak DirectX7) /AlphaRef[:Hex|Dec] Alfa referenciaérték az auto colorkeying módszerhez tartomány: 0-255, alapértelmezett = 0 /TexMemSize[:Hex|Dec] Textúramemória mérete kB-okban, alapértlemezett = 8192 /XRes[:Hex|Dec] Felülbírált vízszintes felbontás, alapértelmezett = 0 /YRes[:Hex|Dec] Felülbírált függőleges felbontás, alapértelmezett = 0 (X=0 és Y=0 az alkalmazás által kért felbontást jelenti) /Gamma[:Hex|Dec] Gamma korrekció százalékban, tartomány: 0-400, alapértelmezett = 100 /ForceTriBuff[:On|Off|Inv] E/T triplapufferelés kényszerítése /FixTR1[:On|Off|Inv] E/T TR1 árnyék-hibájának javítása /ClipByD3D[:On|Off|Inv] E/T geometriai vágást a Direct3D végzi /GlideGamma[:On|Off|Inv] E/T Glide gamma ramp /HwVertexBuff[:On|Off|Inv] E/T hardveres vertexpufferek /WBuffDetMethod[:ForceZ|ForceW|DriverFlag] A W-puffer emulációja detektálásának módszere, alapértelmezett = DriverFlag /DepthColorEq[:On|Off|Inv] E/T a kép- és mélységi puffer bitmélysége egyenlő /ForceIndexed[:On|Off|Inv] E/T indexelt primitívek kényszerítése /PreferTMUW[:On|Off|Inv] E/T a TMU-hoz megadott W koordináta preferálása, ha szükséges /TimerBoost[:Hex|Dec] Időzítő gyorsításának periódusideje ms-okban DOS-hoz 0 = nincs gyorsítás, alapértelmezett = 80 /Vesa[:On|Off|Inv] E/T beépített VESA-emuláció használata /VesaRefRate[:Hex|Dec] VESA frissítési frekvencia Hz-ben, tartomány: 45-70, alapértelmezett = 50 /VesaMem[:Hex|Dec] VESA videómemória mérete kB-okban, alapértelmezett = 1024 /Supp13[:On|Off|Inv] E/T 0x13-as VGA mód (320x200x8) /DisableFlat[:On|Off|Inv] E/T Flat/Linear VESA módok /MirrorVert[:On|Off|Inv] E/T képernyő függőleges tükrözése opciók csak DX9-hez /DX9LfbCopy[:On|Off|Inv] E/T lfb-láncban másolás, elérhető front buffer /DX9NoVRetrace[:On|Off|Inv] E/T azonnali, szinkronizáció nélküli bufferváltás /DX9FFShaders[:On|Off|Inv] E/T FF shaderek kényszerítése /Dx9HwPalTextures[:On|Off|Inv] E/T Palettás textúrák hardveres újragenerálása /DX9BlackWhite[:On|Off|Inv] E/T fekete-fehér megjelenítés A konfiguráció a wrapper fájlból kerül betöltésre, de az /Import opció ezt felülbírálja, ha meg van adva. Ha sem wrapper fájlt, sem külső konfig fájlt nem adunk meg, akkor a setup az alapértelmezett konfigurációt használja. Ezután minden megadott módosítás megtörténik a konfigban, majd ezt elmenti a wrapper fájlban, kivéve ha a /NoSave opciót megadtuk, sőt, exportálja egy külső fájlba /Export esetén, és kiírja szövegfájlba a /ExportToText használatával. Ha egy opciónak paramétert adunk, akkor azt kettősponttal választhatjuk el. Ha egy adott paraméter nem kötelező és nincs megadva, akkor az alapértelmezett értéket használja a setup. Szintaktikai hiba vagy ismeretlen opció esetén nem történik semmi! A paracssorban a kis- és nagybetűk nincsenek megkülönböztetve. Példák: dgVoodooSetup $FirstFound$:2 /Platform:Dos /Windowed:On Megkeresi a glide2x.dll fájlt (az aktuális és Windows könytárban), betölti a DOS konfigot, beállítja az ablakos módot, aztán elmenti a konfigot. dgVoodooSetup $Win$Glide2x.dll /Platform:Win /CKMethod /Export:MyConfig.cfg Megkeresi a glide2x.dll fájlt a Windows könytárban, betölti a Win konfigot, a colorkeying módszert automatikusra állítja, aztán a konfigot elmenti, és exportálja a MyConfig.cfg fájlba. dgVoodooSetup /Platform:Win /LfbAccess:DisableRead /ExportToText:MyConfig.txt Veszi az alaértelmezett konfigot, letiltja olvasásra az lfb elérését, majd a konfigot kiírja szövegfájlba. Megjegyzések: $Win$:1 ugyanaz, mint a $Win$glide.dll, és $Win$:2 ugyanaz, mint a $Win$glide2x.dll. $Win$:0 (vagy csak $Win$) a glide2x.dll-t keresi a Windows könyvtárban, de ha nem találja, akkor a glide.dll után kutakodik. $FirstFound$:0 (vagy csak $FirstFound$) a glide2x.dll-t vagy glide.dll-t keresi az aktuális és Windows könyvtárban. A keresési sorrend: current_dir\glide2x.dll current_dir\glide.dll Win_dir\glide2x.dll Win_dir\glide.dll mint ahogy az ablakos felület is tevé ezt. Remélem, igazán borzalmasra sikeredett, jó szórakozást! :)