Spam Prevention - PLEASE READ !! (23 Apr 2021)
Due to a problem with spammers the rules for posting in the forums have changed for new users.
Newly registered users won't have their posts published until a moderator approves them.
DgVoodoo creator discusses Swat 3
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 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.
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.
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.
"DirectDrawEnumerateA" - this gathers information about the system of what valid resolutions there are
Information about DirectDraw and what we are up against.
Also this reference page about DirectDraw.
Some Windows calls:
"CreateWindowExA" (link to syntax and paramaters )
"SetWindowPos" (link to syntax and paramaters )
Strangely this error message was in memory:
"This program requires DirectX 6.1 or higher"
I am wondering if this is left over from an early build?
Update: yup here are the original specs
Interesting read, gonna bookmark those pages for references.
The setwindowpos is dead on in the swat 3 code, I have found multiple references to window size and pos. The position is hard coded 0, 0. but there are ways around that. we cant add integers because we only have 4 bites to work with "push 0"
At some point today we need to agree on the loading screens, please read my second to last post and respond, pliz.