+
+
+===============================================================================
+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:
+
+http://dege.fw.hu/
+
+Official dgVoodoo forum where you can contact me and the dgVoodoo community is at:
+
+http://www.vogons.org/viewforum.php?f=59/
+
+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 DX8 implementation and supplying me with ideas, tips and various informations
+on several games!!!
+
+ |
+| ---------------------- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ---------------------- |
+
+
+
+
+
+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
+
+
+The API's it currently can wrap are:
+
+ - 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.
+
+Optional and recommended:
+
+ - 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
+
+If the config file can be found in none of them then the default config is used.
+
+
+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.
+
+
+
+
+
+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)) |
+
+
+
+Remarks:
+
+
+ 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
+
+
+Options on the General tab affects all wrapped APIs, that is, currently
+Glide and DirectX.
+
+ - 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
+
+
+
+
+Have luck,
+
+Dege
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/EXE/dgVoodooReadmeDirectX.html b/EXE/dgVoodooReadmeDirectX.html
new file mode 100644
index 0000000..6ba5daa
--- /dev/null
+++ b/EXE/dgVoodooReadmeDirectX.html
@@ -0,0 +1,656 @@
+
+
+
+
+
+
+
+
+
+ dgVoodoo2 DirectX Readme
+
+
+
+
+
+
+
+===============================================================================
+dgVoodoo 2.54: DirectX emulation related stuffs
+
+===============================================================================
+
+
+
+
+
+Table of contents
+
+
+1. Important notes
+2. General overview
+3. Some technical info
+4. Application resolutions and refresh rates
+5. About fullscreen and windowed mode
+6. DirectX Control Panel (CPL) options
+7. Tips and known issues
+8. Why doesn't dgVoodoo DX emulation start up?
+
+
+===============================================================================
+
+
+
+1. Important notes
+
+
+
+First of all: NEVER COPY DDRAW.DLL AND D3D8.DLL INTO SYSTEM FOLDERS!!
+ALWAYS USE A LOCAL INSTALLATION FOR A GAME!
+DirectDraw and D3D8 are still existing and widely used system components in Windows.
+
+For clarifying, let's see what dlls MS and dgVoodoo use for DirectDraw and
+Direct3D:
+
+
+ -
+
+ MS:
+
+
+ | ddraw.dll | - Contains all DirectDraw implementations up to version 7 |
+ | d3dim.dll | - Contains all Direct3D implementations up to version 6 |
+ | d3dim700.dll | - Contains Direct3D 7 implementation |
+ | d3d8.dll | - Contains Direct3D 8.1 implementation |
+
+
+
+ -
+
+ dgVoodoo:
+
+
+ | ddraw.dll | - Contains all DirectDraw implementations up to version 7 |
+ | d3dimm.dll | - Contains all Direct3D implementations up to version 7 |
+ | d3d8.dll | - Contains Direct3D 8.1 implementation |
+
+
+
+
+
+So, dgVoodoo packs all of its pre-D3D8 implementation into one module, d3dimm.dll,
+which differs in name from the MS one (note the extra 'm' in the name).
+Thus, copying it to the system folder by accident won't cause any harm. In spite
+of that, it is not recommended.
+
+
+
+
+2. General overview
+
+
+If you want to wrap an old DirectX stuff then just copy dgVoodoo's dlls to the
+application folder and launch that. DirectX rendering is configurable similarly
+to Glide. (See DirectX related CPL options)
+DirectDraw is usable without Direct3D but there are no 3D rendering capabilities
+exposed to the applications in that case.
+Direct3D8 is a standalone component, no need for DirectDraw to use it. In spite of
+that it is a good idea to copy DDraw.dll along with D3D8.dll because a lot of movie
+playback system (e.g. DirectShow) rely on DDraw even in D3D8 games. dgVoodoo DDraw
+and D3D8 has the ability and internal support to cooperate if the situation requires.
+
+
+All the interfaces of old DirectX (that is, all DirectDraw interfaces and
+Direct3D 3/5/6/7/8 interfaces) are almost fully supported, and existing implementation
+is improved version by version by more and more reverse engineering and finetuning.
+
+
+Since DirectX is not a pure hardware-only rendering API, basically two types of
+virtual video cards can be used, like back in the old days, hehe. Four extra
+video card types are added to utilize different chipset features and provide correct
+vendorID/hardwareID.
+Available video card types:
+
+
+ -
+ One that simulates an old SVGA with hw-capabilites only for 2D blitting
+ operations.
With such a card, only a software 3D rendering device can be used.
+
+
+ -
+ One (imaginary) video card that has its custom hw 3D rendering support.
+ This card provides support for full hardware acceleration including
+ 'Transform & Light'.
+
+
+ -
+ GeForce4 Ti 4800
+
+ -
+ ATI Radeon 8500
+
+ -
+ Matrox Parhelia-512
+
+ -
+ GeForce FX 5700 Ultra
+
+
+
+
+For more detailed capabilities, see the technical info.
+
+Software rendering devices does not use real software rendering in dgVoodoo. I
+think that a software rasterizer has no reason for existence nowadays and didn't
+want to write one just for fun so they use hw accelerated rendering in the
+background. The point is, towards the applications they logically appear as
+software devices.
+
+DirectX renderer needs less GPU power (for general cases) than Glide renderer but
+it uses relatively complex precompiled shaders too (since whole of the fixed
+function vertex/pixel pipeline has to be mapped to pure shader functionality).
+
+DX emulation has a method for fast CPU-access of locked surfaces. The current
+method is not the final version and going to be improved later.
+The reason of not using that one all the time but it is up to the user's choice
+is that this method is not 100% safe and can cause crashes under certain
+circumstances. It depends on the wrapped application.
+
+Important to note that compatibility with MS DirectDraw is not completely
+guaranteed, especially with very old applications written in the win95/Win98 era.
+Those applications might utilize DirectDraw/GDI interaction which is not fully
+supported in dgVoodoo. I would like to improve that somehow, in later versions.
+
+
+
+
+3. Some technical info
+
+
+
+I say 'almost fully supported' when talking about DX support because there are
+some functions on certain interfaces of which functionality is somewhat unclear
+or totally unimportant, so they either not implemented at all or just
+partially because I did not have time and patience to figure out their exact
+behavior. Think about a total of 5-6 functions of all the DX interfaces,
+I hardly believe that anything used them.
+
+For DX8.1, the following features are not implemented but planned to be in the
+future:
+
+
+ - Higher-Order Primitives (maybe some day)
+
+
+
+................................................................................
+
+
+Internal virtual 3D card has the following 3D hardware capabilities:
+
+
+
+
+ - Supports transforming and all kind of lighting with flat, Gouraud and Phong
+ shading, max 8 active lights
+ - Supports 6 clipping planes
+ - Supports vertex bending with 3+1 weights
+ - Supports matrix palette of 256 elements for indexed vertex blending
+ - Supports texture coordinate generating & transformation, projective texturing
+ - Supports all contemporary pixel formats for textures and render targets with
+ four different RGBA order (altough the order is not yet exposed in the CPL app)
+ - Supports compressed textures (DXTC1-5)
+ - Supports volume textures with limited number of texture formats
+ - Supports Z-buffer (of course) and stenciling (but there is no W-buffer)
+ - Supports vertex and pixel fog
+ - Supports colorkeying with one texture (with colorkey blending or
+ colorkey discarding)
+ - Supports all texture sampling modes
+ - Paletted textures
+ - Depth textures
+ - 16 vertex streams
+ - Vertex tweening
+ - Supports point sprites
+
+
+
+* Additionally, if dynamic shader compiling IS NOT AVAILABLE then
+
+
+
+ - Supports 4 texture stages and all DX7-level texture blending operations and
+ arguments on each of them including bump mapping
+ - DX8-level vertex/pixel pipeline is UNAVAILABLE
+
+
+
+* if dynamic shader compiling IS AVAILABLE then
+
+
+
+ - Supports all of the 8 texture stages and all DX8-level texture blending
+ operations and arguments on each of them
+ - All types of DX8.1 bytecode shaders are supported
+
+ vs1.0, vs1.1
+ ps1.0, ps1.1, ps1.2, ps1.3, ps1.4
+
+ 256 vertex shader constants
+
+
+
+The other 4 card types are not an exact emulation of the given chipsets with some
+real ATI/nVidia/Matrox driver version. They are just present to bias the available
+rendering capabilities and properties toward a real ATI, nVidia or Matrox card:
+
+
+
+GeForce4 Ti 4800 capabilities:
+
+
+
+ - Same as the internal virtual 3D card, except:
+ - No 32 bit z-buffer support
+ - Full cut colorkeying
+ - No indexed vertex blending
+ - Maximum supported pixel shader version is ps1.3
+ - Max 96 vertex shader constants
+
+
+
+ATI Radeon 8500 capabilities:
+
+
+
+ - Same as the internal virtual 3D card, except:
+ - No 32 bit z-buffer support
+ - Plain colorkeying
+ - Max 57 matrices for indexed vertex blending
+ - No paletted texture support
+ - 8 vertex streams
+ - Max 192 vertex shader constants
+
+
+
+
+ Matrox Parhelia-512 capabilities:
+
+
+
+ - Same as the internal virtual 3D card, except:
+ - No 32 bit z-buffer support
+ - Plain colorkeying
+ - No paletted texture support
+ - Maximum supported pixel shader version is ps1.3
+
+
+
+
+ GeForce FX 5700 Ultra capabilities:
+
+
+
+ - Same as the internal virtual 3D card, except:
+ - No 32 bit z-buffer support
+ - Full cut colorkeying
+
+
+Since I cannot enumerate all the capabilities here, check them out with DXCapsViewer if interested.
+Also, those capabilities might be changed in the future if I get more accurate information about the hardwares in question.
+
+
+................................................................................
+
+DirectDraw and Direct3D objects supports all types of rendering devices that are
+supported in original DirectX.
+Direct3D8 support HAL and software device types.
+
+In MS pre-Direct3D8 implementations Direct3D7 is the only one that can be used with
+hardware vertex transformation and lighting, through a Transform & Light (T&L)
+device (but I guess it casually falls back to software vertex processing if the
+device driver does not support the complete vertex operation pipeline that is
+currently set).
+
+In all other cases software vertex processing is used. In dgVoodoo vertex
+processing is always routed to the hardware when possible.
+However, it's not so simple: software vertex processing is unavoidable in Direct3D
+in some cases, for example when an application wants Direct3D to do only vertex
+processing without rendering or to calculate visibility, or, when the rendering
+extent must be updated when drawing primitives through a non-T&L device (this is
+not too important in practice but I included it because of full compatibility).
+Also, vertex processing for Direct3D3 can only be done in software because of the
+execution logic of execute buffers.
+It all means that dgVoodoo has a software T&L vertex processing engine like
+MS Direct3D for such cases, duplicating the hw functionality. However for
+transforming, bending, lighting, fogging and texture coordinate transforming
+calculations dgVoodoo uses fast vectorized SSE2 code instead of scalar FPU.
+
+(It should be noted that in newer DX version like DX7 MS uses SSE2 too.
+ What is more, for software emulation of vertex shader code in DX8, MS seems to
+ apply an internal compiler, that compiles from shader code to x86 bytecode.
+ Wow, what a nice feature!! I should do the same, but probably it all is not too
+ relevant on modern CPUs.)
+
+
+
+Phong shading (per-pixel shading) is not supported by MS Direct3D, only
+Gouraud (per-vertex). However the internal virtual 3D card can externally be
+forced to Phong shading through the CPL app but keep in mind that it can cause
+heavy GPU usage because Direct3D lighting is quite complex, typical hardware
+implementations supports 8 active lights with a lot of properties and components.
+Also, Phong shading is only applicable when the application commits all its
+transforming and lighting calculations to the D3D runtime. Unfortunately it is
+very common that games do their own T&L calcs and use D3D as a lowlevel rasterizer
+for the rest. It is especially true when a game is written for multiple platforms
+or multiple 3D APIs like Glide, D3D, OpenGL, etc. Direct3D3 always uses software
+vertex processing so Phong shading cannot be applied there at all.
+
+DX8 is a horse of another colour from the beginning of a new era. Applications
+written for that usually heavily utilize multiple vertex streams through real
+vertex and index buffers along with built-in hw T&L pipeline and/or shaders
+without any calculations done in software.
+
+Phong shading is only applicable with full fixed function vertex/pixel pipeline
+usage. If an application is rendering through a vertex and/or pixel shader in DX8
+then Phong cannot be utilized.
+
+
+
+
+
+
+4. Application resolutions and refresh rates
+
+
+
+An application using DirectX can only detect available resolutions and
+associated refresh rates by asking DirectDraw/DX8 to enumerate them. There are two
+slight problems with it in practice:
+
+
+ - Modern hardware does not necessarily report some low resolutions like 320x200,
+ 640x480, etc.
+ - Old hardware was not able to report refresh rates or query the current one in
+ general, back then when 60/75Hz CRTs were the standard displays. Thus, most of
+ the games/applications just used 0 for refresh rate when setting the resolution
+ which means 'unspecified or default' refresh rate.
+
+
+
+To workaround the first case, dgVoodoo keeps a list of 'classic' resolutions.
+These are the following:
+
+
+
+
+ - 320 x 200 (X-mode is also supported in DDraw)
+ - 320 x 240, (X-mode is also supported in DDraw)
+ - 640 x 400,
+ - 640 x 480,
+ - 800 x 600,
+ - 1024 x 768,
+ - 1280 x 1024
+
+
+
+
+If a resolution of that list is not amongst the ones that your modern adapter
+reports then dgVoodoo forces enumerating it to the application.
+
+As for the refresh rates, if an application does not specifify one of the
+enumerated ones but specifies 0 (default) then dgVoodoo finds and applies the
+natively supported one that is most closest to 60Hz.
+
+If you want to make sure or would like to use a custom refresh rate then
+you can override that through the resolution selector combo box (DirectX tab).
+For details, see chapter 'Resolution and refresh rate overriding' in the general readme.
+
+If the refresh rate is overridden then all resolutions are enumerated with the
+overidden value to the applications.
+
+
+
+
+5. About fullscreen and windowed mode
+
+
+
+Choosing fullscreen or windowed working mode is part of the DirectDraw API. Some
+games or demoscene stuffs run only in fullscreen so one could think what cool it
+would be to have them running in windowed mode. I thought the same so wanted to
+enable by default the same method to switch between them as used for Glide.
+There are some problems however: the ways handling fullscreen and windowed mode
+via DirectDraw are totally different in the aspect of the driving code. So,
+forcing an application into an unexpected situation may cause glitches or crashes.
+Also, a game may have its on mechanism for mode switching with which dgVoodoo
+could conflict. Due to those theoretic things, and because I experinced some
+problems with some games, I decided to emulate the original DirectDraw behavior
+by default: when a fullscreen application loses the focus then its window gets
+minimized and when it regains that its window is restored and enters fullscreen
+again and no manual switch is available. Also, there are no changes applied on the
+app window like style and overridden messages, etc.
+
+If you make sure that a given game does not conflict with dgVoodoo's Alt-Enter
+thing then you can enable that in the CPL app. Also, you can force it to windowed
+mode if 'app controlled fullscreen/windowed' option is disabled at the game
+startup (and choose windowed mode in the general settings), without Alt-Enter.
+Forcing a windowed application to fullscreen can only be done by manual switch
+because there is no way to 1) detect when an application begins its rendering and
+2) switch to fullscreen.
+
+(But, think about it, windowed to fullscreen does not make any sense. The
+resolution used comes from the window size but the window may get resized or
+repositioned when switching mode, so..., it's confusing.)
+
+What is more, since DirectDraw was a one-monitor-API in practice, integrating windowed
+applications in a multimonitor environment is already a problem even for MS,
+I think. If such an app is even forced to fullscreen mode then it may crash or
+misworks for reasons I do not want to word here.
+
+Lost mode is emulated in default DX emulation mode, namely when switching
+between windowed/fullscreen mode by Alt-Enter is disabled. This is because some
+DX applications count on losing their surfaces when their window loses focus and
+their code paths can be mislead if they remain 'unlost'. (This is a result of bad
+programming technique as DX SDKs clearly state that an application shouldn't
+rely on window focus lost or any other circumstances.)
+
+On the other hand, there are incomplete or buggy DX applications that can't
+restore when they get reactivated and just get stuck. So, introducing lostmode
+emulation is up to a potential feature loss, as such applications likely worked
+well with older dgVoodoo versions. In order to keep this feature dgVoodoo applies
+auto-restore for the needed elements when such a situation is detected.
+
+
+
+
+6. DirectX Control Panel (CPL) options
+
+
+
+ - Disable and passthru to real DirectX
+
+ As it says, if you want to disable DirectX without
+ removing dgVoodoo's DLLs then use this option.
+
+
+ - Videocard
+
+ You can select between the internal virtual 2D (SVGA)
+ and 3D accelerated cards.
+
+
+ - VRAM
+
+ Onboard videomemory of the selected videocard.
+
+
+ - Filtering
+
+ Various texture filtering modes can be forced here, starting from simple point sampled to high level anisotropic.
+ Keep in mind however that forcing other than the application default can result in rendering glitches, or it can
+ completely break some visual effects!
+
+
+ - No mipmapping
+
+ Disabling mipmappig (forcing largest mip texture level).
+
+
+
+ - Resolution
+
+ Here you can override the application resolution and
+ refresh rate. See detailed explanation of static/dynamic
+ resolutions in the general Readme.
+
+
+ - Antialiasing
+
+ For 3D rendered surfaces you can force MSAA.
+ Option 'Application controlled' is meaningful only for DX8. For DDraw/DX it is equivalent to 'Off'.
+
+
+ - Application controlled fullscreen/windowed state
+
+ Since choosing this state is part of DirectDraw, you
+ must disable this option to control that via general
+ settings.
+
+
+ - Disable Alt-Enter to toggle screen state
+
+ To prevent conflicting with an application built-in
+ Alt-Enter handler.
+
+
+ - Bilinear blit stretch
+
+ 2D bitmap copying can involve stretching in DirectDraw.
+ However the applied stretching filter cannot be controlled
+ via the API and early hw used simple point sampling.
+ It can result pixelated appearance here and there but
+ you can force bilinear filtering which looks cooler for
+ most cases. But, it can also introduce various artifacts
+ especially when colorkeying is also applied during
+ blitting.
+ Try forcing bilinear texture filtering for achieving similar
+ effects for D3D8 games.
+
+
+ - Apply Phong shading when possible
+
+ See technical info.
+
+ - Force vSync
+
+ Forcing vertical retrace.
+
+ - Fast video memory access
+
+ Provides an alternative method for accessing video memory
+ of DX surfaces by the CPU. Try this one if an application
+ renders at a low frame rate.
+
+ - dgVoodoo Watermark
+
+ Similarly to 3Dfx watermark in Glide, you can use
+ dgVoodoo's own one to see if something is driven through
+ dgVoodoo's DirectX.
+
+
+
+
+
+7. Tips and known issues
+
+
+
+ - Always try to run an application with 'application controlled fs/windowed state'
+ and disabled 'Alt-Enter' for the first time. If 'Alt-Enter' is enabled then
+ the wrapper makes some changes to the application window which can cause some
+ applications to miswork or even crash.
+ - Also, always try an application without enabling 'Fast video memory access' for
+ the first time as that method may be unsafe for the application in question, and,
+ unortunately can cause inappropriate working.
+
+ -
+ Upscaling (forcing resolution) for old 8 bit paletted DDraw applications are not
+ recommended. Paletted things and forced resolution don't work well together,
+ but I want to fix it in the future.
+ Upscaling scenes by forcing resolution, where no 3D-rendered objects are presents,
+ has no sense anyway.
+
+ - Forcing vertical retrace is not always a good idea. There are games of which
+ loaders refreshes the screen at maximum speed (without vertical sync) while
+ loading textures, meshes, etc. If vSync is forced to on then it can take ages
+ while it all gets over.
+
+
+
+
+
+
+ 8. Why doesn't dgVoodoo DX emulation start up?
+
+
+
+
+ I got reports about cases with dgVoodoo DirectX emulation not starting up.
+ The story is simple, one copies the DX dll files into the given application folder,
+ next to the executable, makes sure that DX emulation is enabled on the CPL, and in
+ spite of that, when starting the application dgVoodoo isn't utilized at all, dgVoodoo
+ watermark doesn't show up in the corner if the app starts at all.
+ Thanks to the Guys on Vogons, who are helping me a lot, they come out with 2 reasons:
+
+
+ -
+ Some of the DX dlls (ddraw.dll, d3d8.dll) are registered in the KnownDLLs section of
+ the Windows registry. When they are then the operating system always loads the system
+ versions of those dlls. Removing the entries from
+ "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs"
+ is undangerous and can be safely done with Regedit.
+ This issue causes the majority of the problems.
+
+ -
+ A bit marginal but existing problem with DirectDraw is that it can be initialized through
+ Windows' OLE mechanism which identifies objects with GUIDs. The 'GUID-dll name' pairs are
+ also stored in Windows registry but Microsoft switched to absolute dll paths in Windows 8(?)
+ instead of the relative ones present in Windows 7, so the OLE-accessed DirectDraw is always
+ the system one in that case. The registry entries in question can be changed back to relative paths,
+ but since Regedit requires TrustedInstaller privilege level for that, and you have to search for
+ the entries yourself, it is a complicated process, I don't recommend you to experiment with it.
+ Luckily most of the old programs access DirectDraw directly, bypassing OLE.
+
+
+
+ I know that these details are technical like hell, and I don't at all expect an average user to
+ tinker the operating system registry by hand. I just write this info here because I think it's useful for
+ advanced users and experts to begin with. A dgVoodoo tool doing it all would be fine but currently doesn't
+ exist one.
+
+
+
+
+
\ No newline at end of file