http://bugs.winehq.org/show_bug.cgi?id=13198
--- Comment #8 from Alexander Dorofeyev alexd4@inbox.lv 2008-06-10 13:25:09 --- (In reply to comment #7)
(In reply to comment #5) That's correct behavior of GetDeviceCaps. What you have found may mean that ddraw should set/initialize default palette.
I don't think so, I did quite extensive testing of that and saw no evidence ddraw sets any default palettes. There was evidence though that it falls back to current system palette in case primary surface palette is missing.
I looked into the game with IDA and it looks like there's only place it creates a ddraw palette, and it follows a GetDC(0), GetDeviceCaps() and check for RC_PALETTE. Unfortunately for us, in native RC_PALETTE is returned if ddraw changed mode (SetDisplayMode) to 8bpp prior to GetDeviceCaps (tested on real XP). But normally it isn't returned in normal desktop modes in XP, you are right about that. Without RC_PALETTE returned, a ddraw palette will never be created. And returning RC_PALETTE cap isn't going to happen, I guess.
If the "use system palette colors by default in ddraw if no ddraw palette available" logic would be implemented, this could also be a fix for this game, although technically this isn't how this game works on native. This pretty much gets back to the first hack I posted. But it won't work without working GetSystemPaletteEntries or some other way to get last realized gdi palette. Last time I checked GetSystemPaletteEntries definitely does return some meaningful results in native, even in 24bpp etc modes, but it just always returns 0 in Wine I think, except in the non-existant palettized X modes.