We support an old video game that uses full-screen mode with 256-color graphics with DirectDraw. The problem is that some applications running in the background sometimes try to change the system palette during the game, which leads to damage to the graphics.
We can (sometimes) detect when this happens while processing the WM_PALETTECHANGED message. A few updated versions ago, we added logging (just write down the window title / class / process name), which helped users identify abusive applications and close them. MSN Live Messenger was a common criminal.
The problem got worse when we found out that Windows Vista (and 7) does it "on its own." WM_PALETTECHANGED options point to CSRSS and the desktop window. In Vista, the workaround that often worked was to open any folder (computer, documents, etc.) and leave it open during the game. It sounds funny, but it worked - in most cases. On Windows 7, even this workaround did not work. Users found that stopping some services (Windows Update and Indexing Service) also fixed the problem for some configurations.
Some time ago, I just started doing random things in the hope of finding a solution. I found that setting the GDI palette (using Create / SelectPalette) before setting up the DirectDraw palette (using IDirectDrawPalette :: SetEntries) will restore the palette after it is damaged (WM_PALETTECHANGED handler). SetSystemPaletteUse and calling SetPalette on the main surface helped a little more. However, it still flickers when the application tries to steal the palette, which is especially noticeable during fading.
Question: is there a way to get a “real” exclusive palette that completely prohibits other applications from changing the Windows palette while our game maintains focus?
source
share