Guide:Setting up 3dfx Voodoo in DOSBox‐X - Wengier/dosbox-x-wiki GitHub Wiki

Back to the DOSBox-X Wiki Welcome page.

Setting up 3dfx Voodoo in DOSBox-X

Overview

The 3dfx Voodoo is a 3D accelerator chipset released in late 1996, and sold by various graphic card manufacturers. The original Voodoo 1 adapters are not full video adapters, and in fact need to be used in conjunction with a separate VGA adapter in a pass-through manner. The video-output from the VGA video card must be connected to a video-in on the Voodoo adapter, which then overlays the 3D renderings, and the monitor is then connected to the video-output of the Voodoo adapter.

As these where the early days of 3D acceleration, it uses its own proprietary Glide API which was supported by many DOS and Windows 9x games at the time.

DOSBox-X has support for emulating the 3dfx Voodoo in one of two modes.

  • Low-Level Emulation, emulating the 3dfx Voodoo 1 hardware. This requires a very fast PC.

  • High-Level Emulation, where the Glide API calls are passed through to the host OS, where it is then converted to a modern 3D Graphics API.

You can find out whether they are currently enabled in DOSBox-X from the menu group Video ⇒ 3dfx emulation.

[voodoo] options

This section will list the available 3dfx Voodoo configuration options that DOSBox-X provides. Unless otherwise noted the options effecting the 3dfx Voodoo emulation are in the [voodoo] section of the DOSBox-X config file.

voodoo_card

  • Default value: auto

  • Possible values: auto, false, software, opengl

Enables low-level Voodoo card hardware emulation.

The "auto" option means it will try to use OpenGL if possible, and otherwise fallback to software rendering.

Note
 This emulation mode does not work in fullscreen mode.

voodoo_maxmem

  • Default value: true

  • Possible values: true, false

Enables maximum memory size for the Voodoo card hardware.

If true (default), the memory size will be 12MB (4MB front buffer + 2x4MB texture units). Otherwise, the memory size will be the standard 4MB (2MB front buffer + 1x2MB texture unit).

glide

  • Default value: false

  • Possible values: true, false

Enables high-level Glide API pass-through to the host OS. This requires that the host OS has a Glide API library (or Glide wrapper) installed, and in addition it requires the special GLIDE2X.OVL file provided by DOSBox-X, or for Windows 9x games a specially patched GLIDE2X.DLL.

Note
 This only works for games that dynamically link to the external GLIDE2X library. It does not work for so-called statically linked games that have the GLIDE library code integrated with the game code.
Note
 Starting with DOSBox-X 0.83.24, glide is supported in fullscreen mode. Older versions could only run it in windowed mode.

lfb

  • Default value: full_noaux

  • Possible values: full, full_noaux, read, read_noaux, write, write_noaux, none

Enable LFB (Line-Fill-Buffer) CPU Cache access for Glide.

Note
 OpenGlide does not support locking the aux buffer, as such please use _noaux modes.

splash

  • Default value: true

  • Possible values: true, false

Show 3dfx splash screen on game startup

This option only applies when using the high-level Glide API emulation, where the 3dfx splash screen is normally not shown. This has no effect when using the low-level Voodoo adapter emulation, where the 3dfx splash screen will always be shown when the Voodoo adapter is initialized by the game.

In addition, this option is only supported on x86 Windows hosts, and it requires the 3dfxSpl2.dll library to be installed. It is enough for 3dfxSpl2.dll to be in the same directory as dosbox-x.exe

Note
 The 3dfxSpl2.dll library only exists for 32bit x86. This means that if you want to see the 3dfx splash screen that you must use the 32bit x86 version of DOSBox-X.

[cpu] option

ignore undefined msr

  • Default value: false

  • Possible values: true, false

This setting is located in the [cpu] section of the DOSBox-X config file.

Normally the CPU will fire an Invalid Opcode exception in the case of an undefined MSR (Model-specific register).

This option is off by default, enable if using software or drivers that assumes the presence of certain 686 MSR registers without checking. If you are using certain versions of the original 3dfx Glide drivers for MS-DOS you will need to set this to TRUE as 3dfx appears to have coded GLIDE2X.OVL to assume the presence of Pentium Pro/Pentium II MTRR registers.

