The new OverrideStencilFormat and DdrawOverrideStencilFormat settings help reduce GPU power usage and fix games!

[the-burrito-triangle]

So I was playing the Might & Magic 6, 7, 8 merge mod and ran into an annoying issue with 2D assets like trees flickering while moving due to clipping on 3D objects. Using dxwrapper, I managed to fix the clipping issue by forcing the game to use D3DFMT_D24S8 with DdrawOverrideStencilFormat = 75 (but 77 for D3DFMT_D24X8 also works). The game defaults to D3DFMT_D16 (80) and I think this is why the 2D assets run into clipping issues with the surrounding 3D environment.

With that success, I also tried this with Warcraft III The Frozen Throne (classic game from 2003, not the remake) using OverrideStencilFormat = 75. And I saw a decent drop of 2 to 3 watts of GPU power (14 to 15 watts reduced to 11 to 12 watts) on my laptop iGPU when playing at 60fps with 3840x2160 resolution. This game also uses D3DFMT_D16 by default but works fine with D3DFMT_D24S8. I think modern GPUs and drivers prefer 32bit surface formats for performance, so forcing the game to use one can actually result in better performance.

For anyone who want's to look into this more, here's a link to the various D3D9 surface formats:
https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dformat

And this page is a good read too:
https://aras-p.info/texts/D3D9GPUHacks.html

Anyways, dxwrapper keeps getting better and better from my testing. And now has features that even dgvoodoo doesn't have.

My only issues with dxwrapper is that, on a few 3D DDraw games, the antialiasing setting tanks performance and some games exhibit erratic spikes in frametimes at high (3840x2160) resolutions when compared to dgvoodoo. I haven't noticed any issues when using it with D3D8 or D3D9 games. Otherwise dxwrapper's performance is awesome!

[elishacloud]

and ran into an annoying issue with 2D assets like trees flickering while moving due to clipping on 3D objects.

I just added a feature in the unreleased dev builds you can download from the Actions tab called DdrawClampVertexZDepth. Setting this to 2 may help in some cases. I saw a similar issue with Deus Ex GOTY in one location and this helped even when changing the stencil format didn't.

Anyways, dxwrapper keeps getting better and better from my testing. And now has features that even dgvoodoo doesn't have.

Thanks for the kind words.

My only issues with dxwrapper is that, on a few 3D DDraw games, the antialiasing setting tanks performance

There is not really much I can do about this without using a shader for AA. Currently, I am just enabling the Direct3D9 AA. However, if you set AntiAliasing = 1 then that auto chooses the highest supported AA your card can take. Try setting this to 2, 4 or 8 and see if that helps with the performance.

some games exhibit erratic spikes in frametimes at high (3840x2160) resolutions when compared to dgvoodoo.

Yeah, I haven't done a lot of testing at 4k. There is definitely more I can do to improve the performance here. However, I have been trying to focus on compatibility first.

[the-burrito-triangle]

I'll give DdrawClampVertexZDepth = 2 a try. It's always nice to have more knobs to turn when dealing with quirky game behavior.

I didn't know that AntiAliasing = 1 was even an option (I had just assumed it only took standard power of 2 values). When testing I was using 2 and 4, and to be fair, the biggest issue was the increased frametime spikes, not drop in FPS with AA enabled. dgvoodoo must be using some blackmagic, because enabling AA has almost no measurable impact on performance with 2x or 4x AA (but it is using d3d11 feature level 10.0 which might have better AA algorithms available to it). The frametime spikes when playing at 4k with dxwrapper are seen on both my laptop (i7-1165G7 with iGPU) and my desktop (i9-11900T with AMD RX 7600) so I don't think its a GPU bottleneck issue. Lowering the resolution and disabling AA reduces the spikes significantly when using dxwrapper for this game (M&M 6-8 merge). At 2560x1920 with AA disabled the game plays smoothly on both my laptop and desktop with dxwrapper. dgvoodoo still has slightly better FPS and lower peak frametime spikes, but the clipping issue is pretty distracting so I prefer to use dxwrapper with this game.

Thanks for making dxwrapper! It's honestly shaping up to be an amazing tool to get old games working again on newer OSes and even works great on Linux with Wine and DXVK/WineD3D.

[elishacloud]

dgvoodoo must be using some blackmagic, because enabling AA has almost no measurable impact on performance with 2x or 4x AA (but it is using d3d11 feature level 10.0 which might have better AA algorithms available to it).

Have you tried with the ForceDirect3D9On12 option? Direct3D9On12 is a Microsoft feature, but since it is rendering on Direct3D12 the AA may be faster than Direct3D9's version.

Or, instead of using Direct3D9On12, in the latest dev builds you can try enabling D3d9to9Ex and FlipEx. This is supposed to help with performance.

Lowering the resolution and disabling AA reduces the spikes significantly when using dxwrapper for this game (M&M 6-8 merge).

This makes sense because with dd7to9 I am rendering to a render target and then copying the whole render target to the back buffer. This means copying significantly more data for 4k (about 4x the amount of memory) vs 1080p. I'm not sure what dgVoodoo2 does. It may be rendering directly to the back buffer to avoid this copy. I could do that too, but it complicates a lot of things.

There are other options here. I could render to a texture and then draw the texture to the screen rather than copying it. Not sure if that would speed things up. I can try that at some point, but it would break AA since you cannot do AA on a texture.

Thanks for making dxwrapper! It's honestly shaping up to be an amazing tool to get old games working again on newer OSes and even works great on Linux with Wine and DXVK/WineD3D.

Yes, I am trying to convert the games to native Direct3D9. I'm not using any special or fancy Direct3D9 features that may not work on all cards. In other words, I am trying to make it as compatible as possible.

[elishacloud]

I could render to a texture and then draw the texture to the screen rather than copying it. Not sure if that would speed things up. I can try that at some point, but it would break AA since you cannot do AA on a texture.

I just put a change in that will render to a texture rather than a surface and then draw the texture to the back buffer. This doesn't work when AA is enabled but it improved the performance in some cases by as much as 2x.

dgvoodoo still has slightly better FPS and lower peak frametime spikes,

I put a fix in to preload 3D textures when using color keying. This reduced the low FPS spikes in some games.

One other thing that might help in some games is to enabled the DdrawForceMipMapAutoGen option. Because if the game tries to use a MipMap that hasn't been generated yet dxwrapper will generate it on the fly which can cause a lower framerate while it's creating the MipMap.

[elishacloud]

There is not really much I can do about this without using a shader for AA. Currently, I am just enabling the Direct3D9 AA.

I forgot that a render target surface that uses multi-sample cannot be locked so I created a shadow surface for it. If a game tries to lock or get the DC of a surface when AA is enabled then dxwrapper needs to copy the whole surface to a shadow surface and then copy it back once unlocked.

A lot of older games would lock the render target, so that could be what is causing the slowdown. I might be able to do something here to help a little bit, but this is a limitation of Direct3D9.

[elishacloud]

Ok, try with this build. It should be a bit faster with AA disabled and might be a little better even with AA enabled: dxwrapper.zip

[the-burrito-triangle]

Wow! That is a night-and-day difference! With 4x AA turned on I actually get better performance than with it off now! And frametimes have dropped quite a bit too. dxwrapper is now on par with dgvoodoo with this game. Wild!

[the-burrito-triangle]

Correction! dxwrapper is actually faster than dgvoodoo with this game! I get lower peak frametimes and slightly higher FPS at 4k resolution on my laptop. These recent changes are honestly amazing! It's crazy that it runs better with AA turned on than off. Amazing work man.

[elishacloud]

Wow. I am glad it is working so well for you. My last build had a minor bug. Here is the fixed one. I hope this one works as well for you: dxwrapper.zip

[the-burrito-triangle]

So I tried enabling D3d9to9Ex and FlipEx with AA turned off and EnableWindowMode = 1 but I don't notice any difference in performance with it enabled or not. I could be misconfiguring the dxwrapper.ini or the game though. I do still get large frametime spikes without AA enabled. The new code path for AA is quite performant, providing better FPS and lower frametimes than without AA (at least on this specific game).

My last build had a minor bug. Here is the fixed one.

Thanks, I'll give it a try.

Update:
The new build works great. Thanks!

[elishacloud]

