Closed Trass3r closed 1 year ago
zbuffer is used for Direct3D. Some games add the zbuffer flag but don't use it. However, I looked into Dungeon Keeper 2 in the past and it does require the Direct3D APIs. I plan to support it in the future, but am working to fix the remaining issue with DirectDraw (2D) APIs first. I do plan to get this game working with Dd7to9
but just have not had time yet.
Yep it does use Direct3D 3 for rendering. Though just as a rasterizer. All vertices are pre-transformed.
@elishacloud Actually this already works when patching it just a bit:
Edit: fixed in ea12a2232
With the latest version it doesn't work.
First of all D3DFMT_D24X8
seems to mean dwZBitMask = 0xFFFFFF
(ref).
When patching dxwrapper as follows it shows the loading screen but crashes when it should switch to the game.
diff --git a/ddraw/IDirectDrawTypes.cpp b/ddraw/IDirectDrawTypes.cpp
index b49b171..805c70c 100644
--- a/ddraw/IDirectDrawTypes.cpp
+++ b/ddraw/IDirectDrawTypes.cpp
@@ -605,9 +605,13 @@ D3DFORMAT GetDisplayFormat(DDPIXELFORMAT ddpfPixelFormat)
{
return D3DFMT_D16;
}
- if (ddpfPixelFormat.dwFlags == DDPF_ZBUFFER && ddpfPixelFormat.dwZBufferBitDepth == 32 && ddpfPixelFormat.dwZBitMask == 0xFFFFFF00)
+ if (ddpfPixelFormat.dwFlags == DDPF_ZBUFFER && ddpfPixelFormat.dwZBufferBitDepth == 32)
{
- return D3DFMT_D24X8;
+ if (ddpfPixelFormat.dwZBitMask == 0xFFFFFF)
+ return D3DFMT_D24X8;
+
+ if (ddpfPixelFormat.dwZBitMask == 0xFFFFFFFF)
+ return D3DFMT_D32;
}
if (ddpfPixelFormat.dwFlags == (DDPF_ZBUFFER | DDPF_STENCILBUFFER) && ddpfPixelFormat.dwZBufferBitDepth == 32 && ddpfPixelFormat.dwStencilBitDepth == 8 &&
ddpfPixelFormat.dwZBitMask == 0xFFFFFF00 && ddpfPixelFormat.dwStencilBitMask == 0xFF)
@@ -724,7 +728,11 @@ void SetPixelDisplayFormat(D3DFORMAT Format, DDPIXELFORMAT &ddpfPixelFormat)
break;
case D3DFMT_D24X8:
ddpfPixelFormat.dwFlags = DDPF_ZBUFFER;
- ddpfPixelFormat.dwZBitMask = 0xFFFFFF00;
+ ddpfPixelFormat.dwZBitMask = 0xFFFFFF;
+ break;
+ case D3DFMT_D32:
+ ddpfPixelFormat.dwFlags = DDPF_ZBUFFER;
+ ddpfPixelFormat.dwZBitMask = 0xFFFFFFFF;
break;
case D3DFMT_D24S8:
ddpfPixelFormat.dwFlags = DDPF_ZBUFFER | DDPF_STENCILBUFFER;
D3DFMT_D24X8
seems to meandwZBitMask = 0xFFFFFF
Actually it can be both:
And 32bit zbuffer handling is missing in more places like https://github.com/elishacloud/dxwrapper/blob/6be80570acfcfd2b6f8e0aec1ed250dd96f5be5c/ddraw/IDirect3DX.cpp#L751
@Trass3r, thanks for your help here. I think the zBuffer issues should be addressed now.
I'll need to check again, I recently fixed something locally about it. It was falling back to 16bits zbuffer cause of some wrong mask iirc. But otherwise they seem to be fixed. The game still crashes later due to the Lock issue in the followup ticket though.
@Trass3r, thanks for all your comments here! I have cleaned up the code and added support for all the different types of zbuffers. This last check-in should be good. Let me know if you see anything.
Thanks! Looks good in general but formats with the depth at the end like D3DFMT_X8D24 don't seem to be used much nor supported.
d3d9Object->CheckDeviceFormat
fails for D3DFMT_X8D24
on my Intel driver while D3DFMT_D24X8
works.
Wine always seems to use D3DFMT_D24X8
despite the confusingly different WINED3DFMT_X8D24
: https://github.com/search?q=repo%3Awine-mirror%2Fwine+D3DFMT_X8D24&type=code
Looks good in general but formats with the depth at the end like D3DFMT_X8D24 don't seem to be used much nor supported.
Interesting. Ok, I cleaned up the code a bit more. You can see the new check-in here: a3e9f495aee71c8bcddde74849f17da18c074528
I guess what confused me is that the zbuffer seems backwards compared to all the other formats.
For example:
For D3DFMT_R8G8B8
the dwRBitMask
is 0xFF0000
because it is listed first.
For D3DFMT_V8U8
the dwBumpDvBitMask
is 0xFF00
because it is listed first.
For D3DFMT_A8L8
the dwLuminanceAlphaBitMask
is 0xFF00
because it is listed first.
Therefore, for D3DFMT_D24S8
the dwZBitMask
should be 0xFFFFFF00
but it seems not to work that way. For some reason Wine shows it the other way.
I don't understand why the zbuffer is backwards. If you have any ideas why this is backwards I would be interested to hear it.
Yeah who knows. 3D stuff came later. And the z buffer is special anyway, normally not even directly accessible.
https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dformat#buffer-formats
indicate no particular bit ordering per pixel
I see. Thanks for the info and follow-up!
Tested on Dungeon Keeper 2: