===============================================================================
dgVoodoo 2.54: Glide, DirectDraw/Direct3D and D3D8 to Direct3D11 Wrapper
Released: April 25, 2017
Author: Dege

Copyright (c) 2013-2017
===============================================================================

Table of contents

1. Redistribution rights
2. Features
3. Requirements
4. Test results
5. Usage
6. Configuring
7. Resolution overriding
8. General Control Panel (CPL) options
9. General tips and known issues
10. 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:

2. Features

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

This wrapper can use Direct3D 11 with different device types as wrapping output:

• Hardware rendering at GPU feature level 10.1 (recommended)
• Hardware rendering at GPU feature level 10.0 (there are some restrictions)
• Software rendering through Microsoft WARP renderer

• 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

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).
dgVoodoo basically can work in two ways:

• Using its precompiled shaders - it is the less efficient mode (legacy) and doesn't provide DX8-level vertex/pixel pipeline functionality
• Using an external HLSL shader compiler - this is the most efficient and recommended mode and referred as 'dynamic shader compiling'

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

• Operating system: Windows Vista/7/8/10
• Hardware: GPU supporting DirectX feature level 10.0.

• GPU supporting DirectX feature level 10.1
• HLSL shader compiler (D3DCompiler_43 or D3DCompiler_47)
  (note that D3DCompiler_47 is part of Windows 10)

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:
  • Intel HD 2000 (feature level 10.0 only)
  • GeForce 8600 GT (feature level 10.0 only)
  • Intel HD 4000
  • Geforce GT 610
  • AMD HD 6450
  • Intel HD Graphics 530
  • GeForce GTS 450
  • AMD HD 7850
  • GeForce GTX Ti560 (RIP)
  • AMD R7 360
  • GeForce GTX 1060
  If dynamic shader compiling is utilized then dgVoodoo generally performs quite well on all hardware except integrated chips (like Intel HD 2000 and 4000).
  Using only precompiled shaders requires a mid-class video card at least, and the low-end ones (intended for office-like usage) like Geforce GT 610 and AMD HD 6450 are not recommended.


• 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. For DirectX emulation only a local installation is possible since the DirectX dlls CANNOT be copied to the system folder (see DirectX readme).

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

• Windows\System32 folder for 32 bit operating systems
• Windows\SysWOW64 folder for 64 bit operating systems

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 strongly recommended and even unavoidable to get all DX8 level features to work. If dgVoodoo cannot find D3DCompiler then it can use only its generalized precompiled shaders just like versions before 2.5. If dgVoodoo finds a supported compiler dll then it can adapt to the current circumstances and compile specialized shaders providing maximum GPU performance.

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). The configuration data is not stored in the dlls themself anymore. It is in a separate file named 'dgVoodoo.conf'. All of the Glide and DirectX dlls uses this file.

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

For modifying config files, you have dgVoodoo Control Panel (dgVoodooCpl). In dgVoodooCpl you can choose a folder where you can load (from) and save the current configuration. After 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.

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.

(Why configuration is still needed at all? Well, now it's not for choosing from millions of technical options due to weak implementation but for fancy things, see chapter 'General Control Panel (CPL) options' as well as Glide and DirectX readme.)

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

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

  • 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

  • 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

  • you can restrict the scale factor to integer numbers.
    (ISF - integer scale factor)

  So, dynamic resolutions are the following:
  • Max: Maximum resolution available
  • Max ISF: Maximum resolution with integer scale factor available
  • Max FHD: Maximum resolution available (but restricted to 1920x1080)
  • Max FHD ISF: Maximum resolution with integer scale factor available (but restricted to 1920x1080)
  • Max QHD: Maximum resolution available (but restricted to 2560x1440)
  • Max QHD ISF: Maximum resolution with integer scale factor available (but restricted to 2560x1440)

  By default, dynamic resolutions don't have refresh rate even if enumerating refresh rates is enabled. When working with a dynamic resolution, then the refresh rate is undefined and it is up to the wrapper and the video card that what rate will be used (probably the one at which desktop is driven).

• 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 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):

  • "128x128, 60" - means static resolution 128x128 at forced rate of 60Hz
  • "128x128, 0" or just "128x128" - means static resolution 128x128 without overridden refresh rate
  • "0x0, 75" or "unforced, 75" - means unforced (static) resolution with forced 75Hz
  • "max isf, 83" - means Max ISF dynamic resolution with forced 83Hz
  
  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.

