DgVoodoo creator discusses Swat 3

I posted on the forums that Dege, the creator of the awesome dgVoodoo 2, helps people with problems on.

Below is my post:

One of the biggest problems we have with the game is colour banding. Even when we replace textures with 24-bit versions and replace the movies with higher resolution versions there is always ugly colour banding as if the game is running in 256 colours.

I know the game is supposed to be running in 16-bit colour mode but the colour banding is horrible on modern machines. Currently I am working on upscaling the movies with AI software but when the movies are run from within the game the colour banding is much worse than when it is played outside the game. Is there anything that can be done to fix this colour banding issue with dgVoodoo or is this something that can only fixed in the game itself?

Here is Dege's reply:

Yes, I have a copy of the game and also have the Last Resort mod installed, I'm not a Swat player though. 😀 I installed it when I got a report and fixed the mouse handling for the game.

The problem with color banding is because the game insists on 16 bit display mode and 16 bit surfaces / textures.
Even if you have 24 bit movies and textures, the movie player and the game code converts the bitmap data to 16 bit, so dgVoodoo doesn't have a chance to see 24/32 bit graphical data.

I experitmentally forced 32 bit display mode, and also skipped the error message thrown by the game because of that, and for the movies that seemed to solve the problem, the video decoder just converted the bitmap data to 24 bit instead of 16, as expected.

The game itself however, still converted all bitmaps to 16 bit, ending up in wrong appearance.  I think the only solution would be patching the executable to 32bit'ize it:

- Changing display mode and related format checkings from 16 to 32 bit
- Patching the game bitmap converter routines to handle 32 bit targets.  I don't know how many places the latter occurs though, so I cannot estimate how much work that'd be.

Also, by a quick glance, I think this all involves that literally ALL bitmaps should be converted to 32 bit. Backround pictures, cursors, etc.

So my take away from his reply is that it would take more than a few simple hacks to deal with this issue.

I've always said. "You have to break the game before you can fix it. "

I guess the first step would be to see what calls are made by the game.

I assume the 2D menus use DirectDraw and the 3D portion uses DirectX9.

What would the movie player use?

Once we know what calls it makes and what API versions it uses we should be able to research the format of each call. We should be able to see what flags are able to be used with each call and then see if we can modify them to our liking.

For instance what is the maximum bit colour that can be used in the directdraw call that creates the window in Swat 3?

It would be awesome if we first could master the directdraw calls.    Maybe just a pipe dream since it would involve research and learning, lol.
 

Assuming no changes would need to be made to the Ddraw dll.....   We should LordPE hack the exe to use our own version of direct draw.
In other words tell swat.exe to use DDraw.dll in our swat3 folder instead of the one in windows. I'm down to give it a shot. just to poke around, you got a 32 bit version of the menu_background we can use to break the game?

I'll open the exe in Ghidra, and hacking tools to find out some basic calls. I know where a few of them are already. Gonna start a new project.

I am hoping that we won't have to get into anything complex like .dll hooking for Direct Draw. We should rule out the possibility of a simple hack first.

Here is my thought process on how to move forward with this:

1) Identify the calls with an app like Ghidra or a debugger

2) Determine the version of Direct Draw we are dealing with

3) Research those calls to see what all the parameters are.

4) Examine the Swat executable to compare if we can spot these calls and see if there are any parameters we can change for our benefit.

For step 1) best way is to throw a 32 bit texture like the Main_background to make it error, and trace back before the error to see where it goes from there.