Another (probably better) way to circumvent this issue with the 3dfx drivers, is to emulate a Pentium Pro or Pentium II CPU in DOSBox-X by setting either cputype=ppro_slow or cputype=pentium_ii in the [cpu] section of your DOSBox-X config file.

Low Level emulation

This emulation mode has been supported by DOSBox-X for a long time. It emulates the original 3dfx Voodoo 1 chipset, and therefore works with the official 3dfx DOS and Windows 9x drivers. It is the easiest mode to get working, and is in fact enabled by default. Depending on the game, you may not have to do anything, or you just need to select 3dfx Voodoo in the setup program. Some other games may require that you install a patch, or that you run a different executable to start in 3dfx mode.

The main disadvantage of this mode, is that it requires a PC with a very fast CPU (high clock frequency) to emulate the Voodoo adapter.

Note
 Most DOS games shipped with copy of the 3dfx glide2x.ovl library. For low level emulation it is important that you use an official version of this library.

High Level emulation

This mode requires DOSBox-X 0.83.5 or newer, and it only works for DOS games that use the GLIDE2X.OVL library. Or DOSBox-X 0.83.10 or newer for Windows 9x games that use the GLIDE2X.DLL library.

Instead of emulating the 3dfx hardware, this method converts the Glide API calls to a modern 3D Graphics API, and is therefore much more efficient. However, it also requires a few more steps to get working.

The biggest issue is that the Host OS needs to have a Glide API pass-through library installed (glide2x.dll for Windows, libglide2x.so for Linux, and libglide2x.dylib for macOS), and that you use the special GLIDE2X.OVL provided in DOSBox-X (or for Windows 9x games the special GLIDE2X.DLL), instead of one that may be provided with the game or provided by 3dfx.

When DOSBox-X is started with glide=true, and you have a compatible glide wrapper installed on the host, the special modified GLIDE2X.OVL file for DOS games will automatically appear on the emulated Z: drive (Z:\SYSTEM in DOSBox-X version 0.83.14 or later).

If the game already provides a GLIDE2X.OVL file located in the game directory, then you need to rename the game’s original GLIDE2X.OVL file to something like GLIDE2X.ORG. Then the game can usually find the GLIDE2X.OVL library on the Z: drive automatically, but if not, you also need to copy the GLIDE2X.OVL file from the Z: drive to the game directory for use with the game.

Note
 It is good to keep a backup of the games original GLIDE2X.OVL file, as you will need it, if you decide you want to use the low-level 3dfx Voodoo hardware emulation later. Hardware emulation requires that you use the games original Glide library, and not the special one used for pass-through.
Note
 If you want to boot a real DOS in DOSBox-X and still use Glide pass-through, you need to copy the GLIDE2X.OVL file from the Z: drive to your DOS harddisk image.
Note
 Not all DOS games that support 3dfx use the separate (dynamically linked) GLIDE2X.OVL library. Some are statically linked (the GLIDE library code was integrated with the game code during compilation). Those games are NOT compatible with GLIDE pass-through mode, and need to be run in low-level emulation mode instead.

Windows host: Installing glide2x.dll

Note
 Although this library has the same filename as the old Windows Glide library for real 3dfx Voodoo adapters, it is in fact not the same. The library used here converts Glide API calls to a newer 3D Graphics API, and will not work with a real 3dfx Voodoo adapter.

There are several implementation providers for the Windows glide2x.dll library file, namely nGlide, dgVoodoo, Glidos, and OpenGlide.

They do not necessarily work exactly the same. Before trying to find an implementation of this library file, please keep in mind that the architecture of the DOSBox-X executable you are using matters, e.g., whether the DOSBox-X executable is a 32-bit x86 or 64-bit x64 build. Due to the way how Windows works, a 32-bit x86 glide2x.dll can only be used by a 32-bit x86 DOSBox-X executable, and likewise a 64-bit x64 glide2x.dll can only be used by a 64-bit x64 DOSBox-X executable. As a result, in order to make Glide work, please make sure that you do not mix up the CPU architecture of the DOSBox-X application and any DLL files.

nGlide

nGlide appears to be a popular 3dfx Voodoo Glide wrapper provider which converts Glide API calls to Direct3D or Vulkan, and is supported on Windows XP and later.

