dgVoodoo v1.

50 Beta2 by DEGE, 2007

==================================
Hi again! No, dgVoodoo hasn't resurrected, I've just done some cosmetic
intervention on it.
Unfortunately it's still a beta as there are known bugs to fix as well as
missing developments related to Windows Vista.
And now, the well-known fanfare I hate so much:
dgVoodoo is a Glide Wrapper that implements Glide 2.11 and Glide 2.43 API by
using DirectX.
dgVoodoo provides support to run Windows-based and DOS-based applications using
Glide, and it can also emulate VESA 2.0 for DOS applications.
-----------------------------------------------------------------------------
I. Requirements
II. Files of dgVoodoo 1.50
III. What's news in 1.50
IV. Working of, and using the wrapper
V. VESA emulation
VI. Installation
VII. Running DOS programs under Windows Vista (new!)
VIII. General tips for dgVoodoo (updated!)
IX. Differences between DirectX7 and DirectX9 renderers
X. Technical notes (you can skip this section)
XI. Resolution setting
XII. About screen shots
XIII. Using dgVoodooSetup (GUI)
XIV. Using dgVoodooSetup (Command line)

-----------------------------------------------------------------------------
I. Requirements
---------------
- Windows 95/98/Me/2000/XP for Windows applications
- Wndows 95/98/Me/XP for DOS applications
- DirectX 7.0 or greater
- what else important to write here? Idonnow
================================================================================
====
This is a Beta2 only!! I didn't do extensive testings, so take it into account i
f/when
it refuses to work, or gives worse result compared to earlier versions!!
DX9 renderer is still tested only on: GeForce 5700 Ultra, Detonator 56.64
ATI X600, Catalyst 5.6
(The drivers I use are still not really up to date...)
================================================================================
====
================================================================================
====
IMPORTANT: dgVoodoo may not work with all ATI Catalyst versions, your PC may reb
oot
when launching the wrapper in VDD mode with DOS-Glide applications.
It should work in server mode however. I myself use it with Catalyst
5.6
without any problems, but there are reports about rebooting with the
same
driver.
So, I must say that use this shit only at your own risk !!!
================================================================================
====
II. Files of dgVoodoo 1.50
--------------------------
glide.dll - Glide 2.11 driver for windows-based appli
cations
glide.ovl - Glide 2.11 driver for DOS-based apps
(see remarks on it!)
glide2x.dll - Glide 2.43 driver for windows-based appli
cations
glide2x.ovl - Glide 2.43 driver for DOS-based apps
dgVoodoo.exe - Glide server process for DOS-based apps
dgVoodoo.vxd - Kernel module for DOS-based apps
dgVesa.com - VESA 2.0 driver for DOS
dgVoodooSetup.exe - Setup program
readme_eng.txt - dgVoodoo documentation, English version
readme_hun.txt - dgVoodoo documentation, Hungarian version
III. What's new in v1.50 Beta2
------------------------------
- Texture memory scalability to 4MB. Only for Red Baron 3D.
Idea and implementation technique is by GabiLaser!! Thanxxx GabiLaser!!!
And now that I'm writing this readme, it has come to my mind that I forgot
to include the promised "Ignore Palette Changes" function in the wrapper..
.
But it's late....
- Hardware accelerated regenerating of paletted textures when using the Dire
ctX9 renderer,
if your videocard supports certain texture formats (mainstream cards suppo
rt them...)
- Flashing desktop elements and other craps are eliminated. At least they sh
ould be.
- VESA-emu: the wrapper doesn't insist on the resolution and color depth com
ing from
a given VESA mode parameter. If a particular video mode isn't supported by
the
videodriver, it looks up for the best matching available one, converts the
color
format and scales the screen-image as needed (like in windowed mode).
What is more, it chooses the best matching refresh frequeny according to t
he one
given in the setup on VESA tab. It all needed because I had troubles with
VESA emu
under Windows Vista.
Previous versions didn't supported it, and always used 60hz as monitor ref
resh freqency.
Only exceptions are 8 bit modes, they were wrapped to 32 bit because Direc
tX9 doesn't
support so legacy things.
- I think that's all, some other modifications were done as I recall, but th
ey were so
long ago, I can't remember them exactly, and had some beers since then.
IV. Working of, and using the wrapper
-------------------------------------
Back in time, 3Dfx cards were driven via the API called Glide. Newer and newer v
ersion of
Glide came out as it evolved and it existed on several platforms. From viewpoint
of
dgVoodoo, two important and supported platforms are DOS and Windows, and, two im
portant
Glide versions are 2.11 and 2.43.
The driver itself was a library, that was attached either statically or dinamica
lly to
the application using Glide.
- DOS, Glide 2.11, driver: lib linked statically
- DOS, Glide 2.43, driver: glide2x.ovl
- Windows, Glide 2.11, driver: glide.dll
- Windows, Glide 2.43, driver: glide2x.dll
So, it was enough to provide the proper file for the given Glide application (or
others too,
if the driver itself also consisted of additional files) and the application run
. All that Glide
wrappers, like dgVoodoo, do is replace the file(s) mentioned above with one(s) t
hat still implement(s)
the Glide API, but all the Glide calls are converted (wrapped) into OpenGL or Di
rectX calls,
so no need for a real 3Dfx card to run those applications.
But, all this can't be done directly in DOS, since there is no and there have ne
ver been any
OpenGL or DirectX implementation under DOS. It means that DOS driver of dgVoodoo
needs the
Windows driver. The point of the DOS driver is to be a bridge from DOS to Window
s, it passes
all Glide calls from DOS to Windows.
dgVoodoo can realize the communication from DOS to Windows in two ways:
- VDD mode: This is the preferred mode, in all aspects (technical, comfort,
etc.).
In this case the DOS driver automatically finds, starts and uses
the
Windows driver. This mode is only available under WinXP.
- Server mode:
In this case, launching a server application (dgVoodoo.exe) is n
eeded. The server
attaches the Windows driver to itself, and then, DOS driver comm
unicates
with the server. WinXP itself supports communication from DOS to
Windows,
while Win9x/Me doesn't, so, under Win9x/Me the wrapper has to re
alize it
itself (that's why file dgVoodoo.vxd appears here).
So, usage of the wrapper:
For Windows applications, after copying proper files and potential setup (dgVood
ooSetup),
you can run them without doing anything else.
For DOS applications, after copying proper files and setting up the wrapper to w
ork in VDD mode,
you can run them without doing anything else.
For DOS applications, after copying proper files and setting up the wrapper to w
ork in server mode,
you have to launch the server (dgVoodoo.exe) first, and then you can run them.
You can also run DOS programs in the background, but be careful! In certain case
s,
when cooperative level changes (e.g. when a DOS program is being run in full scr
een,
but you changes to an other application), some of the Glide-functions cannot be
called without fail. This means that a game may quit with an error message, etc.
V. VESA emulation
-----------------
dgVoodoo can emulate VESA 2.0 for DOS applications, with minor-major bugs.
Similarly to the Glide emu, VESA emulation can be used in either VDD or server m
ode.
What is more, it needs and uses file glide2x.dll, so that, VESA emu code is
integrated into the Glide 2.43 driver (except for Win9x/Me, because most of the
emu is done by the kernel module (dgVoodoo.vxd) there and only a few parts are c
alled
in the dll, like video refresh via DirectDraw).
[I know that I should have placed the implementation into a dll like dgVesa.dll
or
something like that, but according to the feedbacks I got and experienced, many
people
think that dgVoodoo consists of too many files, and they get confused about the
ir usage.
OK, I thought I won't bugger about with it then, integration made things go eas
ier
as well, as for switching between VESA and Glide modes at runtime. Maybe I will
resolve
it in about 2010, when the DOS part of this wrapper will be unusable not only i
n practice,
but theoretically too, as 64 bit Windows doesn't support 16 bit code.]
VESA emu of dgVoodoo supports all resolutions from 320 x 200 to 1280 x 1024 in
8, 16 and 32 bit color depths. 320 x 200 x 256color is a standard VGA mode, you
can
enable it for emulation.
To use VESA emulation, you will need to run the DOS-driver, dgVesa. Under Win9x/
Me,
when the server is running with VESA emu enabled, it installs DOS driver automat
ically
into each newly opened DOS-box, so in that case using dgVesa is needless.
(DOS driver of VESA emu is for maintaining the contact between DOS and Windows,
like
the DOS driver of Glide.)
VI. Installation
----------------
Important: If you have any of the previous versions installed, overwrite each co
mponent
of dgVoodoo, don't mix them with older version files or with files wi
th the
same names from other software!
Global installation: copy all the needed files to your Windows folder
Local installation: copy all the needed files to the folder of the application/g
ame you
want to play
Installing dgVoodoo to run Windows apps
.......................................
Just copy the following files into the proper folder, depending on you do gl
obal or
local installation:
GLIDE2X.DLL
GLIDE.DLL (in the case you need Glide 2.11 support as well, bu
t take
advice from me, and do local install for Glide2.11)
DGVOODOOSETUP.EXE
After doing this and setup, Windows applications should work.
Installing dgVoodoo to run DOS apps
...................................
Just copy the following files into the proper folder, depending on you do gl
obal or
local installation:
GLIDE2X.DLL
GLIDE2X.OVL
DGVOODOOSETUP.EXE
DGVOODOO.EXE
DGVOODOO.VXD (this file is required under Win9x/Me only, WinXP wo
n't miss it)
DGVESA.COM (if you need VESA emulation)
After doing this and setup, DOS applications can be launched (VDD mode), or
you have to start the server first, and then DOS applications can be launche
d
(server mode).
VII. Running DOS programs under Windows Vista
---------------------------------------------
Unfortunately dgVoodoo isn't completely compatible with Vista, there are some in
convenience
I haven't mop up yet.
Theoretically dgVoodoo can be used with Vista, but only with 32 bit Vista (like
it can be
used only with 32 bit XP), once I reported about it on Vogons:
Two main sucks compared to XP:
- Vista is disposed to load any VDD only from Windows\system32, I think
this is
because of a security-crap or something like that. The point is that k
eep your
Glide2x.dll there if you want to run any DOS stuff. Actually, it's imp
ortant
NOT to have any Glide2x.dll in the folder of DOS app because the DOS d
river
notices it in this case and wants Vista to load that instance. And Vis
ta's
respond is dismissive.
(This behavior should be avoided by some development as well as gettin
g setup to
search for Glide2x.dll instances in Windows\system32.)
You have to do the same with VDMSound, just copy its vddloader.dll int
o System32,
and voila, it works like a charm.
- If the desktop composition (Aero look & feel) is enabled, so that Vist
a is driving
the video card through the new WDDM driver model, then no any kind of
full screen
functionality is available (except via DirectX of course), as this dri
ver model
doesn't support such functionality. So you can neither switch into ful
l screen
text mode, nor into VGA mode, etc. Instead you get a kind message from
Vista saying
"This system doesn't support full screen mode". And the usual choice,
you can ignore
it, or close the renitent application. A common user closes it since h
e/she has no
any idea about it.
The point is that you are forced to use dgVesa with VGA emu enabled. d
gVesa bypasses
this all via DirectX. There's no other way!
I can't say I did many testing around DOS stuffs under Vista, but accordingly to
the facts
listed above, I was managed to run Tomb Raider 1.
VIII. General tips for dgVoodoo
-------------------------------
- Scaling of texture memory means that dgVoodoo reports 4MB total texture memory
to the
application, but effectively it uses as much as it's configured for. It has no
any use
by default, this option was designed expressly for Red Baron 3D because RB has
a bug,
you get texture corruption if it uses more than 4MB memory.
DON'T use it for any other application!!!!
To get perfect working, the application is needed to entrust all texture size
calculation
to the wrapper, because texture sizes are scaled too. If not that is the case,
so that
the application does its own calculations, then texture sizes and scaled textu
re
memory addresses won't be chimed together, and causes texture corruptions. So,
one more,
use this option only with Red Baron 3D, RB3D behaves well enough to make use o
f it.
- If hardware accelerated regenerating of paletted textures is enabled, dgVoodoo
eats up
some extra video memory, exactly as much more as minimally needed. Hw accelera
tion
has use with applications that make the wrapper work hard by altering texture
palettes
continuously. Such ones are e.g. Blood and Red Baron 3D. However, there's no p
oint to
use it with Tomb Raider 1 as its textures are rather static, they don't change
, so
the extra video memory is just wasted.
There's a stupid restriction: you cannot use hw acceleration if you use manage
d textures.
Don't ask why, the implementation would be relatively complicated.
- Don't force your videodriver in any of its settings dialog to apply FSAA if yo
u're
going to use dgVoodoo, or create separate profiles for Glide applications with
FSAA set to
application controlled!! If FSAA is applied, video memory buffers can't be loc
ked and
modified directly which is required by many Glide applications. Of course this
will
cause visual artifacts (missing screen items), or the application terminates a
t once
due to the failed lock. The point is all that looks as if it were the fault of
the
wrapper. But it's not, hehehehehehahahhaa....
- There are no magic options to set, so that if dgVoodoo won't work at all with
default
settings, probably won't work at all with others too. Only exception is maybe
the
difference between VDD- and server-mode.
- DON'T USE the server (dgVoodoo.exe) in compatibility mode (WinXP)!!!!
It messes up the detection of version of the operating system, so the server m
ay think
it's running under Win98.
- When your screen is flashing, try to use the wrapper with "closer to a real ha
rdware"
option enabled. Flashing occures when a game unexpectedly behaviors and the wr
apper
locks the LFB in a very optimalized way (most likely in 16 bit full screen).
- If you start a DOS game, and the glide-window appears, and then nothing happen
s, try
to run that program with unhided console window. It's possible the game exits
with an
error message, but you cannot see anything because the console window is hided
.
- If you want the smoothest animation try to set the refresh frequency to the cl
osest one
to the desired freq (see setup)
- Automatically generated mipmap levels can cause serious artifacts, so it is no
t
recommended to use it in general. Missing levels are generated by resampling t
he
original texture and it means colorkey-pixels are going to be recoloured to
something different color around a given shape. Alpha values can also be modif
ied
in a wrong way if an application uses alpha testing.
Furthermore, when an application refreshes certain textures continuously, spee
d
can be degraded due to calculating all the levels every time.
- Some applications were programmed in a way that it utilizes properties of a re
al
hardware when locks the LFB, so they weren't completely programmed according t
o
the Glide specification (such a program is e. g. Extreme Assault Demo). If you
get "slided"
pixel rows or something similars, try to enable the "closer to a real hardware
"
option of the wrapper. This option does not confuse other programs but eats up
more
memory and provides slower buffercontent caching, so do not use it if not need
ed.
NOTE that this option is automatically enabled when using Glide 2.11 to
keep compatibility with Voodoo1.
- dgVoodoo generates additional timer interrupts when it works in DOS Glide mode
,
so DOS games may seem to be faster than normal. This was brought in earlier, b
ecause
3D rendering could be too time-consuming, taking out much execution time of DO
S, resulting in
losing timer interrupts, so that games slowed down to slowmotion.
Since then, I've improved cooperation of certain threads, so this problem may
not take place
now (I hope, at least).
Previous versions (like 1.31) generated one timer interrupt after each 15ms, n
ow this version do
that after each 80ms by default (from 1.40+, it's been changed to 80ms from 40
ms of 1.40).
Time of period was a hidden option in all of the previous versions. Since game
s can be faster
than normal, if you want, now you can turn off timer boosting in the setup, or
can set to the
aforementioned 80ms. (It's a limited choice, since it could be set to other va
lues too, but
I'm far from happy to make this option public at all).
- I think all of Glide 2.11 DOS-applications have their Glide libraries statical
ly
linked (according to the Glide 2.11 SDK). However file glide.ovl could only be
usable by dynamic
linking. I myself don't know of any program using it in this way. That's why t
his file exists
but isn't included in this version.
- Focus problem (Win9x/Me):
If serverproc loses the focus, it suspends the served DOS box and wakes it up
when it gets
back the focus. In some cases the serverproc gets the focus but Windows does n
ot send
any message about it (or I coded it nastily) so you have to inactivate and rea
ctivate the
window of the server manually. In full screen, you can do it by moving the inv
isible mouse
cursor to the edge of the screen and resize the window (when mouse focus is no
t set to
the DOS-box).
In certain cases it can be very annoying that mouse focus is set to the DOS bo
x.
For example, when you run the program in windowed mode, you can't resize the w
indow
severely. However, if Ctrl-Alt is pressed, mouse focus is released from the DO
S box.
If you click on the window, it gets back the focus.
IX. Differences between DirectX7 and DirectX9 renderers
-------------------------------------------------------
One may think that DX9 can only be better. Generally speaking, maybe it's true b
ut unfortunately
DX7 has some advantages been removed by MS in the later interfaces (e.g. killing
DirectDraw
completely in DX8...)
Note that DirectX 9.0c or greater installed is required to use the DX9 renderer,
the wrapper
won't access the API via earlier versions!!
Advantages of DirectX9:
- Pixel shaders. This renderer uses pixel shaders of version 1.4 in order to
emulate the 3dfx
pipeline almost completely. With shaders, renderer can reach greater accur
acy in its internal
calculations (so that it can avoid saturation between texture stages prese
nt in
fixed function shaders), and can emulate the 3dfx pipeline almost perfectl
y
(texture combine -> chroma keying -> alphaControlITRgbLingthing -> alpha/c
olor combine).
FF shaders can only do it partially and with constraints. Pixel shaders of
version 1.4
are needed because of chroma keying, it couldn't be solved with earlier ve
rsion pixel shaders.
If your card doesn't support pixel shaders v1.4, DX9 renderer can still fa
ll back to
FF shaders, but using the DX7 renderer instead is highly recommended in th
is case.
GeForce Fx Series and Radeon 8500 both have support for pixel shaders of v
1.4.
- Alpha based colorkeying doesn't rely on alpha testing and blending at all,
can't conflict
with any other effect, so it can be used under arbitrary circumstances. Na
tive colorkeying
works in a well defined way, so the result doesn't depend on the video dri
ver.
- Using vertex and index buffers more efficiently. Using hardware vertex buf
fers
(which also applies to index buffers in DX9 renderer) is stoutly recommend
ed (as opposed to DX7
as you'd better not use it with that accordinging to the experiences), it
seems to work much
nicer than in DX7 probably due to the buffer renaming techinque done inter
nally in DX9.
In fact, buffer renaming is a double buffering techinque done transparentl
y to the application
which is missing in DX7 and the wrapper itself doesn't implement it.
Disadvantages of DirectX9:
- When DX9 renderer falls back to FF shaders it cannot emulate native colork
eying. This also
affects lfb access with texture tiles, so DX9 with FF shaders can prove to
be unusable in
most cases. Old cards with FF-only support should use the DX7 renderer. FF
support in DX9
renderer is going to be removed in future versions.
- Generally, accessing the Lfb is mostly done by texture tiles with nondefau
lt resolutions because
Direc3D9 supports only a simple buffer blitting.
- Front buffer is inaccessible. This doesn't matter at all for most of the a
pplications, but
for the sake of possibility, DX9 renderer can be switched into a special w
orking mode with its
own administration of the render buffers, always doing copying between the
m.
In this mode front buffer is accessible but slight performance penalty can
take on, that's why
it is disabled by default. (It has an annoying side effect: when the front
buffer is inaccessible,
you cannot take screenshots because they are saved as the content of the f
ront buffer...)
- With full screen only, buffer switching interval can't be affected per swi
tch, but only at init
(so that, bufferswitching with sync to vertical retrace or immediate buffe
rswitch).
Thus, DX9 renderer always syncs it to the vertical retrace, but it can be
forced to immediate
bufferswaps if needed.
- Lack of paletted textures (in practice). GeForces up to FX series supports
them by hardware but
their drivers seem not to expose this capability via the DX9 interfaces fo
r some reasons (I have
some tips why not, but...), so I couldn't even test it in this renderer. S
ince I didn't want to
put dead and untested code in the wrapper, DX9 renderer always disables pa
letted texture support
independently on the driver capabilites.
- Full screen 8 bit VESA modes are always emulated by using 32 bit screen mo
des because D3D9 is all
about 3D. It cannot be driven through 8 bit modes.
Colorkeying with DirectX7:
- Native: General colorkeying method using the native colorkeying of cards
- Native for TNTs:
This method is a special alpha based colorkeying for TNT cards only
(TNTs implement their cking on an alpha based conception,
working under special circumstances only)
- Alpha based:
General colorkeying method using alpha testing and
mask textures as alpha channels
- Automatic:
It always forces alpha based colorkeying by default, but if it
won't work due to either lack of enough videomemory or constraints
of
alpha based method, then it falls back to native colorkeying.
Alpha based colorkeying is the closest to the real Glide-colorkeying
and it should give the same results on every video card, that's why automati
c
method always forces this by default.
Disadvantages: this method cannot provide colorkeying at all if alpha testin
g
is enabled in special modes and also, wrong results may be produced if speci
al
alpha blending modes are used.
Colorkeying with DirectX9:
- Native: Can only be used with pixel shaders, and works according to the de
finitions
in 3dfx's documentations.
- Native for TNTs:
It makes no sense here, so it's equivalent to the plain native met
hod.
- Alpha based:
It uses the alpha components of separate mask textures to decide w
hat
pixels to reject like in DX7 but this functionality is moved to pi
xel
shaders from the alpha testing/blending level.
- Automatic:
It always prefers native method to alpha based by default. However
, native
has one issue worth to deal with: if precision loss occures becaus
e of a
texture conversion (e.g. when 16 bit textures are forced then 8 bi
t paletted
3dfx textures are converted to 16 bit too, so 32 bit color values
have to be
stumped), then not only pixels matching the colorkey will be rejec
ted but
all ones in a certain, small interval around the colorkey in the c
olorspace.
Automatic method tries to avoid that case.
With FF shaders, automatic always uses alpha based method.
FF shaders has the same constraints as with DX7 renderer.

X. Technical notes (you can skip this section)
----------------------------------------------
Glide LFB locking
.................
- Option "closer to a real hardware" is automatically enabled when Glide 2.1
1 is used,
because of maintaining the Voodoo1-compatibility. It means that stride (AK
A pitch or logical
line length) for LFB operations is always 2048 bytes, and read/write point
ers to buffers
are "constant" (for particular formats).
- A hidden option, "No matching LFB formats" are also automatically enabled
for
Glide 2.11 to avoid buffer pointer mismatch problem. In fact, this prevent
dgVoodoo
from using directly any of its internal optimized buffers in order to read
/write pointers of
a particular buffer always do point to a certain memory area (this is impo
rtant in Glide 2.11).
- "No matching formats" is also enabled when you use the wrapper for DOS pro
grams under WinXP
in server mode. This is because matching lfb formats means using directly
one of the
internal buffers residing in the video memory. Thus, the DOS program and
the locked buffer
would be in separate address spaces. Note that when "no matching formats"
is enabled, there is
no extra conversion from the format to the same format, just a raw copy i
s done.
DOS Glide
.........
- In VDD mode, the wrapper file (glide2x.dll) is attached directly to the
NTVDM process running the DOS program as a VDD (Virtual Device Driver). Yo
u can
avoid running the serverprocess, the application and the wrapper share the
same
process and address space like in case of Windows applications. Also, more
than one
applications can use the wrapper simultaneously.
- Disadvantages of server mode under WinXP: Since the application and the wr
apper run
as two separated processes in separate address spaces, dgVoodoo can't util
ize matching
LFB formats (it considers them as if they were always different), server c
an serve only
one DOS program.
You should try this mode if you have troubles with VDD mode.
VESA Emu
........
- dgVoodoo reports VGA-compatibility altough its compatibility is restricted
to the palette registers and the vertical blank (3DA) register.
It means X mode cannot be emulated, etc.
(But, this project is not about developing VESA to the perfectness...)
- Linear/Flat Frame Buffer mode is not supported under Windows Xp.
- Under Windows 98/Me, Bank Switching is done by changing the actual memory
mapping
in kernel mode. However it is beyond the possibilities under Windows XP, s
o copying
large 64K memory blocks is needed there. Thus, it is slower than W98/Me im
plementation.
- Win9x/Me only: If you use dgVoodoo for VESA in a DOS box, then you stop it
and use the original driver, you will probably see a messy screen. This is
because
dgVoodoo overwrites the memory mapping for videomemory set up by VDD
(Virtual Display Driver) and cannot fully restore it. In this case close
that DOS box and use another.
- Win9x/Me only: VESA init can fail when starting the server.
The memory area used as videomemory is allocated when kernel module is loa
ded into
the kernel. (When it is unloaded, this memory area is released.) Normally
the kernel
module behaves as a dynamic VXD. It means it is loaded and unloaded to/fro
m
kernel by the serverproc. The main problem is the videomemory has to be
physically continuous but Windows cannot provide it if bulk of the
physical pages are messy-allocated for running applications.
If you want, you can insert the following line in SYSTEM.INI into the
[386Enh] section:
device = dgVoodoo.vxd
In this case kernel module is used as a static VXD, so it is loaded into
the kernel during Windows startup. It reserves 2MB as videomemory (because
it cannot read the current configuration) and releases it when Windows shu
ts down.
XI. Resolution setting
----------------------
If an application does not allow you to set the required resolution you can
do it by dgVoodoo. However keep in mind that this can not only cause graphical
artifacts, but the wrapper even has to work harder in the background in such a c
ase,
mainly when the application is using direct Lfb-access, so it all can have a ser
ious
overhead.
So, that's why do use nondefault resolution only when it cannot be set via the a
pplication
itself.
You can use all of the resolutions supported by your video card.
XII. Screen shots
-----------------
You can save the content of the screen into a file or to the clipboard.
You can do it by pressing the "Pause" button in case of Windows apps and DOS in
XP,
and "Scroll Lock" for Win9x/Me DOS. I know it should be done by the same button
for
all platforms but I cannot solve it (temporarily). Result of the saving
operation can be seen on a green label in the middle of the screen except when
you are in an 8 bit full screen mode (VESA) because the label cannot be drawn by
the
3D hardware.
If the screen is saved into a file, the name of the saved file is the same as
the application's concatenated by an ordinal number. It is saved to the "Temp"
directory on the same drive where the application is. If the name of the
application is unknown (only in DOS) then filename is
C:\Temp\dgVoodoo_xyz_.bmp where _xyz_ is an ordinal number.
The saved file is 8 bit (full screen, VESA), 16 or 32 bit depending on what
the bit depth of the used videomode is. The saved file is always saved as
a BMP file and dgVoodoo is not intended to support any other format in the
future. Just save the screen then convert it to whatever you want.
XIII. Using dgVoodooSetup (GUI)
-------------------------------
dgVoodoo does not have a configuation file from which it reads the actual
settings. Settings are stored in GLIDE2X.DLL and GLIDE.DLL instead.
The setup program needs these file as well.
Setup program organizes setup options on three main tabpages and one hidden tabp
age.
Page "Global": Options that affects both the Glide and VESA emula
tion
Page "Glide": Contains options for Glide
Page "VESA": Contains option for VESA
page "Renderer specific": Specific options for both renderers
(can be made unhidden from context menu)
Let's have a look at the setup-dialog:
Platform
Here you can select the Win or DOS platform to configure.
Language / Nyelv
You can select a language to setup in, and which the wrapper itself uses
.
Instance of dgVoodoo
In this list you can see the names of wrapper files to be configured.
By default, setup searches for such files in the current directory, but
if none is found, it does it in Windows directory. You can add additiona
l
wrapper files to the list by "Search" button.
"Win dir" and "./" button adds files from Windows and current directory
if any is found there.
Below this field, you can see the actual page. You can select between pages by t
he tabs.
Page "Global"
-------------
Renderer API
You can choose between DirectX7 and DirectX9 renderers.
Display device
You can select a screen adapter to use.
Display driver
You can select which rendering driver to use.
(dgVoodoo will probably work unproperly with software drivers, but I
think that's not a big pain. :) )
Screen mode
You can select between full screen and windowed mode.
Screen bit depth
You can set the bit depth of full screen mode.
In windowed mode bit depth is determined by the
actual settings of the desktop. These settings can be seen
above the tabs. If it is not compatible with
dgVoodoo (so that it is not a 16 or 32 bit mode), you will
be warned.
16 bit mode can be useful for fast LFB accesses.
Enable screen shots
You can enable the screen saving here.
Saving to file
You can enable saving to file here.
Saving to the clipboard
You can enable saving to the clipboard here.
Working in VDD mode
Only for DOS under WinXP: you can set VDD mode here.
Active in background
Only for DOS under WinXP: by enabling this option, DOS programs
runs in the background too.
Hide console
Only for DOS: Hides the console window of the application.
Set mouse focus to application
Only for DOS: If application is running, mouse focus is set
to the application. You can use the mouse by enabling this
option.
Enable Ctrl-Alt
If enabled, you can release the mouse focus from DOS box by this
key combination.
Always preserve window size
Only for DOS, in windowed mode: if you resize the window, further
mode switchings (e.g. between VESA and Glide) won't resize the
window to the default size when a new resolution is applied.

Preserve aspect ratio
Preserves aspect ratio of the window during sizing.
Page "Glide"
------------
DirectX textures bit depth
Bit depth of textures used in Direct3D. dgVoodoo can use the
following texture formats (arbitrary component order):
- 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
At startup, it puts all the texture formats supported by your ca
rd
into a list. When dgVoodoo has to decide which format to use for
a
particular 3Dfx format (best fit) it selects it from the list.
Options meaning:
- 16 bit: select from only 16 bit formats
- 32 bit: select from only 32 bit formats
- Optimal: select from any format including paletted
(8 bit) textures
Refresh rate
- Monitor freq is the closest supported freq:
Only with usage of full screen, it sets the effective refresh f
requency
to one of the supported values by the monitor that is closest t
o the one
application requires. In practice they will probably be equal s
ince most
of the Glide applications use 60Hz (or 70, 72), which must be s
upported
by even a crappy monitor.
Of course this option overrides the value set in "Monitor freq"
option.
Recommended for perfect emulation and smoothest animation!!
[The other old option, with which application-given freq could
be emulated
at arbitrary effective refresh freq, has been removed, I didn'
t have a
good mind to deal with it while reimplementing the base of DX7
renderer.
I don't think anybody used it at all, it's only use perhaps wa
s keeping
one's eyes in its sockets by using a high refresh freq while i
t could be
virtually capped to a lower value. :)]
- Always wait for vertical sync:
Waits for at least one vertical retracing even if an applicatio
n doesn't
demand it. It can be useful for applications not synchronizing
themselves
to the refreshing ending in running too fast on modern computer
s,
or rendering artifacts such as horizontal refresh-lines.
Note that this options has no effect with DX9 renderer!!
Use the renderer specific option for it to control globally thi
s behavior!
LFB access
- Disable LFB access (read, write)
Accessing the LFB can be a slow operation.
If you disable an access with a certain type in this com
bo box,
applications still have the sense they access the LFB bu
t in fact
they access an unused buffer instead. Because of it the
rendering
may not be complete (and can be bad if reading is disabl
ed) but
the application can run at max speed.
- Use hardware cache buffers when possible
Keep this option enabled

- Use fastwrite for unmatching formats
Keep this option enabled
- Disable texture tiles
The wrapper decides if texture tiles are needed or not a
ccording to
the current circumstances, by default. If you find its d
ecisions
not too optimal and/or texture tiling is just causes per
formance loss
or artifacts, disable it all by this options causing a f
allback to
plain buffer blitting.
- Closer to a real hardware
LFB has such properties that are closer to the LFB prope
rties
of a real Voodoo card
Note: if an application tries to read/write the aux buffer when
it
is used as a depth or alpha buffer, then it will always manipula
te
the unused buffer (locking depth and alpha buffers are not imple
mented
yet :-| ).
Resolution
You can override the the resolution of an application here.
This list contains all the supported resolutions.
Refresh rate
You can set the refresh freq of your monitor here.
You cannot do it if you use the wrapper in windowed mode or moni
tor freq
is set to the closest supported one.

Texture memory size
Size of the emulated texture memory.
Disable mipmapping
If you don't like mipmapping in a game, you can disable it, fall
ing back
to using only the first mipmap of textures.
Force trilinear mipmapping
Interpolating between the levels of mipmaps
Autogenerate mipmaps
If a mipmap consists of only one level, missing levels are gener
ated.
This option does not override multilevel mipmaps.
Force bilinear filtering
You can force textures to be always blurred.
Texmem scaled to 4MB
You can enable texture memory to be 4MB virtually.
For more info, see general tips.
Gamma correction
You can set the gamma correction between 0% and 400%.
This also works in windowed mode!
Colorkeying method
Colorkeying is the effect when pixels that matches the colorkey
are not rendered.

You can select between four methods for colokeying:
- Native
- Native for TNTs
- Alpha based
- Automatic
See chapter describing differences between renderers for
details.
Force triple buffering
You can force the wrapper to always use three buffers for animat
ion. This can
speed up things, but also can produce wrong appearance if the ap
plication uses
the content of previous frames.
Fix TR's shadow-problem
You can avoid the no-shadow problem in Tomb Raider 1.
Don't use this option if it confuses other Dos-programs.
Enable using hardware vertex buffers
If this option enabled, dgVoodoo puts all the geometry data dire
ctly into the
hardware buffer of the video card, avoiding extra copies. Howeve
r this also can cause
problems, so I let you disable it.

Force W-buffering
You can force true W-buffering if your video card supports it (o
ld ATI cards,
and pre-GeForce 6xxx series).

Timer boosting
Turning on and off timer boosting, for more see section "General
Tips".
Page "VESA"
----------
This page is used only for DOS.
Use built-in VESA support
You can enable the VESA emulation.
Refresh frequency
Refresh freq. You can get smooth animations at higher freqs, but
be
careful: refreshing the screen is time-consuming so the higher t
he
freq the more time is spent on refreshing, the less time is left
for the program for running.
(This text is rather old, so it can be a problem only with ancie
nt
hardware.)
Emulated video memory
Size of the video memory (see related problems).
Size of mem should not be smaller than a particular video mode r
equires.
Mode 13h support
You can enable emulating the standard 320x200 256 color VGA-mode
.
Disable Flat/Linear Frame Buffer Modes (Win9x/Me)
Since implementation of the VESA emu is far from perfect, some p
rograms
may not work in linear mode. So, disable it to force the program
to
use good old bank switching VESA technique.
"Renderer specific"
-------------------
DirectX9
- Force swap chain copy (accessible front buffer)
It is only for making the front buffer accessible, doesn't worth
to
keep it enabled all the time because it can decay performance.
- No vertical sync at bufferswap
Forces immediate bufferswap. Some applications require this beha
vior,
you can force it only with this option for DirectX9.
- Force fixed function shaders
Mostly for testing DX9 renderer without pixel shaders.
- Enable hw accelerated regenerating of paletted textures, if available
It speaks for itself, but can only be used with pixel shaders.
- Try Black&White rendering
It's a kind of Easter egg, renders in grayscale if your hw has e
nough
support. It can only be used with pixel shaders.
You can save your settings by pressing button "OK", while "Cancel" quits
without saving. Button "About" is the usual unusable one that makes a feeling of
a
serious application.
XIV. Using dgVoodooSetup (Command Line, advanced)
-------------------------------------------------
If command line of dgVoodooSetup is not empty, GUI interface does not pop up,
information for setup operations are taken from the command line. No any feedbac
k
on the console. (Damn, an application can't be both a GUI and Console applicatio
n
under Windows, at least not in an easy way.)
This is useful for using the setup in command line scripts.
You can model the GUI workflow, which is usually the following:
- configuration is loaded from either the wrapper file (glide2x.dll, glide.dll),
or from an exported config file
- some config changes are applied if needed
- configuration is either saved in the wrapper file, or exported to external con
fig
file, or both
Command line options:
dgVoodooSetup [wrapperfile] [/opt1] ... [/optn]
where wrapperfile can be:
File Specified file
$Win$[File]|[:0|1|2] $Win$ prefix is changed to Windows directory
if File is specified, appended to Win dir

$FirstFound$[:0|1|2] directory where wrapper file is first found
1 = glide.dll, 2 = glide2x.dll, 0 = any of t
hem
default = 0
where options:
(E/D = Enable/Disable)
(Dec = decimal number)
(Hex = hexadecimal number prefixed by 'x' or '0x')
(Default of boolean operations (On|Off|Inv) = On)
options for operations

/?, /h, /help Help for command line options

/NoSave Does not save config in wrapper file
/Import:configfile Load config from configfile, mandatory param
eter
/Export:configfile Save config in configfile, mandatory paramet
er
/ExportToText:textfile Export config into textfile, mandatory param
eter
/Platform[:Win|Dos] Load appropriate platform config, default =
Win
/Lang[:Eng|Hun] Language, default = Eng
options modifying config:
/Windowed[:On|Off|Inv] E/D windowed mode.
/BitDepth[:16|32] Color buffer bit depth in full scr mode.
Default: 16
/ScrShot[:On|Off|Inv] E/D screen shots.
/ScrShotToCb[:On|Off|Inv] E/D screen shots going to clipboard
/VDDMode[:On|Off|Inv] E/D VDD mode
/RunInBkgnd[:On|Off|Inv] E/D running in background
/CLIPOPF[:On|Off|Inv] Force handling CLI/POPF (XP)
/HideConsole[:On|Off|Inv] Hide/Show console window
/Mouse[:On|Off|Inv] E/D setting mouse focus to Dos
/MouseCtrlAlt[:On|Off|Inv] E/D Ctrl-Alt to release mouse focus
/PreWinSize[:On|Off|Inv] E/D Preserving window size
/PreWinAspRat[:On|Off|Inv] E/D Preserving window aspect ratio
/MonFreq[:Hex|Dec] Monitor freq, 0 = default freq, default = 0
/ClosestMonFreq[:On|Off|Inv] E/D Setting the closest supported monitor
freq to the one that app requires,
overrides MonFreq setting
/WaitOneRetrace[:On|Off|Inv] E/D waiting for at least one retrace
/TextureBitDepth[:0|16|32] Bit depth of D3D textures, 0 = optimal,
default = 0
/PerfectTexEmu[:On|Off|Inv] E/D perfect texture memory emu
/StoreTexCopies[:On|Off|Inv] E/D storing texture copies
/DisableMipMap[:On|Off|Inv] E/D mipmapping
/ForceTriMipMap[:On|Off|Inv] E/D forcing trilinear mipmapping
/AutoGenMipmap[:On|Off|Inv] E/D autogenerating mipmap levels
/ManagedTextures[:On|Off|Inv] E/D managed textures: textures are handled a
nd
recovered by DirectX runtime if needed
/TexMemScaleTo4M[:On|Off|Inv] E/D scaling texture memory to 4MB
/LfbAccess[:Enable|Disable|DisableRead|DisableWrite]
Setting LFB acessibility, default = Enable
/HwCacheBuffs[:On|Off|Inv] E/D hardware cache buffers
/FastWriteUnmatch[:On|Off|Inv] E/D fastwriting for unmatching formats
/FastWriteMatch[:On|Off|Inv] E/D fastwriting for matching formats
/ColorFmtOnLfbFmt[:On|Off|Inv] E/D Lfb read/write format affected by color
format
/RescaleChangesOnly[:On|Off|Inv]E/D rescaling only lfb changes at write
/FlushAtUnlock[:On|Off|Inv] E/D always flushing lfb changes when unlocki
ng
/NoMatchingFmt[:On|Off|Inv] E/D no matching lfb formats
/TextureTiles[:Auto|Disabled|Forced]
Method for applying texture tiles
default = Auto
/LfbRealHw[:On|Off|Inv] E/D closer to a real hardware
/CKMethod[:Auto|Alpha|Native|NativeTNT]
Setting colorkeying method, default = Auto
/CKTntInFallback[:On|Off|Inv] E/D using native TNT method when fallback in
auto
/AlphaRef[:Hex|Dec] Alpha reference value for auto ck mode,
range: 0-255, default = 0
/TexMemSize[:Hex|Dec] Texture memory size in kB, default = 8192
/XRes[:Hex|Dec] Overrided horizontal resolution
/YRes[:Hex|Dec] Overrided vertical resolution
(X=0 and Y=0 means resolution required by ap
p)

/Gamma[:Hex|Dec] Gamma correction in percents,
range: 0-400, default = 100
/ForceTriBuff[:On|Off|Inv] E/D forcing triple buffering
/FixTR1[:On|Off|Inv] E/D fixing shadow bug in TR1
/ClipByD3D[:On|Off|Inv] E/D geometry clipping by Direct3D
/GlideGamma[:On|Off|Inv] E/D Glide gamma ramp
/HwVertexBuff[:On|Off|Inv] E/D hardware vertex buffers
/WBuffDetMethod[:ForceZ|ForceW|DriverFlag]
Setting W-buff emulation detection method,
def = DriverFlag
/DepthColorEq[:On|Off|Inv] E/D setting bit depth of depth buffer to the
same
as color buffer
/ForceIndexed[:On|Off|Inv] E/D forcing indexed primitives
/PreferTMUW[:On|Off|Inv] E/D preferring W of TMU when needed
/TimerBoost[:Hex|Dec] Timer boost period time in ms for DOS
0 = boosting disabled, default = 80
/Vesa[:On|Off|Inv] E/D built-in VESA support
/VesaRefRate[:Hex|Dec] VESA refresh rate in Hz, range: 45-70,
default = 50
/VesaMem[:Hex|Dec] VESA videomemory in kB, default = 1024
/Supp13[:On|Off|Inv] E/D VGA mode 0x13 (320x200x8)
/DisableFlat[:On|Off|Inv] E/D Flat/Linear VESA modes
/MirrorVert[:On|Off|Inv] E/D mirroring the screen vertically
options only for DX9
/DX9LfbCopy[:On|Off|Inv] E/D copying in lfb chain, accessible front b
uffer
/DX9NoVRetrace[:On|Off|Inv] E/D immediate bufferswap
/DX9FFShaders[:On|Off|Inv] E/D forcing FF shaders
/Dx9HwPalTextures[:On|Off|Inv] E/D Hw accelerated regenerating of paletted
textures
/DX9BlackWhite[:On|Off|Inv] E/D grayscale rendering
Configuration is loaded from the wrapper file, but /Import option overrides it i
f
specified. If neither wrapper file nor external config file is specified then
default config is used. Then, all config modifications are done, and config is
saved in wrapper file if /NoSave is not specified, and, it will be saved into an
external config file if /Export is used. Also, it will be exported into a text f
ile
if /ExportToText is present.
If an option has a parameter, it is separated by a colon. If a parameter is not
mandatory
and not specified, then default parameter is used.
In case of syntax error or unrecognized options, nothing is done.
Command line options are case insensitive.
Examples:
dgVoodooSetup $FirstFound$:2 /Platform:Dos /Windowed:On
Searches for the glide2x.dll file (current dir and Win dir), loads the DOS c
onfig,
sets windowed mode, then saves the config.
dgVoodooSetup $Win$Glide2x.dll /Platform:win /CKMethod /Export:MyConfig.cfg
Searches for the glide2x.dll file in Win dir, loads the Win config,
sets colorkeying method to automatic, then saves the config and also exports
it
to MyConfig.cfg.
dgVoodooSetup /Platform:win /LfbAccess:DisableRead /ExportToText:MyConfig.tx
t
Takes the default config, disables lfb access for read, then exports it to
MyConfig.txt text file.
Remarks:
$Win$:1 is the same as $Win$glide.dll, and $Win$:2 is the same as $Win$glide
2x.dll.

$Win$:0 (or just $Win$) searches for glide2x.dll in Windows dir, and, if it
is not found
it searches for glide.dll
$FirstFound$:0 (or just $FirstFound$) searches for glide2x.dll or glide.dll
in current dir and
Windows dir.
Search order is:
current_dir\glide2x.dll
current_dir\glide.dll
Win_dir\glide2x.dll
Win_dir\glide.dll
as done in GUI.
I hope it is really gruesome, enjoy! :)