So I tried enabling D3d9to9Ex and FlipEx with AA turned off and EnableWindowMode = 1 but I don't notice any difference in performance with it enabled or not.

Ok. It's best to keep them disabled if they don't help. Best to enable as few options as you actually need.

The new code path for AA is quite performant, providing better FPS and lower frametimes than without AA (at least on this specific game).

Looks like my change to render to a texture isn't what helped the performance. I think I had a bug where dxwrapper was doing a lot of unnecessary work and that is what made the performance faster. Rendering to a texture is actually slower, in some cases.

Here is an update. I hope this makes it run as fast without AA as it does with AA: dxwrapper.zip

[the-burrito-triangle]

Strange, I still get way better performance with AA enabled (higher FPS and much lower peak frametimes).

Here are some screen shots of the difference (this is where the AA helps as the ship has bad aliasing artifacts when moving). My laptop is using Linux with Wine 10.15, DXVK 2.7.1 and Mesa 25.2.3.

With 4x AA

Without AA enabled

[the-burrito-triangle]

At 4k resolution I also see the same behavior (worse performance with AA off).

With 4x AA

With no AA

[elishacloud]

Uh, this is very weird. There are only two things I can think of that may be different between the AA and non-AA modes. Can you try these two builds and let me know if either of them speed up the non-AA mode?

dxwrapper_discard.zip - With this build I set the D3DPRESENTFLAG_DISCARD_DEPTHSTENCIL flag to discard the content of the zbuffer. This may break some games, but it may simulate what AA does in some cases.

dxwrapper_shadow.zip - With this build force shadow surfaces to be enabled. Normally they are only enabled when AA is enabled.

[the-burrito-triangle]

Nice! Setting UseShadowBackbuffer = 1 does indeed fix the issue! I didn't notice a difference with the dxwrapper_discard build. Did I need to enable a setting like the dxwrapper_shadow build?

Without AA:

With 4x AA:

Discard build, no AA:

[elishacloud]

Ok, I added an option called DdrawUseShadowSurface for this. I don't want to force always using the shadow surface because it uses more memory and may not always be faster. Also I prefer to map directly DirectDraw to Driect3D9 and this adds an extra interface to it.

Here is the updated build with this new option: dxwrapper.zip

Note: UseShadowBackbuffer is a different option and should only affect native Direct3D8 and Direct3D9 older games won't use this even if they are converted to Direct3D9.

[the-burrito-triangle]

Note: UseShadowBackbuffer is a different option and should only affect native Direct3D8 and Direct3D9 older games won't use this even if they are converted to Direct3D9.

Oops! I was double checking the .ini before testing the new builds and thought I needed to enable that. Thanks for the clarification.

The new build seems to work great. For whatever reason, using DdrawUseShadowSurface = 1 with this game greatly improves the performance when not using AA. Thanks for helping to resolve this quirk.

[elishacloud]

For whatever reason, using DdrawUseShadowSurface = 1 with this game greatly improves the performance when not using AA.

I guess that for some reason it is slower to Lock a render target than it is to copy the render target to a system memory surface. System memory surfaces can be locked instantly, with virtually no overhead.

Thanks for helping to resolve this quirk.

You're welcome. Glad I was able to help.

[elishacloud]

I remembered why shadow surfaces are faster. Shadow surfaces are used with Blt, Lock and GetDC. Sometimes a game will Blt multiple times in a row. When not using a shadow surface (because of the way dxwrapper handles Blt) it causes Direct3D9 to Lock the video memory surface. This activity is very slow, almost as slow as copying the the whole surface.

With shadow surfaces dxwrapper can copy the surface once to the shadow and then do all the Blt's quickly on this shadow and then copy it back. This makes it much faster than trying to Lock a video memory surface multiple times each frame.

In the latest build I changed it so that Blt and GetDC always uses shadow surface, even if DdrawUseShadowSurface is disabled. This should allow you to get the faster performance even with both AA and DdrawUseShadowSurface disabled.

Here is the latest build: dxwrapper.zip

Note: Later I want to use Draw rather than a shadow surface when the game calls Blt. This should be much faster than using a shadow surface and make both AA and non-AA faster for games like this.

[the-burrito-triangle]