It comes with an installer to automatically install the Glide library files including glide2x.dll to your Windows directory.

Note however that only 32-bit x86 DLL files are included in nGlide, as of its latest version. This means that if you choose to use nGlide as your Glide wrapper, then you must use the 32-bit (x86 architecture) DOSBox-X binaries (either SDL1 or SDL2 builds) for the Glide feature.

The nGlide installer is available from: https://www.zeus-software.com/downloads/nglide

dgVoodoo

dgVoodoo is another 3dfx Voodoo Glide wrapper which converts Glide API calls to Direct3D for Windows 7 and later.

Unlike nGlide it does not come with an installer as of this time, but it does provide both 32-bit x86 and 64-bit x64 glide2x.dll files in its zip packages. Therefore, you can use either the 32-bit x86 build or the 64-bit x64 build of DOSBox-X for the Glide feature, as long as the correct glide2x.dll file is available to the DOSBox-X executable. You can put the glide2x.dll file (extracted from its zip package) either in your DOSBox-X directory, or in the Windows’ System32/SysWOW64 directory (in the case of 64-bit Windows, C:\WINDOWS\SysWOW64 for 32-bit glide2x.dll file and C:\WINDOWS\System32 for 64-bit glide2x.dll file).

The zip packages are available from: http://dege.freeweb.hu/dgVoodoo2/dgVoodoo2/

OpenGlide

OpenGlide is an open-source Glide API wrapper to OpenGL implementation that is not actively maintained. You will need to compile it yourself using Visual Studio or MinGW, and should therefore only be considered by advanced users.

The original OpenGlide repository on Sourceforge has been unmaintained for a long time and does not work for our purposes. Some forks exist, such as: https://github.com/voyageur/openglide which works for DOSBox-X SDL1, or the fork available here: https://github.com/kjliew/qemu-xtra which seems to work for DOSBox-X SDL2.

Linux host: Installing libglide2x.so

Note
 Although this library has the same filename as the old Linux Glide library for real 3dfx Voodoo adapters, it is in fact not the same. The library used here converts Glide API calls to OpenGL, and will not work with a real 3dfx Voodoo adapter.
Warning
 OpenGlide is not compatible with SDL2, as such you can only use it with the DOSBox-X SDL1 version. If you do try to use it with the DOSBox-X SDL2 version, OpenGlide will segfault when trying to use the glide pass-through.

Unfortunately this library is not included with any Linux distributions, as such you need to compile it yourself. The following steps assume that you have the necessary compiler, developer tools and header files already installed.

Run the following commands from a Linux terminal to compile the OpenGlide fork from Voyageur:

git clone https://github.com/voyageur/openglide.git
cd openglide
./bootstrap
./configure
make
sudo make install
sudo ldconfig

libglide2x.so will by default be installed in /usr/local/lib which may or may-not be in your default library path. To check if ldconfig found the library, run the following command:

ldconfig -p|grep glide

You should get an output similar to this:

	libglide2x.so.0 (libc6,x86-64) => /usr/local/lib/libglide2x.so.0
	libglide2x.so (libc6,x86-64) => /usr/local/lib/libglide2x.so

In the above example it found the libglide2x.so library. If the ldconfig command returns nothing, you need to add the /usr/local/lib directory to your library path and re-run ldconfig as follows:

sudo sh -c 'echo /usr/local/lib > /etc/ld.so.conf.d/usr-local-lib.conf'
sudo ldconfig

macOS host: Installing libglide2x.dylib

Just like on Linux, you will need to compile the library yourself. The necessary steps are detailed below.

Warning
 OpenGlide is not compatible with SDL2, as such you can only use it with the DOSBox-X SDL1 version. If you do try to use it with the DOSBox-X SDL2 version, OpenGlide will segfault when trying to use the glide pass-through.

Install the OpenGlide dependencies

  1. Install Xcode command-line tools: You need Xcode command-line tools from Apple in order to install Home Brew. You can install Xcode from the App Store or run the following Terminal command:

xcode-select --install

Alternatively, when you run the Home Brew install script (see below), it will install the command-line tools for you.

  1. Install Home Brew: Home Brew is the package manager for macOS that makes it easy to install the required packages needed for OpenGlide to compile successfully. You can get it from https://brew.sh or run the following command from a Terminal shell:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

  1. Install the required Homebrew packages needed by OpenGlide: Run the following Terminal command:

brew install SDL1

Build the OpenGlide libraries

  1. Download the source code from this fork of OpenGlide, which has been patched to work on macOS Mojave or higher: https://github.com/almeath/openglide

  2. Unzip the downloaded folder to your desktop and then navigate to the folder using Terminal:

cd $HOME/Desktop/openglide-master

  1. Run the following commands, in order:

./bootstrap
./configure
sudo make install
Note
 If the make command fails with an error about a missing "features.h" file, you can create one in the correct location with the following command: 
sudo touch /usr/local/include/features.h

Then run make again, and it should work. The features.h file is not needed directly by OpenGlide but sometimes the macOS command line tools require it for the build script to complete successfully.

If the build is successful, the resulting libraries are installed to /usr/local/lib/:

libglide.so.2
libglide2x.0.dylib
libglide2x.a
libglide2x.dylib
libglide2x.la
Note
 libglide.so.2 is an alias (symlink) file that has no 'original'. It appears to be a remnant of the Linux based build, and can probably be deleted or otherwise ignored. The macOS dynamic (dlylib) and static (a/la) files are the key components.

These files can remain in your library folder and will be automatically found by DOSBox-X.

Alternatively, you can place them inside your DOSBox-X application package (/Contents/Resources), and they should be recognized in there first, before falling back to the system level files if required.

Test for detection of the OpenGlide libraries

A good way to test the functionality of your OpenGlide library is to download DOSBox-X and enable glide within the configuration/settings in accordance with the DOSBox-X Wiki.

If the OpenGlide library is successfully detected, when you run DOSBox-X it will generate two output files called OpenGLid.ini and OpenGLid.log (the former providing options to adjust the OpenGlide settings). These should be located in the same place as your DOSBox-X application or executable binary.

Optimize the OpenGLid.ini settings

The following settings are recommended (with InitFullScreen=1 to start in fullscreen mode)

[Options]
WrapperPriority=2
CreateWindow=0
InitFullScreen=1
Resolution=0.0
EnableMipMaps=0
IgnorePaletteChange=0
Wrap565to5551=1
EnablePrecisionFix=1
EnableMultiTextureEXT=1
EnablePaletteEXT=1
EnableVertexArrayEXT=0
TextureMemorySize=32
FrameBufferMemorySize=16
NoSplash=1

Frequently asked questions

No GLIDE2X.OVL on Z: drive

Q: I have set glide=true in my config file, yet there is no GLIDE2X.OVL to be found in Z:\SYSTEM?

A: In addition to setting glide=true, DosBOX-X also checks if it finds a compatible glide library on the host. If this check fails, GLIDE2X.OVL will not appear, and the menu option Video ⇒ 3dfx emulation ⇒ Glide passthrough will not be checked.

The glide library installed on the host needs to be the same CPU architecture as the DOSBox-X executable. So for instance, if you are using a 32bit x86 Glide library, such as nGlide, you must also use a 32bit x86 DOSBox-X executable.

No 3dfx splash screen

Q: I don’t see the 3dfx splash screen when starting a game

A: This is normal when you’re running the game in high-level emulation mode (glide=true). This 3dfx splash screen is not part of the game, but rather built into the original Glide library (GLIDE2X.OVL for DOS, or GLIDE2X.DLL for Windows 9x). But the special versions used for Glide pass-through to the host do not have this animation. If you’re running 32bit Windows on the host, you may want to have a look at the splash=true setting, mentioned above.

Slow Glide emulation

Q: I set glide=true yet the game is very slow

A: Most likely you’re not actually running in glide pass-through mode, even though you set the option in your config file.

One tell-tale way of knowing if the game is running in glide pass-through mode, is the 3dfx splash screen when starting the game. If you see the splash screen, you are probably not running in pass-through mode, but rather in low-level Voodoo emulation mode.

To run in Glide pass-through mode, the GLIDE2X.OVL file must appear at Z:\SYSTEM when you start DOSBox-X, and you must be sure no other GLIDE2X.OVL file is being found by the game. For instance, if there is a GLIDE2X.OVL file in the game directory, rename it, and try again.

⚠️ **GitHub.com Fallback** ⚠️