[Bug 13198] Microsoft Pinball Arcade black/blank window in 24bpp mode

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=13198





--- Comment #8 from Alexander Dorofeyev <alexd4 at 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.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.