• Resolution is calculated in the same way for scaling mode 'Unspecified', 'Centered' and 'Stretch with AR'.
  

• Stretched scaling mode with ISF tries to stretch to min([D|F|Q]) and the scale factor for both direction is the integer part of the minimum of
  min ([Dx|Fx|Qx])/Ax and min ([Dy|Fy|Qy])/Ay (ratios of X/Y directions).

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

• Glide: when switching from windowed mode to fullscreen then a new forced resolution is calculated by the wrapper, based on the native res of the display on which the full screen output will appear.

• DX: It's not so flexible at all, unfortunately. Since DX impl doesn't support changing resolution during its working, it cannot do the same as Glide when switching into fullscreen. Also, since display outputs are enumerated to the application, resolution calculation can rely only on the native res of the output on which DX is initialized (so changing the output of a running DX emulated app from the CPL application is without avail, won't affect the next resolution calculation).

8. General Control Panel (CPL) options

• Output API
  Three output API's are available:
  

  • Direct3D11 feature level 10.1

  • Direct3D11 feature level 10.0

  • Direct3D11 Microsoft WARP renderer
    
    D3D11 with FL10.0 is designed to be used with late DX 10.0 hardware and has some limitations:

    • No mipmapping in Glide rendering
    • Limited operations on Z-buffers
    • Buffers with forced MSAA can only be rendering targets; they cannot be used as
      • depth textures
      • source of copy operations (Blit in DDraw)
      • locked for CPU-access (Lock in DDraw/ LockRect in D3D8)
    • Faces of 3D-rendered cube-depth buffers cannot be
      • source of copy operations (Blit in DDraw)
      • locked for CPU-access (Lock in DDraw/ LockRect in D3D8)

    WARP is a software renderer, I intended it to be kind of a reference driver but I experienced some rendering errors with it unfortunately.

• Video card (adapter)
  In case you have more than one, then

  • Glide: which one to use for rendering. Option 'All of them' is equivalent to selecting the first video card in the list.
  • DirectX: it is a multi-device capable API so you can choose which adapter(s) are to be enabled for the emulation.

• Monitor (output)
  If you have multiple monitors then you can choose which one(s) (connected to the selected adapter):

  • Glide: which monitor is used for fullscreen output. When 'Default' is selected then switching from windowed to fullscreen during playing a game selects the monitor containing the largest part of the game window.
    It can be overridden dynamically on a running Glide wrapped application and it also affects dynamic resolution calculating (see resolution overriding).
  • DirectX: which monitor(s) to enable to appear as DX devices to the application. 'Default' enables all the monitors connected to the selected adapter. When the game or application goes into fullscreen then it always happens on the monitor (device) that the game/application selected for use. In case of a multidevice environment games and applications often (and silently) selects the first available device which generally corresponds to the primary monitor, but advanced apps allows the user to configure it through the app itself.
    It can be overridden dynamically on a running DirectX-wrapped application however it only affects the output, it is all about pure visuality. It doesn't affects dynamic resolution calculating (see resolution overriding) and also, the application shall continue to see the corresponding device in it original state (keep in mind that it can conflict with the app).

• Full Screen / Windowed
  See section "Usage".

• Unspecified/Centered/Scaled/Scaled with Aspect Ratio kept, for full screen
  If the current resolution the wrapped app using does not match any natural resolution your adapter supports then the display can be strethed out to fit all the screen or its size can be left unchanged but centered. NOTE that if your video card supports overriding the scaling method of applications, and you'd like to apply a scaling with aspect ratio then it is recommended to set dgVoodoo's scaling method to 'Unspecified' + set the scaling mode on your video card control panel because dgVoodoo's internal scaling is unfortunately not a sterling one. It implies that you may experience various problems like wrong mouse cursor or glitches in rendering in certain applications. Scaling can only be done well (transparently) on the GPU/display side.
  C64-like output: well, if you are not a former C64 owner and fan, don't even try it, I'm sure you won't like it at all. As dgVoodoo is my main hobby programming playground these times I tried some algorhytms as part of it. It's not really a feature, but the result of some former experimenting and can be funny for some scene demos.

• Progressive scanline order
  Default scanline order is interlaced or progressive. It is up to the output display device which one to choose altough it chooses progressive when it is possible, I think, so that when the device is capable of displaying a given resolution with a given refresh rate with progressive order. Otherwise it might choose interlaced order with halved physical refresh rate. If this option is enabled, you can only see enumerated resolutions that are displayable with progressive order. However, if a custom resolution is defined then it may causes the output device to use lower physical resolution than the wrapper set.

• Enumerate refresh rates
  Enables the CPL application to enumerate refresh rates for each resolution and enables the wrapper to override the default refresh rate of the application. However using other than the app default can cause heavy animation lagging or glitches!

• Color adjustments
  Brightness, color intensity (saturation) and contrast can be finetuned here. The defaults are good in general so treat this as a cool extra. (I'm using it in some cases for making colors more vital to get a bit cartoon-like effect.)

• Inherit Color Profile in full screen mode
  When this option is enabled then dgVoodoo won't change the physical gamma ramp of the screen but instead it solves the color adjustments just like in windowed mode and so your pre-configured color profile(s) for the given monitor(s) remain(s) preserved. Color adjustments are relative to the predefined color profile in that case.

• Keep window aspect ratio
  In windowed mode, when sizing the window, you can keep the aspect ratio of the current resolution.

• Capture mouse
  It's useful mainly (but not only) for multimonitor systems. If this is enabled then the mouse cursor is forced into the application window to prevent accidental mis-clicks outside of it.

• Center app window
  When a game controlling the mouse input is being run in windowed mode then it's a pain to move it's window into the screen, so I thought it's a valuable option (was a request too), but it can conflict with the mouse input or the app itself.

9. General tips and known issues

• Forcing things (like resolution, antialiasing, texture filtering, etc) is not a healthy thing. If an application or game uses low resolution or point sampled textures or anything dissonant to the eye then it has reasons for that. It is not because the programmers were so lame but of avoiding artifacts that would otherwise get brought in (typical example is a bilinear filtered texture with colorkey based transparency). If you force anything then potentially get one of those artifacts. If you can live with it then it is ok, use the wrapper in forced mode. If not then disable all forcings and use the particular game or application in the mode it was designed for, because no general method exists to fix such type of artifacts.
• Controlling antialiasing cannot be done on per-primitive basis in Direct3D 11 when feature set larger than 10.0 is used. That is why antialiased drawing is not emulated in Glide automatically in this version in any way (per-primitive or per-edge). It can only be forced globally in the CPL application.
• Fullscreen gamma ramp may not be supported by your card. nVidia and ATI seem to handle it as expected but (e.g.) Intel does not.
• When an application is being run in compatibility mode (Win98/XP etc) then the user's application data folder is different than the OS default. Therefore dgVoodoo cannot read the global config file and the default config gets applied if no local config file is present. The preferred way is creating a local config for such cases if other than the default needed. (Perhaps using the user's appdata folder is not a too good idea after all, I might change it later.)
• If you have a multimonitor system then always try a game to run on the primary one for the first time. Some games lock the mouse cursor to the screen area where game window is assumed to be (the left-top corner of the desktop). If such a game is being forced onto another monitor then clicking in the game causes application focus loss because its window is not under the mouse cursor.
• I don't know why but overriding refresh rates by arbitrary values (in the resolution selector combo box) does not seem to work for DirectX emulation. It is still subject to investigation because the code handling this is common for both Glide and DirectX. :(

10. Change log

• 2.54
  • Windows input issues caused by the wrapper are fixed (Outlaws, GTA1 DDraw mode, etc.)
  • Rendering transition between Glide/DDraw is fixed (Outlaws)
  • Concept of setup application is replaced with concept of Control Panel (CPL)
  • Control Panel App:
  • Contrast as a new color adjustment option is added
  • Preserving predefined monitor color profile(s) for fullscreen mode as an option is added
  • A general option for centering the application/game window is added
  • DirectX texture filtering options are changed, possibility of forcing anisotropic filtering is introduced
  • New scaling mode with C64-like output (it's not a feature but more like an experimenting code)
  • Visual cosmetics
  • DirectX:
  • Some of the DDraw code is guarded to avoid the unexpected worst-way DLL unloading
    Now LithTech engine games (Blood2, NOLF, Kiss Psycho Circus, ...) should tolerate Alt-Tab on Win10
  • Some other extra guarding to prevent crashes, Virtua Cop2 now works in D3D mode
  • Blit bug and clipper incompatibility fixed in DDraw (D3DRM, Tokipazu, tech demo Final Reality)
  • Minor issue in DDraw and bad L6V5U5 format descriptor is fixed (Kyro tech demos)
  • Adding support for plain surface format A8L8 (DDraw) (Matrox G400 Tech Demo)
  • D3D3 fog fixed (Shadows of The Empire patched to 1.1)
  • Execute buffer bug fixed in D3D (D3DRM)
  • Some D3D5 incompatibilities are fixed (crash and texture handling with Space Bunnies Must Die)
  • Fixing D3D6 bugs and calculations of old software-only lighting and other incompatible things (DX6 SDK sample applications (Immediate/Retained) + Fog City/Tirtanium demos)
  • Unexpected way of texture compression is implemented (D3D7, Soulbringer)
  • Adding support for Q8W8V8U8 texture format (D3D8) (3DMark 2001 SE, Nature, Pixel shader and Advanced Pixel shader test)
  • D3D8 device handling bug is fixed (multimonitor environment)
  • D3D8 compatibility fixings, now handling managed textures is compatible with Phantasy Star Online Blue Burst (corrupt mipmapping)
  • Issue with D3D8 device capabilities and SYSTEMMEM vertex buffers are fixed (LKCC demos)
  • D3D8 DrawIndexedPrimitive bug fixed (Syberia 2)
  • Adding support for depth buffer format D24X4S4 (D3D8) (Matrox Parhelia Reef Tech Demo)
  • Adding support for volume textures (D3D8), though with limited number of formats (Matrox Parhelia Coral Reef Tech Demo + DX8 SDK VolumeTexture sample + general)
  • Lower resource usage is partly included in this version. For the time being, only the usage of GPU accessible system memory.
  • General bugfixing, like unexpected forced windowed mode (Soulbringer movies), vertex shader (missing fog in Colin McRae Rally), non-perspective polygon drawing bug, fixed (Zanzarah The Hidden Portal), and a lot other
  • Handling depth buffers had some bugs at FL 10.0, fixed (D3D11)
  • Potential bad driving of D3D11 at FL10.1 when no resolution and MSAA is forced (D3D11) (Gorky17)
  • Some (regression and other) bugs in the D3D11 renderer are fixed
  • GeForce 4 profile is slightly modified to match a real GF4
  • Now light beams in Splinter Cell 1 should be rendered correctly through the GF4 card type (unblurred lights with occlusion)
  • 2 new videocard types are added:
  • GeForce FX 5700 Ultra (keeps the soft shadows for Splinter Cell 1 (because I like it :D) and will hopefully be feasible to provide place for new features later)
  • Matrox Parhelia-512 (for Matrox Coral Reef Demo 1.1 and other Matrox tech demos)
  • Glide:
  • Glide fix (far background in front of the 3D world: Mig29, Uprising)
  • Texture memory report is modified to match that of a real 3Dfx driver (Slave Zero)
  • Tons of code changing for new features that are not ready yet and so not included in this version


• 2.53
  • Support for 'dynamic resolutions' (see section 'Resolution overriding')
  • Added support for 'd3dcompiler_47.dll', so Win10 users don't have to download and mess with d3dcompiler dll, 47 is part of the Win10 OS.
  • Linear filtering was applied for upscaling the output-image even if the scale ratio was 1.0, fixed
  • Some modifications on the CRT-like shader were done for correct CRT-like appearance on high-res displays like a 4K monitor
  • Glide mode 'Compare to bias' is fixed (Esoteria demo)
  • Some other Glide rendering issues are fixed (Hype - The Time Quest)
  • DDraw system memory surface pitch is fixed to match that of DIBs (Snow Wave Avalanche)
  • A DX8 bug is fixed, so Mafia now works, altough I experience z-buffer glitches here and there (to be fixed)
  • Lot of general D3D/D3D8 bugs are fixed, too
  • GeForce4-style shadow buffering is reverse engineered and implemented in the 'Geforce Ti4800' preset
  • Floating point arithmetic differences (incompatibilities) between vs1.x and vs4.x are resolved, Splinter Cell 1 now works in shadow buffer mode
  • New dynamic vertex buffering algorhythm for removing rendering performance bottleneck, better usage of GPU
  • The config application is now per-monitor DPI-aware, to have sharp appearance
  • MSAA option name 'Auto' is changed to 'App driven'
  • New option for DirectX emulation is added (No texture filtering)
  • Changes in the default config:
  • Capture mouse is on
  • MSAA is app driven
  • Doc format is changed from txt to html and content is revised


• 2.52
  • Support for new output APIs are added
  • Direct3D11 at feature level 10.0 (there are some restrictions)
  • Direct3D11 Microsoft WARP renderer
  • Support for rendering DirectShow movie playback
  • Resolution overriding for DirectX emulation is now available
  • New scaling mode (forced 4:3 aspect ratio) with/without CRT-like appearance is added
  • MSAA support for DX8
  • Lot of DX8 bugfixings
  • A few DDraw/D3D bugfixings
  • Making 'VertexLayout' functionality be compatible with a real 3Dfx driver (Glide3)


• 2.51
  • Point sprite support for DX8 is added
  • New texture formats (A8, L8, A8L8) for DX7/DX8 are added
  • Tons of DX8 bugfixings, more compatibility
  • More DirectDraw compatibility in object handling + bugfixing
  • Regression bugs in Glide fixed
  • Capabilities of GeForce Ti 4800 and ATI Radeon 8500 are changed to be much closer to the real ones (see the technical details in the DX readme)
  • AMD driver bug causing driver crash with Glide rendering is workarounded now dgVoodoo should work on all AMD cards properly
  • 'Fast video memory access' is now compatible with Unreal engines
  • Emulated method of stretching the display output with keeping aspect ratio is added
  
  
• 2.5
  • First version of D3D8 implementation is added
  • Lot of bugs fixed during general DirectX code refactoring, I don't want to detail them all here
  • Dynamic shader compiling for all API components for better performance (see Usage and DirectX readme for details, you'll need D3DCompiler_43.dll for this feature)


• 2.45
  • Heavily refactored DirectX emulation code for certain planned features
  • Full cooperating between Glide and DirectX
  
  
  • DirectDraw emulation:
    • True multidevice support, more robust DDraw emulation
    • OLE interface support for DirectDraw
    • DXTC (S3TC) block compression encoder is added, full support for possible alpha-format conversions
    • Two new video card types are added with slightly different properties (GeForce4 Ti 4800, ATI Radeon 8500)
    • DirectDraw emulation-only mode could fail, fixed
    • Various DirectDraw bugs/incompatibilities are fixed
    • Blitting bugs fixed + full support for blitting from primary surface
    
    
  • Direct3D emulation:
  • New colorkeying method added and existing colorkeying related bugs are fixed
  • Bugs in rendering from execute buffers (points/lines), fixed
  • Bug in handling state blocks, fixed
  
  
  • Glide rendering
  • Resolution extension support (idea and technical concept by VEG and Zeus)


• 2.44
  • DirectX emulation:
  • Some surface/D3D device related bugs are fixed
  • Mirrored blitting was broken, fixed
  • 24bit software surface support is added
  • support for DXT1-5 compressed textures is added but an S3TC encoder is still missing for the cases when a compressed texture is the blitting target
  • Transforming normal vectors was incompatible with MS D3D, fixed This fix includes enabling/disabling of normalizing them, default was wrong for older than DX7 interfaces
  • Colorkey blend capability is added
  • support is added for old mode-X display modes
  • Various other small bugs fixed that I can't remember of


• 2.43
  • DirectX emulation:
  • 3D support for 8 bit surfaces is added (Colin McRae Rally)
  • Improved surface blitting, more optimal resource consuming for 3D surfaces
  • First version of fast surface video memory CPU-access is added
  • Introducing 'lost' state into the default DX behavior, with additional automatic self-restore mechanism for buggy DX applications
  • 3D TL vertex rendering incompatibilites, fixed
  • Various small 3D/caps related bugs, fixed
  • Several other bugfixes that I don't want to word here
  • Other:
  • Some problems related to the window procedures and message handling are fixed
  • Names of the wrapped running DX applications were displayed incorrectly, fixed


• 2.42
  • Direct3D3 renderstate handling bugfixes (some of them were disabled)
  • Various DirectDraw bugfixes like object/structure version handling,
  surface blitting, basic ROP codes are added, and others
  • Compatibility fixings in DirectDraw surface creation functionality
  • Compatibility fixings in DirectDraw surface locking functionality
  • Compatibility fixings in Direct3D device creating
  • Fixing/refactoring light handling in general; now software vertex processing can handle any number of them, and also, they can be added at any index in Direct3D7
  • 32 bit z-buffer support added
  • Minor Direct3D rendering bugs
  • Bad return code in an empty (but necessary) function on IDirect3DTexture, fixed
  • Missing multithreading guarding in some Direct3D3 methods, fixed

2.41
• Direct3D 3 support is added; that is all Direct3D interface is supported now
• Bug in the resolution enumerator in DirectDraw, fixed (classic and all other resolutions are now enumerated with all bit depths.)
• Resolution combo box was buggy in the setup; couldn't enumerate anything when too much resolutions were available, fixed
• Logic of selecting the refresh rate when unspecified rate is requested by the application is changed
• Overridable refresh rates
• Bugfixings and improvement for blitting to the primary surface in DirectDraw
• Bugfixings for other general surface locking/blitting functionality
• Minor DrawPrimitive bug fixed (missing triangles in Diablo II with Direct3D renderer)
• Bug with monochrome lighting is fixed (discovered with Jedi Knight - Mysteries of the Sith)
• Bug in surface blitting, fixed (The Settlers IV)
• Bug/incompatibility fixings in surface handling in: GetAttachedSurface, EnumerateSurfaces, SetSurfaceDesc and loading textures from system memory surfaces to texture surfaces in video memory
• DX wrapper is now more noshutdown-proof when unexpectedly pulled out from the process memory area; LithTech engine based games now should work (tested with Blood2 and Shogo Mobile Armor Division)
• Various other small bugs fixed that I came across
• Introducing 'unspecified' scaling mode. If you want to apply 'scaling but keeping aspect ratio' then select it on your graphics driver control panel and select 'unspecified' mode in dgVoodoo Setup. If it does not work then your only chance is forcing it through the graphics control panel (it all seems to be a Windows issue).
• Disabling 'Bilinear blit stretch' in the default configuration. I've seen a few games where it caused more 'harm' than coolness that is why I decided to disable it by default.


• 2.4
  • DirectX rendering:
  • New, improved version of DirectDraw. It fully supports creating and blitting to/from textures, Z-buffers and 3D-renderable surfaces with several pixel formats. Also, general API-behavioring is more accurate to the original one because of lot of bugfixings and heavy reverse engineering.
  • Gammacontrol interfaces is added to DirectDraw
  • First version of Direct3D implementation is added and (almost) fully supports DirectX5, DirectX6 and DirectX7. For more and technical details, see the DirectX readme. Direct3D interfaces are also as carefully reverse engineered as DirectDraw ones.
  • Glide rendering:
  • Bug in handling utility textures, fixed (missing textures in South Park)
  • Bug with PALETTE6666 extension fixed (unreadable menu text in Need For Speed - Porsche 2000 with a Voodoo2 or higher)
  • Bug with tripebuffering fixed (missing 3D elements in The Tainted)
  • Adapting Glide3 to 3Dfx mini GL driver (3Dfxvgl.dll), (American McGee's Alice):
  • Lowering gamma bitnum to 8 (3Dfx didn't follow his own rules...)
  • Some init/exit code could get stuck because they can get called from DLLMain, fixed
  • Setup
  'Apply' button in the setup is added (I got bored to OK'ing and reopening the setup each time I want to modify the config of more folders or running instances)


• 2.32
  • Possibility of overriding the application resfresh rate is added
  • Small Glide3 fix (bug with Turok 2)
  • Minor Glide3 shader modification (SurfDemo)
  • Glide lib is made thread-safe at the needed (minimal) level (means avoiding crashes at certain circumstances where the original 3Dfx driver survived beause of its architecture; a Turok 2 issue again, using background threads)


• 2.31 - It is a slight patch version for 2.3:
  • Fixing Glide 3DF reader for various line ending types (Crazy Marbles)
  • A bug found in one of Glide state setting functions, fixed (Crazy Marbles)
  • Hidden/shown cursor glitch is (seems to be) fixed in windowed mode
  • Possibility of forcing progressive scanline order on output display is now available in the setup
  • Fixing some DirectDraw bugs thanks to other pending developments (what I don't want to release yet)


• 2.3 - This won't be easy because I suspended developing for a few months, but:
  • First I refactored the code in order to any new driver component or renderer could be added easily
  • Fixed some issues with multiple video cards/monitors. Now it works OK in a multi-videocard system (not so frequent usecase but I like if something is done well)
  • Added first version of DirectDraw component to the driver
  • Minor Glide shader modifications


• 2.2
  • Napalm build added
  • Glide3 fixings: erroneous clip coord space handling
  • Small bug related to lfb write with active pipeline, fixed
  • Setup got revamped a bit


• 2.15
  • Full support for texture buffers via Glide3 extension 'TEXTUREBUFFER' All 16 bit texture formats are supported as rendering format except for paletted ones
  • Bad color order for delta0 color, fixed (seems I'm not in luck with RGBA order in general)
  • Some bugs are fixed I found through my own tests: unwritten alpha values to the aux buffer, bogus Glide3 viewport handling
  • More optimization in LFB lock handling to avoid slowdowns on locking patterns/usage like in King's Quest: Mask of Eternity (Thanks for the feedback & help, Andrew!!)
  • A lot of code changed thanks to other developments, so I hope I have not broken anything


• 2.14
  • Unified Memory Architecture (UMA) along with TEXUMA Glide3 extension is supported
  • Some Voodoo hardware properties are changed according to UMA/non-UMA architecture
    (Now Extreme Assault works with Gulikoza's latest patch, but see Tips for more)
  • Optimizations for lfb read/write region (including 3Dfx watermark)
  • A missing thing from PCI emulation is implemented for perfect lfb access with active pixel pipeline


• 2.13
  • Improved PCI emulation for LFB access: heavy lfb-lockers like Carma1 and Pyl SHOULD run much smoother now (see Tips for more)
  • Glide3 fixings: bad color order with packed RGBA, uninitialized texchroma state
  • General glide fixings: bug in glide setstate and clip rectangle
  • Missing feature "fog with iterated z" is implemented along with minor shader modifications
  • Support for splash screen and shameless plug: dgVoodoo needs the 3Dfx splash dlls to get it working (3DfxSpl2.dll, 3DfxSpl3.dll, all with version 1.0.0.4), however I did not include them in the core dgVoodoo pack
  • Minor modification for DosBox
  • TMUnum selector combobox is fixed, I fcked it down last time


• 2.12
  • More shader optimizations: most critical ones are reduced to 90% in size again (So, by now, their size are 65% of the original. I hope I have not messed up anything with them.)
  • Optional 16 bit depth buffer (see Tips for why is that)
  • Some fixings in Glide3 thanks to some unexpected API-driving (scene demo Virhe)
  • Some bugs related to maintaining/switching/handling windowed/fullscreen state are fixed
  • Voodoo2 with 1 TMU is no longer selectable in the setup; A Voodoo2 always have 2 TMUs and it is the default now because shaders are optimal enough now to handle 2 TMUs


• 2.11
  • Refactoring GPU querying to get it to work with ATI drivers (ATI does not seem to handle them correctly, my code was always fooled into infinite loop at a certain point)
  • Further shader optimizations: most critical ones are reduced to 90% in size
  • Minor cursor-issue related to losing window focus, fixed


• 2.1
  • Potential stalling rendering (even on fast GPUs) when switching screen modes, fixed
  • Shader optimizations: most critical ones are reduced to ~80% in size
  • Ability to configure running Glide wrapped applications dynamically (see section 'Configuring')
  • Different exposed capabilities according to the selected card type
  • More Dosbox compatibility
  • Bug in gammaramp handling, fixed
  • Bug in fogtable generating code, fixed
  • Bug in PCI access emulation, fixed
  • Forced vSync is enabled by default to avoid overkilling the GPU with wild-rendering applications


• 2.01
  • Undrawn polygons when updating TMU memory, fixed
  • Potentially bad drawing of strip-primitives in Glide3, fixed
  • Malfunctioning LFB lock with 32bit formats when PCI emulation is enabled, fixed
  • Fullscreen/Windowed state was not always remembered between Glide-initializings, fixed


• 2.0 - The original version