Note: Later I want to use Draw rather than a shadow surface when the game calls Blt. This should be much faster than using a shadow surface and make both AA and non-AA faster for games like this.

Awesome! I'd be happy to test this out when you start experimenting with this.

In the latest build I changed it so that Blt and GetDC always uses shadow surface, even if DdrawUseShadowSurface is disabled. This should allow you to get the faster performance even with both AA and DdrawUseShadowSurface disabled.

Strangely, with this new build, I still get better performance with AA enabled or with DdrawUseShadowSurface = 1. Here are some screen shots:

No AA and DdrawUseShadowSurface = 0

No AA and DdrawUseShadowSurface = 1

4x AA and DdrawUseShadowSurface = 0

[elishacloud]

Strangely, with this new build, I still get better performance with AA enabled or with DdrawUseShadowSurface = 1. Here are some screen shots:

It's possible that this game locks the surface. DdrawUseShadowSurface = 1 is required for the shadow surface to be used when locking.

Also, when DdrawUseShadowSurface = 1 is enabled I set the surface as unlockable. That may speed things up as well. In other words, what you are experiencing is expected for some games.

[the-burrito-triangle]

Makes sense. I'll try testing Dungeon Siege with the new build and see if these changes help there.

[the-burrito-triangle]

Hmmm. Seems Dungeon Siege is broken with dxwrapper. Cursor movement is too fast (way too sensitive), the character creation screen scales the model too large (shows legs only), the intro cut scene (using game engine) is missing assets (flowers) and strangely a tree follows the character when moving around. The GOG supplied ddraw wrapper seems to work okay though.

Edit: dgvoodoo also seems to work fine with this game.

[elishacloud]

Hmmm. Seems Dungeon Siege is broken with dxwrapper.

Ok, I found the issue. MultiplyTransform() was broken. Here is the fixed build: dxwrapper.zip

Cursor movement is too fast (way too sensitive),

I am not seeing this issue. However, it could be because your computer is too fast. You could try setting LimitPerFrameFPS to 60.

[the-burrito-triangle]

That fixed it! The cursor movement is fixed too. (I have a Logitech MX Master 2 set to 3000 DPI so I think that made the original issue worse.)

Amazing work as usual, thanks!

[the-burrito-triangle]

Seems I spoke too soon. If AA is turned on the cursor disappears in the main menu after moving it around and the game will crash when starting a new game or loading a save. With AA off I didn't notice any issues though.

[the-burrito-triangle]

On a high note, dxwrapper makes Total Annihilation work perfectly and draw very little power when playing on my laptop. For comparison, when using cncddraw, the CPU core is pegged at 100% load (even with vsync enabled) and the intro video exhibits scanlines. With dxwrapper I can fix the intro video scanlines and with forced vsync the game draws very little power / load on the CPU. Overall massive improvement. I do find it odd that older Win9x era DDraw games have a tendency to cause really high CPU usage on modern computers.

[elishacloud]

Seems I spoke too soon. If AA is turned on the cursor disappears in the main menu after moving it around and the game will crash when starting a new game or loading a save.

Weird. I am not see any issues here. How are you enabling AA? This is the latest build, in case there was an issue with your last build: dxwrapper.zip

On a high note, dxwrapper makes Total Annihilation work perfectly and draw very little power when playing on my laptop.

That's good to hear.

On a high note, dxwrapper makes Total Annihilation work perfectly and draw very little power when playing on my laptop.

I think it always caused that. One trick you can do to dxwrapper to reduce CPU usage in some cases is to enable both ForceVsyncMode and EnableVSync. This may make the game run too fast, in some cases depending on the vsync you have set in your GPU.

For comparison, when using cncddraw, the CPU core is pegged at 100% load (even with vsync enabled) and the intro video exhibits scanlines.

Yes, cncddraw uses a separate thread for presenting. This allows it to have consistent present calls per second, but can cause more CPU time. dxwrapper only presents when the primary surface gets changed.

[the-burrito-triangle]

I was enabling AA with the dxwrapper.ini when I encountered the issue, but with the latest build everything seems fine. I could have accidentally misconfigured the old dxwrapper.ini without noticing. Sorry for the false alarm.