dgVoodoo 2.64: Glide and DirectX API libraries implemented on D3D11
Released: June 17, 2020
Author: Dege

Copyright (c) 2013-2020

Table of contents

1. Redistribution rights
2. Features
3. Requirements
4. Test results
5. Usage
6. Configuring
7. Resolution overriding
8. General options
9. General additional options
10. General tips and known issues
11. Special release version with debug layer
12. Change log


1. Redistribution rights

Files of dgVoodoo can be redistributed freely as far as they are kept together, remain unmodified and unrenamed. Namely, only the full package can be redistributed in the form as it is!

If you would like to utilize them in publicly available custom solutions or packages, like game patches or anything else, then PLEASE ask me for permission, furthermore mention its original source in your package along with the following download link:


Official dgVoodoo forum where you can contact me and the dgVoodoo community is at:


Tip: See topic "WIP versions" for checking out new dgVoodoo versions that are not officially released.

---------------------- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ----------------------

Very BIG THANKS must go to the community of Vogons for helping me a lot in testing during the development! Thanks Guys, I couldn't have proceed so far without such a great quality assurance!

And I append a new sentence here to emphasize it again, especially for testing my D3D8/9 implementation and supplying me with ideas, tips and various informations on several games!!!

---------------------- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ----------------------

2. Features

dgVoodoo 2 is a set of old graphics API's implemented for Windows Vista/7/8/10.

They are implemented on Direct3D 11 and they can use different device types as wrapping output:

The following graphics API libraries are implemented:

For both Glide and DirectX, dgVoodoo pushes as many emulation work to the GPU as possbile. Thus, the entire internal 3Dfx GPU logic is mapped to pixel shaders for Glide emulation, and all the fixed function vertex & pixel processing pipeline is implemented by shaders for DirectX emulation (when possible).
Glide libraries basically can work in two ways:

If dynamic shader compiling is available (see Usage) then dgVoodoo can work with specialized shaders requiring much less GPU power, providing much better performance, especially on weaker video cards.

3. Requirements

Optional and recommended:

4. Test results

We can examine this in two aspects:

5. Usage

There is no installer for dgVoodoo beacuse you can copy its dlls anywhere you want (to use). If u like it and want to use as the only global Glide wrapper on your machine then copy Glide dlls to the system folder. Glide dlls are available in both 32bit (x86) and 64bit (x64) versions. x64 version is for 64 bit QEmu (and maybe 64 bit DosBox) builds. For native usage you always need the 32bit (x86) version dlls.
For DirectX emulation only a local installation is possible since the DirectX dlls CANNOT be copied to the system folder (see DirectX readme). Also, D3D9 has both 32 and 64 bit versions. Always use the proper one, depending on the application type (not the OS type).

A Glide wrapped application can start up either in windowed or full screen mode (it is controlled by the Control Panel, see later). Also, you can switch between them during the gameplay by Alt-Enter. See 'Known issues' for more.

The same is true for wrapped DirectX applications, but it is a more complicated case, see DirectX readme.

Glide and DirectX dlls can co-work inside a process so the same versions of them have to be used within a folder. If one of them detects the other with different version then it refuses to initialize and work. Co-work is useful for applications that use DirectDraw for some initial in-game menu and Glide for 3D rendering.

If you use dgVoodoo on Windows 10 then dynamic shader compiling is automatically available because D3DCompiler_47 is part of the operating system.
For preceding Windows versions (Vista, 7, 8) you need to download it manually and then, you can copy this dll into each game folder next to the wrapper dlls but the best practice is to copy it into

if it is not already there by the result of the installation of some other software.
Note that dgVoodoo supports both D3DCompiler_43 and D3DCompiler_47. _43 is supported only because of compatibility with users having it downloaded and copied into their system folder previously.

Utilizing dynamic shader compiling is only recommended for Glide libraries (unlike with previous dgVoodoo versions). DirectX implementations have their own internal DXBC generator which proved to be good enough so support for the external compiler has been removed. (I would like to completely ditch the external compiler once the internal code generator is implemented for Glide as well.)

6. Configuring

As different options might wanted to be used for particular applications, I kept the concept of local/global configurations (might be familiar from old dgVoodoo). Current configuration is stored in a file named 'dgVoodoo.conf'. Its format can either be binary or a textual INI-file for manual editing.

When the Glide or DirectX wrapped application starts, dgVoodoo tries to read config data. The search paths and the order for the config file are the following:

If the config file can be found in none of them then the default config is used.

For modifying config files, you can either use dgVoodoo Control Panel (dgVoodooCpl) or edit it manually with a text editor. dgVoodooCPL provides convenient GUI interface for all options but only the most important sections are available by default. You have to enable the advanced options through the context menu. This is because of emphasizing the sufficiency of the default sections for the everyday usage and leaving the advanced sections for practiced users knowing what they are doing.
In dgVoodooCpl you can choose a folder where you can load (from) and save the current configuration. Once you chose a folder, it remains in the list permanently. If the CPL application finds a valid config file in its own folder (where the app itself is located) then it automatically places the folder into the list and selects the folder. Otherwise the user's application data folder is selected, by default.

Note that

If an application tolerates losing focus without closing/minimizing itself, you can configure it dynamically: when the CPL starts up it builds a list of detected running Glide/DirectX wrapped applications and insert it into the folder selector combobox. When you select such a running instance then the current state of the application is read as config and most of the options can also be changed. So, you can set resolution, msaa, brightness, etc on the spot without restarting the application (configurable items depend on emulation type). When an option changes, it takes effect at once. If the dialog gets cancelled or an other config folder/instance is selected, all the changes gets cancelled as well.

You can always use the 'Apply' button to save the current config to the selected folder or running application without exiting the CPL application. Important to note:

A folder inserted formerly into the list can be removed. Also, list of the running instances can be refreshed.

7. Resolution and refresh rate overriding

You can override the application resolution and refresh rate both for Glide and DirectX rendering.
There are three types of resolution overriding, and, the 'Resolution' comboboxes contain two types of elements in the enumerated list:

If you are terribly interested in how the current dynamic resolution is calculated then a little technical part comes here. Otherwise you can skip this section.

D:desktop resolution
F:FullHD resolution (1920x1080)
Q:QHD resolution (2560x1440)
A:application resolution
AS (x, y):stretched from x to y, with aspect ratio
IAS (x, y):stretched from x to y, with aspect ratio, integer scale factor

Unspecified Centered Stretched Stretch with AR
Max AS (A, D) AS (A, D) D AS (A, D)
Max ISF IAS (A, D) IAS (A, D) * remarks IAS (A, D)
Max FHD AS (A, min (D,F)) AS (A, min (D,F)) min (D,F) AS (A, min (D,F))
Max FHD ISF IAS (A, min (D,F)) IAS (A, min (D,F)) * remarks IAS (A, min (D,F))
Max QHD AS (A, min (D,Q)) AS (A, min (D,Q)) min (Q,F) AS (A, min (D,Q))
Max QHD ISF IAS (A, min (D,Q)) IAS (A, min (D,Q)) * remarks IAS (A, min (D,Q))


I'd like to say some words about what happens on multimonitor systems with dynamic resolution forcing:

8. General options

Options on the General tab affects all wrapped APIs, that is, currently Glide and DirectX.

9. General additional options

10. General tips and known issues

11. Special release version with debug layer

Special release version of dgVoodoo contains an additional validator and report layer. Its purpose is dgVoodoo currently has 2 main types for debug feedback

Messages and tracing are independent on each other. Tracing is mainly for devs, for quick and average usage only the messages are recommended.
All of them are written to the debug output, logging to file is not yet implemented.

So, I recommend you to use DebugView or much more DebugView++. They are very cool applications for cases when no any debugger is available. Also, if you have more than one monitors then you can watch the log in realtime: put DebugView++ on one display and run the game on another.

Messages have a '[dgVoodoo]' prefix so the best way to check out a game with dgVoodoo's debug layer is enabling filtering to the 'dgVoodoo' substring (Crtl-L in DebugView and F5 in DebugView++). Every single log output appear in new lines in DebugView/DebugView++ - this is nice, except for some tracing messages written to the output part by part, like D3D8 disassembled shaders. Unfortunately they appear nastily because of that.

It's not really a big problem however because I cannot recommend you to enable tracing. It's much more intended for developers but if you want to use it after all then do it with DebugView++ or a debugger like Visual Studio 2015 because feedback is so tremendous that only tools with asynchronous debug output window are able to handle it. Tools with synchronous debug output like DebugView won't be able to keep up with it and make your game/app crawl at speed near zero.

I must emphasize:

12. Change log

Have luck,