narzoul
commented
1 year ago I don't remember doing anything specific for the SW renderer. Probably by the time I tested it, it was already fixed by something, so I don't know what it was. The only issue I think it had was that it didn't render correctly above 640x480. It looked like z-buffer corruption or some such to me, but I just assumed it was badly handled by the game itself.
I do remember 2 separate crash problems when starting the game in general, not sure if they were related to SW rendering though, and at the time both were only affecting AMD drivers:
-
The main menu fonts are mapped into a system memory surface larger than 4k in one dimension, but AMD drivers for some reason restrict the maximum system memory surface size to the same as video memory surfaces, which was 4k on my old GPUs (this shouldn't be a problem with newer GPUs, since they support at least 8k textures). There was some custom fix on the internet that replaced the problematic font with a smaller one I think, which fits into 4k.
-
I couldn't find traces of this the last time I checked, but I definitely recall the game was using the old DDSURFACEDESC struct for creating z-buffers. With this older interface, the z-buffer format is just specified as a single number with the bit depth, instead of as a pixel format, like with the newer interfaces. The problem was that the game was using DDCAPS.dwZBufferBitDepths to determine the largest supported bit depth, and was trying to use that to create the z-buffer. However, my AMD driver was filling this cap incorrectly, indicating that it supports 16 and 32 bit depth buffers, where in fact it was only 16 and 24 bit ones. So the z-buffer creation failed, the game had no error checking for it and then crashed on dereferencing the null surface pointer. I think this is still an issue on newer drivers too (at least for my RX 480).
The lag in the briefing is also related to text, I think. The game tries to blit every single letter from a system memory surface to the render target back buffer with source color keying. Because color keying is involved, this cannot be hardware accelerated, so the HEL steps in to emulate the copy by locking both surfaces, performing the blit via the CPU, then unlocking both surfaces. Locking and unlocking the back buffer is expensive, I think it's basically equivalent to copying the whole surface from video memory to system memory and then back. And this blit can happen hundreds of times in a short time frame during some transitions in the briefing screens.
DDrawCompat has multiple ways of handling such scenarios more efficiently:
-
It intercepts lock/unlock operations in the WDDM driver, and replaces them by copying the surface between the video memory surface and a self-allocated system memory surface that serves as the "lock surface". This in itself is not much different than locking the surface, but it also remembers which of the two surfaces still contains valid data, and only does the copy on demand when the requested surface was invalidated by some operation. Technically, this might be possible to do without WDDM hooks I think (maybe I even had such a version in some old release), but there are cases when DirectDraw calls internal (not exported) lock functions, such as when a blit has to be emulated by HEL, and you'd have to be able to predict these in advance accurately and redirect the operation to the system memory copy (after making sure it's up to date).
-
It detects when a blit requires a nontrivial copy from system to memory video (which cannot be hardware accelerated), gets a temporary video memory texture where it uploads the source rectangle, then changes the source surface and rectangle to this texture. The blit itself might be performed by shaders instead of the pfnBlt driver routine, because newer AMD GPUs have somehow also broken color keyed blits (I received multiple such reports for RX 5xxx series GPUs at least). And I've also noticed strange issues with doing stretched blits on NVIDIA, which defaults to point filtering, but it seems to have some rounding errors that result in one-pixel shifts along some horizontal/vertical lines. Nowadays blitting via shaders seems to be a lot more reliable. You could also do some of this with fixed-function pipeline rendering without shaders, but you know, D3D9On12 doesn't support texture color keying, which would be needed to emulate color keyed blits... And, of course the D3D7 runtime doesn't support shaders at all, so using shaders is pretty much impossible without WDDM hooking, I think.
BEENNath58
The game has different types of issues, and investigating them is quite difficult, I was intrigued to know how you fixed two of them:
Thank you