dgVoodoo v1.31 by DEGE, 2004 ============================ dgVoodoo is a Glide Wrapper that implements Glide 2.11 and Glide 2.43 using DirectDraw7 and Direct3D7. dgVoodoo provides support to run Windows-based and DOS-based applications that use Glide. DOS applications can only be wrapped without VESA emulation under Windows XP. ----------------------------------------------------------------------------- I. Requirements and files of dgVoodoo II. Files of dgVoodoo 1.31 III. General tips for dgVoodoo IV. What's news in 1.31 V. Installation VI. Technical notes (you can skip this section) VII. Running DOS programs under Windows XP VIII. Accessing the LFB IX. VESA (only for Win9x/me) X. Resolution setting XI. Screen capturing XII. Using dgVoodooSetup ----------------------------------------------------------------------------- I. Requirements --------------- - Windows 95/98/Me/2000/XP for Windows applications - Wndows 95/98/Me/XP for DOS applications - DirectX 7.0 or greater - what else important to write here? Idonnow ==================================================================================== IMPORTANT: because of unknown reasons, dgVoodoo does not work with ATI Catalyst 4.7 and newer versions when using DOS-glide (and probably neither it will do it in the future)!! If you are lucky it may work for you in server mode but I must say the following to avoid any damage: use this shit only for your own risk !!! ==================================================================================== II. Files of dgVoodoo 1.31 -------------------------- glide.dll - Glide 2.11 driver for windows-based applications glide.ovl - Glide 2.11 driver for DOS-based apps (see remarks on it!) glide2x.dll - Glide 2.43 driver for windows-based applications glide2x.ovl - Glide 2.43 driver for DOS-based apps dgVoodoo.exe - Glide server process for DOS-based apps dgVoodoo.vxd - Kernel module for DOS-based apps dgVoodooSetup.exe - Setup program dgVoodooSetup.exe.manifest- Copy this file along with dgVoodooSetup.exe if you want setup to show up in XP-style readme_eng.txt - dgVoodoo documentation, english version readme_hun.txt - dgVoodoo documentation, hungarian version III. General tips for dgVoodoo ------------------------------ - If you have an ATI card, it stands a fair chance it doesn't support w-buffering. In this case use the W-buffer emulation instead!! This kind of emulation however is not perfect, so prepare for artifacts! :( - When your screen is flashing, try to use the wrapper with "closer to a real hardware" option enabled. Flashing occures when a game unexpectedly behaviors and the wrapper locks the LFB in a very optimalized way (most likely in 16 bit full screen). - If you start a DOS game, and the glide-window appears, and then nothing happens, try to run that program with unhided console window. It's possible the game exits with an error message, but you cannot see anything because the console window is hided. - If you want the smoothest animation try to set the refresh frequency to the closest one to the desired freq (see setup) - Automatically generated mipmap levels can cause serious artifacts, so it is not recommended to use it in general. Missing levels are generated by resampling the original texture and it means colorkey-pixels are likely to be recoloured to something different color around a given shape. Alpha values can also be modified in a wrong way if an application uses alpha testing. Furthermore, when an application refreshes certain textures continuously, speed can be degraded due to calculating all the levels every time. - I think all of Glide 2.11 DOS-applications have their Glide libraries statically linked (according to the Glide 2.11 SDK). However file glide.ovl is only usable by dynamic linking, altough I myself don't know of any program using it in this way. That's why this file exists but isn't included in this version. IV. What's new in v1.31 ----------------------- - Support for Glide 2.11 - LFB handling is rewritten, it means new converters, etc. This version supports write formats RGB565, RGB555 and ARGB1555 natively. - Earlier solutions for multithreading issues could (and did) cause problems like in Red Baron 3D, it's now fixed (at least I hope it's indeed fixed) - Some minor bugs fixed - When switching to another application by alt-tab, then back, texture corruption may occure. For example, my videodriver doesn't set the "state" of textures to "lost", in spite of part of the videomemory they reside in is unambiguously overwrited. To avoid this, dgVoodoo reloads all the textures when they are first used after the cooperative level is got back (Windows applications themself may notice swithcing by alt-tab and don't call Glide functions until you don't switch back, thus, reloading won't work). - Default texture filtering is "point sampled", not bilinear filtering. - Setup behavior is slightly changed: since driver 2.11 can also be configured now, setup provides a list for instances of wrapper files. At startup it put all the files found into this list but you can add more instances by "Search", "./" and "Win dir" buttons. Actually, both of the platform configurations are read in (and written out!), so none of them is lost when selecting between the two platforms (losing is an old behavior, it was inherited from old version setups when Windows and DOS configs were placed into two separate files). - Bugfixing, for example screen saving does not work in previous version, etc. - Saving and loading configurations from/to setup (right click, menu) - Sure there are some more slight changes, but I can't remember them V. Installation --------------- Overwrite each components if you have the earlier version! Don't mix them, they are not compatible! If you don't want to use this wrapper, or/and you just would like to try it with a certain game/app, then you can copy the needed files into the directory of that game/app! Installing dgVoodoo to run Windows apps --------------------------------------- Just copy file GLIDE2X.DLL into your windows directory (usually C:\WINDOWS). After doing this, win apps should work. NOTE that it is importrant to make sure you do not have any file named GLIDE2X.DLL in the directory of the application you wish to run (from other wrappers). Installing dgVoodoo to run DOS apps ----------------------------------- Windows 9x/Me ------------- Copy the following files into your windows directory: DGVOODOO.EXE, DGVOODOO.VXD, GLIDE2X.DLL, GLIDE2X.OVL If you installs Glide 2.11, copy following files into the application directory: DGVOODOO.EXE, DGVOODOO.VXD, GLIDE.DLL, GLIDE.OVL Usage - - - After needed configuring, start DGVOODOO.EXE. If any error occures during initialization you get a message box with the proper error message. If server finds both Glide 2.11 and Glide 2.43 drivers it offers a choice to select the one you wish to run. If server starts successfully, nothing more to do, you can run your DOS applications. NOTE that it is importrant to make sure you do not have any file named GLIDE2X.OVL in the directory of the application you wish to run (from other wrappers). Windows XP ---------- Copy the following files into your windows directory: DGVOODOO.EXE, GLIDE2X.DLL, GLIDE2X.OVL If you installs Glide 2.11, copy following files into the application directory: DGVOODOO.EXE, GLIDE.DLL, GLIDE.OVL Usage - - - If you configure dgVoodoo to work as a VDD, you should not run serverprocess, you just run your DOS-programs. If you use dgVoodoo in server mode, then start the server (DGVOODOO.EXE) and run your DOS-programs. NOTE that it is importrant to make sure you do not have any file named GLIDE2X.OVL in the directory of the application you wish to run (from other wrappers). Installing setup program ------------------------ Copy file dgVoodooSetup.exe to your windows dir, and put its icon to the desktop. VI. Technical notes ------------------- - Option "closer to a real hardware" is automatically enabled when Glide 2.11 is used, because of maintaining the Voodoo1-compatibility. It means that stride (AKA pitch or logical line length) for LFB operations is always 2048 bytes, and read/write pointers to buffers are "constant" (for particular formats). - A hidden option, "No matching LFB formats" are also automatically enabled for Glide 2.11 to avoid buffer pointer mismatch problem. In fact, this prevent dgVoodoo from using directly any of its internal optimized buffers in order to read/write pointers of a particular buffer always point to a certain memory area (this is important in Glide 2.11). - "No matching formats" is also enabled when you use the wrapper for DOS programs under WinXP in server mode. This is because matching lfb formats means using directly one of the internal buffers residing in the video memory. Thus, the DOS program and the locked buffer would be in separate address spaces. Note that when "no matching formats" is enabled, there is no extra conversion from the format to the same format, just a raw copy is done. VII. Running DOS programs under Windows XP ------------------------------------------ dgVoodoo can run DOS programs in two modes under Windows XP: - VDD mode: in this case, wrapper file (glide2x.dll) is attached directly to the NTVDM process running the DOS program as a VDD (Virtual Device Driver). You can avoid running the serverprocess, the application and the wrapper share the same process and address space like Windows applications. Also, more than one applications can use the wrapper simultaneously (for the time being, with the same configuration). - Server mode: in this case, you have to run the server process, like for Win9x/Me. Disadvatages: since the application and the wrapper run as two separated processes in separate address spaces, dgVoodoo can't utilize matching LFB formats (it considers them as if they were always different), server can serve only one DOS program. You should try this mode if have troubles with VDD mode. You can also run DOS programs in the background, but be careful! In certain cases, when cooperative level changes (e.g. when a DOS program is being run in full screen, but you changes to an other application), some of the Glide-functions cannot be called without fail. This means that a game may quit with an error message, etc. VIII. Accessing the LFB ----------------------- Accessing Linear Frame Buffer means reading and writing directly from/to video memory. If an application accesses LFB directly then a conversion has to be done between the (one of the) 3Dfx format and the actual format of the DirectDraw buffer if necessary. The main problem here is that the DirectDraw buffer must be read (for the conversion) in most cases even if the application wants only to write to the LFB. Format conversion is fast enough, no significant performance penalty, but reading video memory itself is extremely slow. dgVoodoo tries to avoid this by caching the buffer content but there are a lot of cases when caching is not usable. It is possible that both format are the same in case of a 16 bit screen mode. If so, no need to do any video memory read and conversion. However when another resolution is applied than the app's default, video memory needs to be read for rescaling, so that accessing LFB slows down. This version is able to utilize hardware buffers to speed up video memory reading (this is done by the video card itself). Note that this can still slow down if an application locks the LFB several times per frame when the cached buffer content is useless. Even the video card has no unlimited speed. You may have some troubles with hardware accelerating in special cases (depending on your video card). In this case turn off hardware accelerating, using software reading as it was done in previous versions. If there is not enough video memory, no hardware accelerating at all (but this is very improbable on modern video cards). NOTE: Under Windows XP, if you run DOS programs in server mode, the wrapper cannot utilize matching LFB formats, see technical notes for more. However, you can still use the fast writing described in the following. You can use fast writing for unmatching formats from v1.15. This method may issues in artifacts in special cases. This method doesn't need videomemory to be read for conversion, except when you specify another resolution than the application set. In this a case videomemory is read because of rescaling, but this can be done by hardware (just like when formats are the same) if hardware accelerating is enabled. Version 1.15 and newer ones contain an additional option to provide such buffer features that are closer to the features of a real Voodoo hardware. This is independent on whether hardware accelerating is used or not. This option is used for applications that are not programmed according to the Glide specification and utilize the features of the real hardware (e.g. Extreme Assault). This option does not confuse other programs but eats up more memory and provides slower buffercontent caching, so do not use it if not needed. NOTE that this option is automatically enabled when using Glide 2.11 to keep compatibility of Voodoo1. Another thing to ponder: there are applications that accesses the LFB in a manner when pixel pipeline is active. The wrapper locks the buffer but cannot emulate this effect. This means that e.g. certain things will not be transparent when they should be transparent, etc. IX. VESA (only for Win9x/me) ---------------------------- This version is capable to emulate VESA 2.0 interface. This can be used only if serverproc is running (like in case of glide) and only in DOS-boxes created when serverproc is running. VESA emulation can be run in either windowed or full screen mode altough you should use the original VESA-driver in full screen mode (except for screen capturing). dgVoodoo supports all modes from 320x200 to 1280x1024 in 8, 16 and 32 bit. 320x200x256 color is a standard VGA-mode which can be enabled. Known problems about VESA: - dgVoodoo reports VGA-compatibility altough its compatibility is restricted to the palette registers and the vertical blank (3DA) register. It means X mode cannot be emulated, etc. - If you use dgVoodoo for VESA in a DOS box, then you stop it and use the original driver, you will probably see a messy screen. This is because dgVoodoo overwrites the memory mapping for videomemory set up by VDD (Virtual Display Driver) and cannot fully restore it. In this case close that DOS box and use another. - VESA init can fail when you start the serverproc. The memory area used as videomemory is allocated when kernel module is loaded into the kernel. (When it is unloaded, this memory area is released.) Normally the kernel module behaves as a dynamic VXD. It means it is loaded and unloaded to/from kernel by the serverproc. The main problem is the videomemory has to be physically continuous but Windows cannot provide it if bulk of the physical pages are messy-allocated for running applications. If you want, you can insert the following line in SYSTEM.INI into the [386Enh] section: device = glide2.vxd In this case kernel module is used as a static VXD, so it is loaded into the kernel during Windows startup. It reserves 2MB as videomemory (because it cannot read the current configuration) and releases it when Windows shuts down. X. Resolution setting --------------------- If an application does not allow you to set the required resolution you can do it by dgVoodoo. If an application accesses the LFB frequently then video memory has to be resized but it can be accelerated by hardware. This was always done by software in previous versions. You can use all of the resolutions supported by your video card. XI. Screen capturing -------------------- You can save the content of the screen into a file or to the clipboard. You can do it by pressing the "Pause" button in case of Windows apps and DOS in XP, and "Scroll Lock" for Win9x/Me DOS. I know it should be done by the same button for all platforms but I cannot solve it (temporarily). The result of the saving operation can be seen on a green label in the middle of the screen except when you are in an 8 bit full screen mode because the label cannot be drawn by the 3D hardware. If the screen is saved into a file, the name of the saved file is the same as the application's concatenated by an ordinal number. It is saved to the "Temp" directory on the same drive where the application is. If the name of the application is unknown (only in DOS) then filename is C:\Temp\dgVoodoo_xyz_.bmp where _xyz_ is an ordinal number. The saved file is 8 bit (full screen, VESA), 16 or 32 bit depending on what the bit depth of the used videomode is. The saved file is always saved as a BMP file and dgVoodoo is not intended to support any other format in the future. Just save the screen then convert it to whatever you want. XII. Using dgVoodooSetup ------------------------ dgVoodoo does not have a configuation file from which it reads the actual settings. Settings are stored in GLIDE2X.DLL and GLIDE.DLL instead. The setup program needs these file as well. Setup program organizes setup options on three pages. Page "Global" contains options that affects both the Glide and VESA emulation. Page "Glide" contains options for Glide. Page "VESA" contains option for VESA. Let's have a look at the setup-dialog: Platform Here you can select the Win or DOS platform to configure. Language / Nyelv You can select a language to setup in, and which the wrapper itself uses. Instance of dgVoodoo In this list you can see the names of wrapper files to be configured. By default, setup searches for such files in the current directory, but if none is found, it does it in Windows directory. You can add additional wrapper files to the list by "Search" button. "Win dir" and "./" button adds files from Windows and current directory if any is found there. Normally, you needn't deal with this field. Below this field, you can see the actual page. You can select between pages by the tabs. Page "Global" ------------- Display device You can select which screen adapter to use. Display driver You can select which rendering driver to use. (dgVoodoo will probably work unproperly with software drivers, but I think that's not a big pain. :) ) Screen mode You can select between full screen and windowed mode. Screen bit depth You can set the bit depth of full screen mode. In windowed mode bit depth is determined by the actual settings of the desktop. These settings can be seen above the tabs. If it is not compatible with dgVoodoo (so that it is not a 16 or 32 bit mode), you will be warned. 16 bit mode can be useful for fast LFB accesses. Screen capturing on You can enable the screen saving here. Saving to file You can enable saving to file here. Saving to the clipboard You can enable saving to the clipboard here. Hide console Only for DOS: Hides the console window of the application. Set mouse focus to application Only for DOS: If application is running, mouse focus is set to the application. You can use the mouse by enabling this option. Enable Ctrl-Alt If enabled, you can release mouse focus from DOS box. Working in VDD mode Only for DOS under WinXP: you can set VDD mode here. Active in background Only for DOS under WinXP: by enabling this option, DOS programs runs in the background too. Page "Glide" ------------ DirectX textures bit depth Bit depth of textures used in Direct3D. dgVoodoo can use the following texture formats (arbitrary component order): - 16 bit ARGB_4444 - 16 bit ARGB_1555 - 16 bit RGB_555 - 16 bit RGB_565 - 32 bit ARGB_8888 - 32 bit RGB_888 - 8 bit P8 At startup, it puts all the texture formats supported by your card into a list. When dgVoodoo has to decide what format to use for a particular 3Dfx format (best fit) it select it from the list. Options meaning: - 16 bit: select from only 16 bit formats - 32 bit: select from only 32 bit formats - Optimal: select from any format including paletted (8 bit) textures Refresh rate Monitor freq is the closest supported freq: At init every glide based application gives the resolution and refresh rate at which it wants the monitor to work. If this option is enabled, the wrapper automatically selects one of the supported freqs that is closest to the freq given by the application. (However in practice you shouldn't use this because most of the applications wants freqs 60-70hz, and you can use higher ones (>=85Hz) if they are available). If this option is disabled, the monitor freq will be the one the user selected. (Default=real value is determined by the driver of video card, usually it means the highest supported freq) Refreshing: refreshing is aligned to the real vertical sync, maybe using different freq than the application required (first option), or refresh is also restricted to the freq application required (second option). This can cause flickering because certain frames may not be rendered. Summarized: - If you aren't interested in using the same freq that the application requires (general case), then DON'T let the wrapper set the monitor freq to the closest supported one and use the first option for refreshing. - If you ARE interested in using the same freq (rare case, altough this mode is recommended for smoothest animation), then use the second option for refreshing. - If this causes an ugly flickering then let the wrapper set the monitor freq to the closest supported one, and use the first option for refreshing. (If you are lucky, real freq will be close to the required freq.) - It's no use to set the mon. freq to the closest supported one and restrict refreshing to the freq given by the applicaton. Always wait for vertical sync: Waits for at least one vertical retracing even if an application doesn't demand it. It can be useful for applications not synchronizing themselves to the refreshing ending up in running too fast on modern computers, or rendering artifacts such as horizontal refresh-lines. Depth buffering What to do if an application tries to use W-buffering? - enable W-buffering (first option) - emulate W-buffering using a Z-buffer These options were brought in because W-buffering worked improperly in previous versions. Now true W-buffering should work. When W-buffering is emulated (and even in true W-buffering) you may notice some artifacts due to the large distance (Zfar) used for W-buffering. LFB access - Disable LFB access Accessing the LFB can be a slow operation. If you disable access in this check box, applications still has the sense they access the LFB but in fact they access an unused buffer instead. Because of it the appearing may not be complete (and can be bad if reading) but the application can run at max speed. - Use hardware cache buffers when possible If both the 3Dfx and DirectDraw buffer format are the same then you can utilize the video card to read video memory (using hardware buffers) - Use fastwrite for unmatching formats Enables using a fast method for unmatching formats. For more, see "Accessing LFB". - Rescale changes only If different resolution is used than the application set, then only written out pixels are rescaled (not whole buffer) in case of writing. This prevent image from blurring. This method can only be used with fastwriting. If lfb formats are the same, fastwriting will be forced. - Closer to a real hardware LFB has such properties that are closer to the LFB properties of a real Voodoo card Note: if an application tries to read/write the aux buffer when it is used as a depth or alpha buffer, then it will always manipulate the unused buffer (locking depth and alpha buffers are not implemented yet :-| ). Resolution You can override the the resolution of an application here. This list contains all the supported resolutions. Refresh rate You can set the refresh freq of your monitor here. You cannot do it if you use the wrapper in windowed mode or monitor freq is set to the closest supported one. Texture memory size Size of the emulated texture memory. Perfect texture memory emulation You can enable perfect texmem emulation by this option. When it is enabled, the wrapper can use exactly the same mipmaps that are required by the application. In this case texture reallocating and reloading is always done automatically if needed. If you disable this option texture memory emulation is done in the same way as in previous versions. Disable mipmapping If you don't like mipmapping in a game, you can disable it, falling back to using only the first mipmap of textures. Force trilinear mipmapping Interpolating between the levels of mipmaps (This was a hidden option in 1.23.) Autogenerate mipmaps If a mipmap consists of only one level, missing levels are generated. This option does not override multilevel mipmaps. Force bilinear filtering You can force textures to be always blurred. Gamma correction You can set the gamma correction between 0% and 400%. This also works in windowed mode! Colorkeying method Colorkeying is the effect when pixels that matches the colorkey are not rendered. You can select between three methods for colokeying: Method 1: this method is a special alpha based colorkeying for TNT cards only (TNTs implement their cking on an alpha based conception, working under special circumstances only) Method 2: General colorkeying method using the native colorkeying of cards Alpha based: General colorkeying method using alpha testing and shadow-textures as alpha channels Method 1 and 2 use the native colorkeying capability of the videocards. If it cannot be got to work or give ugly results, you should try alpha based colorkeying. Alpha based colorkeying is the closest to the real Glide-colorkeying and it should give the same results on every video cards. Disadvantages: this method cannot provide colorkeying at all if alpha testing is enabled (this is not true for v1.21 and versions above 1.21). Also, wrong results may be produced if special alpha blending modes are used. Force triple buffering You can force the wrapper to always use three buffers for animation. This can speed up things, but also can produce wrong appearance if the application uses the content of previous frames. Fix TR's shadow-problem You can avoid the no-shadow problem in Tomb Raider 1. Don't use this option when using another Dos-program. Clipping by Direct3D If an application doesn't do its own geometry clipping but make the wrapper do it, clipping is done by Direct3D in 3D (altough Glide supports only 2D clipping) if this option is enabled. However you may have troubles with 3D clipping (like in Red Baron), in this case try out the own 2D clipping algorithm of the wrapper by disabling this option. (2D clipping is not perfect for polygons with negative W-coordinates...) Enable using hardware vertex buffers If this option enabled, dgVoodoo puts all the geometry data directly into the hardware buffer of video card, avoiding extra copies. However this also can cause problems, so I let you disable it. Page "VESA" ---------- This page is used only for DOS. Use built-in VESA support You can enable the VESA emulation. Refresh frequency Refresh freq. You can get smooth animations at higher freqs, but be careful: refreshing the screen is time-consuming so the higher the freq the more time is spent on refreshing, the less time is left for the program for running. Emulated video memory Size of the video memory (see related problems). Size of mem should not be smaller than a particular video mode requires. Mode 13h support You can enable emulating the standard 320x200 256 color VGA-mode. You can save your settings by pressing button "OK", while "Cancel" quits without saving. Focus problem --------------- If serverproc loses the focus, it suspends the served DOS box and wakes it up when it gets back the focus. In some cases the serverproc gets the focus but Windows does not send any message about it so you have to inactivate and reactivate the window of the serverproc manually. In full screen, you can do it by moving the invisible mouse cursor to the edge of the screen and resize the window (when mouse focus is not set to the DOS-box). In certain cases it can be very annoying that mouse focus is set to the DOS box. For example, when you run the program in windowed mode, you can't resize the window severely. However, if Ctrl-Alt is pressed, mouse focus is released from the DOS box. If you click on the window, it gets back the focus. Dege If you want to contact me feel free to send an email to "slonderin@freemail.hu" ----------------------------------------------------------------------------------- Development of previous versions Fixings in v1.30c ----------------- - Minor modification, which gives back missing textures in POD - Fixings of multithreading issues had no effect under Win98/Me, fixed Fixings in v1.30b ----------------- - Real paletted textures shared one palette which caused noticeable performance penalty. I have changed the code and each texture has its own palette object now. This thing only affected Geforce cards (and maybe Volaries, if they support paletted textures, but I know nothing about it). - Some minor things I forgot to implement in 1.30, e.g. using lod bias from DOS or with utility textures. What's new in v1.30 ------------------- - New lfb-writeback method (previous versions worked in stupid-mode a little bit) - Missing Glide-functions are present now and some of them are implemented - Multibase texturing is supported - Some multithreading issues are fixed - Lfb-access can be disabled in a new way, only for read, only for write or for both (can be useful for e.g. Screamer2) - Bit depth of depth buffer is always the highest possible one (this was always equal to the bit depth of the color buffer in prev. versions because older cards only supported this configuration) - Delta0 mode is implemented - Two hidden option are available in setup (see setup) - Autogenerating mipmaps - A lot of internal changes, fixes and rewrites, making a lot of thing simpler (in fact this is what is reflected in the version number jump) What's new in v1.23 ------------------- - mouse support is added for DOS programs under WinXP - XP-DOS IRQ and speed problem is moved to a better solution - improved buffer locking to make it compatible with Carmageddon - bugfixing - and making new bugs, they will come out right after I release this version, making me release a new 1.23b version or something like that What's new in v1.22 ------------------- - Color, alpha and texture combining are completely rewritten and improved - supporting AP88 and AYIQ8422 3Dfx textures directly via the new multitexturing system if your videocards supports paletted textures (GeForce) and have enough video memory Thus, certain games doesn't slow down due to continuous reloading of textures caused by continuous palette altering (e.g. Blood) - Depth bias is implemented (thank Zeckensack for the info, I hope now it works properly) - Some bugs fixed Note: depth bias can't be emulated perfectly when you use w-buffering emulation so don't expect too much (since the w-buffering emulation itself isn't perfect). What's new in v1.21 ------------------- This version is mainly intended to be a bugfix version of 1.20: - IRQ-problem coming out using WinXp for DOS programs is fixed - LFB can be locked for reading and writing simultaneously when fast writing is used - Backface culling bugs fixed - Handling properly YIQ-tables (9 bit) - Bugs in the vertex converters - Alpha based colorkeying can provide colorkeying at a cretain degree if alpha testing is enabled - Refresh frequency can be selected for each resolution What's new in v1.20 ------------------- - Experimental Windows XP support for DOS programs - Perfect texture memory emulation: if you enable it, the wrapper maintains a copy of the full texture memory, and can update its internal texture cache according to it when needed. This is brought in because when the wrapper has only a texture cache it is hard to figure out that exactly what textures are used by the application. This is a problem when e.g. a particular mipmap is downloaded in more parts, by its mipmap levels (like in Unreal, Unreal Tournament). When perfect tex. mem. emulation is in use, reallocating and reloading of textures is done automatically. Note that multibase texturing is not supported in this version. - Mipmapping can be disabled. - Internal texture cache can hold large enough number of textures, so "number of textures" option has been dropped. Size of texture cache is dynamically changed. - Setting a gamma-ramp via Glide is now disabled. This is because I noticed that default gammaramp (which is linear) can be too dark, it is better to use the original ramp set by DirectX. However, you can enable it, if you need it. - Option "Disable W-buffering" has been dropped, it's no use. - New colorkeying method added: Alpha-based colorkeying is not based on the native colorkeying of the video card but on alpha testing. The wrapper uses shadow-textures to achieve this. This method should produce the same result on every videocards, and it is much closer to the real Glide-colorkeying. However, there are some disadvantages of it: this method cannot provide colorkeying at all if alpha testing is enabled. Also, wrong results may be produced if special alpha blending modes are used. - Own 2D-clipping algorithm is implemented (as described in the SDK). You can decide whether to use DirectX for clipping or not. Sometimes you can have troubles with DX (it clips in 3D), but you can try out clipping without DX. Note that 2D-clipping can also fail since 3D-clipping is required when an unclipped triangle with negative w coordinate(s) is passed. - You can decide whether to use hardware vertex buffers or not. This was always used in some of the previous versions. Since it can cause problems, I let you to disable it if you want. - Support for paletted textures: if your videocard supports paletted textures (so that you have a GeForce card) and texture bit depth is set to "optimal", the wrapper uses paletted textures for textures with 3Dfx formats P8 and YIQ422. - At start Setup searches for the wrapper file in the current directory. If it doesn't find the wrapper file (glide2x.dll) then it searches it in the Windows directory. - usual bugfixing - probably I've made a lot of new bugs And thank all of you very much for testing dgVoodoo betas with Red Baron 3D!! Version 1.15b is the same as v1.15 with one fatal and some minor bugs fixed. What's news in v1.15 -------------------- In fact, nothing interesting news. This version is released only because the developing is going to be suspended for about 6 months, and I wanted this version to reflect the current state. - LFB-access: fast write for unmatching formats - Texture handling: 3Dfx texture formats yiq422 and ayiq8422 are supported Paletted textures (without alpha) are utilized if your videocard supports them (not tested) - DOS: mouse focus can be released by Ctrl-Alt - Bugfixing (At the back of my mind I think I've done something else too, but I can't recall now.) What's news in v1.14 -------------------- A lot of bugfixes: - Texture handling and converting functions - Proper handling of AP_88 3Dfx texture format, reading textures with table (palette) from 3DF file - Alpha blending, color & alpha combine functions - VESA emulation - Minor bug fixed in LFB handling - Function grDepthBias is unimplemented now (worked improperly) - W-buffering error is fixed so it should work (see "Depth buffering"), but the chance for emulation is left The wrapper can run Blood. You'd better to turn on VESA emulation to run Blood otherwise it may crash Windows because of uncleared reasons. What's news in v1.13 -------------------- - Improved LFB accessing speed and techniques (see "Accessing the LFB" section) - Using hardware vertex buffers when available - Some internal bugs fixed (fog, grBufferClear, etc.) This version is not tested so intensive than previous versions! If something won't work, try to use v1.12! What's news in v1.12 -------------------- Bugfixes for v1.11: - Method 2 for colorkeying does not work in v1.11, fixed (this should work for GeForce cards now, except under certain circumstances) - if larger resolution is used than the app's default, lines are drawn with proper thickness - errors related to the label for screen capturing, fixed - errors in the setup, fixed - Language selection now affects not only the setup but the language used by the wrapper itself What's news in v1.11 -------------------- This version is intended to be a bugfix version for v1.1, so nothing substantive news: - Failing full screen init is fixed - Internal conversions: all the work is done by GLIDE2X.DLL, so the serverproc needs it (and this file is required for setup too). Main reasons: easier to develop and easier to adapt it to the future XP version. - a few more setup options, one of them existed internally in the previous versions (I did not talk about it): Glide calls of Tomb Raider 1 is messy a bit for me... Lara has no shadow and the background of the text is not dark by default. I spent a lot of time on debugging and thinking about it and now I think this problem is not caused by the wrapper. (However I can't beleive that TR1 runs buggy on a real Voodoo card, altough I have never seen it.) One of the new options can avoid this problem but also can confuse other Dos programs. - Setup can be done in hungarian - A few screenshot about dgVoodoo is added What's news in version 1.1 --------------------------- - VESA emulation for DOS - Resolution setting - Screen capturing - Internal optimization, improved rendering - other things