Closed alekasm closed 5 years ago
Thanks for the report, I will look into it (eventually....)
As for your question, since you are on Windows 10, you are already using 32-bit display color depth whether you want to or not. Lower color depths are not supported since Windows 8.1. All the 8 and 16 bit display modes are emulated - normally by Windows, or in this case by DDrawCompat. This means that your monitor uses a 32 bit display mode while the game renders to a hidden 8 or 16 bit surface, and that surface is then converted (copied) to a 32 bit surface before being displayed.
As for the game itself rendering its output in 8 bit, it's not something that can be changed by any wrapper. 8 bit display mode is quite different from the higher color depths, because it relies on a "color palette" and only stores color indices in the image buffer, rather than actual RGB color values. This also makes it possible to change what is displayed by modifying the color palette alone, without changing the image buffer itself (the color indices). This is not possible with higher color depths.
Even for something simpler like 16 -> 32 bit conversion, you'd still have to handle the cases when the application requests direct access to the image buffer, which then has to be provided in the expected format. So this would require an additional step to convert the buffer back to 16 bits, let the application read/modify it, and then convert it back to 32 bits.
In games that don't use Direct3D for rendering, this has no benefits anyway because it won't change the end result, it would just slow things down with unnecessary back and forth conversions. The case where it could have a benefit is for Direct3D rendered games, where higher color depth can improve visual quality (e.g. reduce "color banding", especially since dithering doesn't seem to be widely supported by hardware nowadays). This is something that DDrawCompat could (should) eventually support.
As for the game above, I doubt it uses Direct3D, since I think it never supported 8 bit display modes (or even if it did, it doesn't anymore). It most likely uses its own software renderer, with direct image buffer manipulation. So to change the end result you'd have to modify the game code itself.
The color issues are most likely related to incorrect palette handling in DDrawCompat. I've fixed a couple of related problems already, but it's still not quite perfect...
Correct the game uses 8-bit color. The game's color looks fine in fullscreen, but in windowed mode it has these issues presumably because in fullscreen mode it actually changes the color to 8-bit (so there's no emulation)? The game uses DirectDraw and there are some calls to Create/Realize/Select Palette functions, but it seems like this may only be used during a video sequence in the beginning of the game.
I've been modifying the game a lot, trying to track down a lot of the graphics issues now which is very hard. From what I've read and what I'm guessing, I'm assuming it's an issue where the 8-bit palette is incorrectly (or not finding) the color it needs from the system so its display "red" when it reaches this case.
In your directdraw dll, it fixes the "red pixel" problem but things like text colors and font appear different unfortunately. I know its probably impossible to wave your magic wand and fix all directdraw problems for every game - I'm just happy to see you working on this.
So my initial suspicions I think hold true, it's the palette (I've spent way more time trying to figure this out than I'd like to admit).
Here is the before:
Here is me modifying the palette which I think is "broken" (from what I described above):
Now here is the part of the palette I think is broken (starting at index 246/256):
I made it look better by copying the colors from the palette when the game is in fullscreen mode, then simply plugging the same colors into the palette when its in windowed mode. This fixes a bunch of issues, but there are still some color problems. Mainly the point of this comment was just to confirm that it appears to be a problem with the palette selection.
Why did you close the issue? I thought the palette problems are still there.
Should be fixed in latest experimental release.
There are strange issues that are occuring with the experimental version using SimCopter - not apparent in the stable build.
First is after the video sequence of the game, the style/colors of the hwnd does not show correctly on 8-bit compatability mode (Windows 10 64-bit). This issue does not happen when the game is on 32-bit (no compatability mode). Issue does not happen at all on stable build.
The game running in windowed has the same "color errors" as the original ddraw (from Wow64). See image below of a building have one of its sides completely red (this is not correct). On the stable build, the colors seemed much better - however a lot of the text colors were not correct.
Not sure if any of this helps at all, but I really appreciate seeing someone work on this.
Also, what are the chances of having a game that relies on 8-bit color from DirectDraw natively use 32-bit color?