narzoul
commented
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...
alekasm
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?