Readme

dgVoodoo 2.82.5: Glide and DirectX API libraries implemented on D3D11/12

Released: Apr 16, 2024
Author: Dege

Copyright (c) 2013-2024

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. Direct3D 12
• 11. ARM64/ARM64X builds
• 12. General tips and known issues
• 13. Special release version with debug layer
• 14. 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:

http://dege.fw.hu/

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

dgVoodoo forum on Vogons

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

dgVoodoo2 is a set of implementation of old graphics API's for Windows 7 and later
versions.

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

• Hardware rendering at GPU feature level 12.0 (recommended but currently

has some issues)
• Hardware rendering at GPU feature level 11.0 (recommended)
 • Hardware rendering at GPU feature level 10.1 (has a minor limitation for
DX8/9)
• Hardware rendering at GPU feature level 10.0 (there are some limitations)
• Software rendering through Microsoft WARP renderer

The following graphics API libraries are implemented:

• Glide 2.11, Glide 2.45, Glide 3.1 and Glide 3.1 Napalm
• DirectX 1-7 (all versions of DirectDraw and Direct3D up to version 7)
• Direct3D 8.1
• Direct3D 9

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).

3. Requirements

Minimum:

• Operating system: Windows Vista/7/8/10

• Hardware: GPU supporting DirectX feature level 10.0.

Optional and recommended:

• GPU supporting DirectX feature level 11.0 or higher

4. Test results

We can examine this in two aspects:

 • Used hardware and performance
I've tested and run different versions of dgVoodoo2 on the following GPU's:

o Intel HD 2000 (only with old drivers supporting feature level 10.1)
o GeForce 8600 GT (feature level 10.0 only)
o Intel HD 4000
o Geforce GT 610
o AMD HD 6450
o Intel HD Graphics 530
o GeForce GTS 450
o AMD HD 7850
o GeForce GTX Ti560 (RIP)
o AMD R7 360
o GeForce GTX 1060

• Accuracy of the emulation, individual games and applications

Of course it's not perfect but I think I got very nice results in general. I
maintain expanding lists for games and demos, for DirectX emulation:
Games
Demos

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.

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:

• Folder of the wrapper DLL

• Folder of the application (EXE)
• User application data folder

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

• CPL always writes INI format config file (unlike previous versions) - and you
can edit it manually, passing over the CPL
• CPL doesn't expose all the sections of the configuration by default only the
most important ones - you have to enable additional ones through the context
menu

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:

• If the wrapped app and the CPL runs on different privilege levels
(admin/nonadmin) then the app won't appear in the instance list or they
cannot communicate to each other. Sorry for the inconvenience.
• Switching resolution or MSAA can only be performed perfectly if the
application re-renders everything on each frame. If it uses or keeps previously
(once-)rendered things like cockpits or similars then they will be missing as will
not get re-rendered. (Glide only)
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:

• Static resolutions

Those are enumerated by your videocard for the selected display output.
Select any of them, and the wrapper will force that one (along with the
selected refresh rate), no matter what resolution the application wants to set.
Resolution 'Unforced' means always using the current application resolution,
so there is no overriding at all.

• Dynamic resolutions

First, a little explanation on what the practical problems are with static
resolutions (especially for DirectX applications).

o The application may use multiple resolutions for different parts like
movies, menus and ingame. The statically chosen resolution may not
have the same aspect ratio as those of them. For app-resolutions
with different aspect ratios like 4:3 vs 16:9 it's a problem because
one of them will be displayed hugely distorted.

o Even if the app uses only one resolution, and you can select or type
another one with the same aspect ratio, then selecting the proper
resolution is still not an easy task:
a) you don't necessarily know what resolution the app uses
b) you don't necessarily know what the max resolution your display
is capable of
c) even if you know both of them, you may have to calculate
manually the desired resolution.
(My own problem was the following: I sat down in front of a new computer
with a 4K monitor and wanted to try out some stuffs through dgVoodoo. I
faced the fact that I didn't know the exact monitor resolution, I also didn't
know what res the stuffs to try were using. I just wanted the maximum
available resolution to be forced that keeps the aspect ratio.)

Dynamic resolution is the synonim of "let the wrapper choose the current
resolution for you". The maximum, and also the base used for calculating the
current resolution, is your desktop resolution. The base rule is that the
wrapper always calculates the maximum available resolution for the given
scaling mode, but

o you can restrict the base maximum to FullHD (1920x1080) or QHD

(2560x1440) for weaker GPUs (like low-end cards or maybe,
integrated chips) with large-res display outputs, and
o you can restrict the scale factor to integer numbers.
(ISF - integer scale factor)

So, dynamic resolutions are the following:

o 2x, 3x, ...: Integer multiples of application resolutions; doubled,

tripled, etc.
o Max: Maximum resolution available
o Max ISF: Maximum resolution with integer scale factor available
o Max FHD: Maximum resolution available (but restricted to
1920x1080)
o Max FHD ISF: Maximum resolution with integer scale factor
available (but restricted to 1920x1080)
o Max QHD: Maximum resolution available (but restricted to
2560x1440)
o Max QHD ISF: Maximum resolution with integer scale factor
available (but restricted to 2560x1440)
o Desktop: Desktop resolution (this value can be forced, see
additional General options); this value simply overrides the
application resolution so the aspect ratio is not necessarily
preserved. This is useful for games patched to render at a
widescreen camera FOV but support only old-style 4:3 or 5:4
 resolutions.

All of them can have an additional integer scale parameter. The concrete
resolution resulting from the calculations is multiplied by the scale. "Max 2x"
and "Max ISF 2x" are predefined ones available in the CPL resolution list
because they can be useful for manual supersampled rendering.

When working with a dynamic resolution, the concrete resolution is unknown

(calculated at runtime) hence no refresh rates are enumerated along with
them, even if enumerating refresh rates is enabled. You can still force one (see
Custom resolutions below).
See the API specific readmes to understand the logic of selecting a real refresh
rate value for unforced cases.

• Custom resolutions

A custom resolution is either a static one that is not in the enumerated list, or
one that is partially overridden. Defining a custom resolution through the CPL
is about typing the string -manually into the combo box- describing the
resolution/refresh rate pair.
Resolution and refresh rate can be overridden independently on each other.
Here are some examples (don't type quotation marks):

o "128x128, 60" - means static resolution 128x128 at forced rate of

60Hz
o "128x128, 0" or just "128x128" - means static resolution 128x128
without overridden refresh rate
o "0x0, 75" or "unforced, 75" - means unforced (static) resolution with
forced 75Hz
o "max_isf, 83" - means Max ISF dynamic resolution with forced 83Hz
o "max_qhd_2x, 60" - means twice of the Max QHD dynamic
resolution with forced 60Hz

If your resolution and refresh rate is in the list then it is better to select it from
there than typing it manually. It is because e.g. 60Hz is not exactly 60Hz in
 practice but 60.01Hz or 59.95Hz or so, depending on your display hardware.
dgVoodoo always handles the refresh rates in their exact rational form but it
cannot do that with manually typed ones.
When displaying a refresh rate in the combo box, dgVoodoo truncates the
value. So, for example, 59.95Hz will appear as 59Hz in the list, while the
display manufacturer probably claims that your display supports 60Hz. Don't
let it mislead you. It is all about truncating or rounding the values.
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