=============================================================================== dgVoodoo 2.45: DirectX emulation related stuffs =============================================================================== Table of contents ----------------- 1. Important notes 2. Tested on 3. General overview 4. Some technical info 5. Resolutions and refresh rates 6. About fullscreen and windowed mode 7. DirectX setup options 8. Tips and known issues for DirectX usage 9. Closing words =============================================================================== 1. Important notes ------------------ First of all: NEVER COPY DDRAW.DLL INTO SYSTEM FOLDERS!! ALWAYS USE A LOCAL INSTALLATION FOR A GAME! DirectDraw is a still existing and widely used system component 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 Direct3D7 implementation dgVoodoo: ddraw.dll - Contains all DirectDraw implementations up to version 7 d3dimm.dll - Contains all Direct3D implementations up to version 7 So, dgVoodoo packs all its D3D 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. Tested on ------------ Operating system - Windows 7, 8 Graphic cards: - Intel Graphics: Integrated Intel Atom GPU on a tablet; I tried it with 2 demos and it worked quite well with low resolutions. In spite of that, Intel Graphics is still not recommended in general. - Geforce GT 610: It's a cheap low end card with very tight memory bandwith but the wrapper works well on that. - GeForce GTS 450: Works like a charm. - GeForce GTX Ti560: Works like a charm. 3. 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 setup options) DirectDraw is usable without Direct3D but there are no 3D rendering capabilities exposed to the applications in that case. All the interfaces of old DirectX (so that all DirectDraw interfaces and Direct3D 3/5/6/7 interfaces) are almost fully supported. 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. Two extra video card types are added to utilize different chipset features. 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 supports for full hardware acceleration including 'Transform & Light'. - GeForce4 Ti 4800 - ATI Radeon 8500 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. (Maybe they could be tied to the MS WARP rasterizer to have some nostalgic feeling when trying out some games in sw mode.) DirectX renderer needs less GPU power (for general cases) than Glide renderer but it uses relatively complex 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. 4. 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 that 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. ................................................................................ Internal virtual 3D card has the following 3D hardware capabilities: - Supports 4 texture stages and all texture blending operations and arguments on each of them including bump mapping - 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 and 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 setup) - Supports compressed textures (DXTC1-5) - 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 The other 2 card types are not an exact emulation of the given chipsets with some real ATI/nVidia driver version. They are just present to bias the available rendering capabilities and properties toward a real ATI or nVidia card: GeForce4 Ti 4800 capabilities: - Same as the internal virtual 3D card - No 32 bit z-buffer support - Full cut colorkeying ATI Radeon 8500 capabilities: - Same as the internal virtual 3D card - No 32 bit z-buffer support - Plain colorkeying - No paletted texture support ................................................................................ DirectDraw and Direct3D objects supports all types of rendering devices that are supported in original DirectX. In MS Direct3D 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. Phong shading (so that 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 setup 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. 5. Resolutions and refresh rates -------------------------------- An application using DirectX can only detect available resolutions and associated refresh rates by asking DirectDraw 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) 320 x 240, (X-mode is also supported) 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 to enumerate 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). Whatever you choose from the list, only the refresh rate applies because resolution overriding is not yet supported. If your 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 so. dgVoodoo always handles the refresh rates in their exact rational form but it cannot do that with manually typed ones. If the refresh rate is overridden then all resolutions are enumerated with the overidden value to the applications. 6. 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 is 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 setup. 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 detect when an application begins its rendering and 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, 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-Tab 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. 7. DirectX setup 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. - Resolution: It is disabled in this version, sorry. - Antialiasing: For 3D rendered surfaces you can force MSAA. - 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. - 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. 8. 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. - 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. 9. Closing words ---------------- As for the DirectX wrapper code, it was an awful lot of work to do in a relatively short time but I did my best on testing the whole part of the library functionality, all cases of hw/sw rendering and processing and as much combinations of them as possible. I "was forced" to write tons of own test code for reverse engineering as well as testing my own implementation. Sometimes I had luck because my real work required to solve some problems needed in the wrapper too, so I could even utilize worktime for the Greater Good. (but don't want my boss to become aware of that.) :) In spite of that this version may contain untested cases that I haven't come across yet, causing bugs or crashes. Also, there are a lot of TODOs in the source which are not so important to fix but I want to do that later to make the wrapper as perfect as possible. I hope this all will get mature incrementally by releasing new versions. By the way, I found some nice old DirectX scene demos for testing: - Stuff I whacked together when I was bored by Trauma http://www.pouet.net/prod.php?which=473 - Slavery by Fairlight http://www.pouet.net/prod.php?which=1020 - Explicit Supremacy by Apocalypse Design http://www.pouet.net/prod.php?which=1541 - Trial 1985 by Armada http://www.pouet.net/prod.php?which=7216 - Blue by Realtime MultiMedia Design http://www.pouet.net/prod.php?which=15879 - Flashback by Void Main http://www.pouet.net/prod.php?which=5547 - Al Castone by The Moose Brothers http://www.pouet.net/prod.php?which=4333 Surely there are more but I didn't root out all of them.