This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Fix for the palette bug. (sdl-windx5-palette-fix.diff, text/plain, 2009-03-20 16:50:56 +0000, 529 bytes)

Reported in version: 1.2.12
Reported for operating system, platform: Windows (XP), x86

Comments on the original bug report:

On 2007-12-21 08:53:07 +0000, James Haley wrote:

Recent versions of SDL appear to cause programs using 8-bit fullscreen hardware surfaces to block until the next hardware refresh when performing a palette change under the DirectX driver, which causes a severe but inconsistent lag. I am not precisely sure what version of SDL this problem started with, but it is manifest in 1.2.12 for certain.

If you want to test this using my port, which I have linked, you need to install it along with some copy of Doom (shareware will work fine), and copy the doom.wad file to a location where EE can find it (such as its own directory). Then, give Eternity the following command line:

eternity -vwidth 640 -vheight 400 -fullscreen -directx

You will now suffer various degrees of lag when picking up items, getting hurt, picking up the radiation suit, etc. Anything which causes a palette change to occur. This lag will not occur if the windib driver is used, or if the program is run in windowed mode regardless of driver specified.

This problem is also known to affect the source ports PrBoom, PrBoom-plus, WinMBF, and Chocolate Doom. I devised a workaround for my own port that translates the 8-bit graphics to a 32-bit video surface, but using this causes a bit of an FPS hit (it is currently toggled on by using the command-line parameter -8in32).

On 2009-03-20 16:50:56 +0000, Simon Howard wrote:

Created attachment 306
Fix for the palette bug.

Hi,

I'm the author of Chocolate Doom, one of the other source ports that James mentioned. This is a patch against the current SVN version of SDL 1.2 that fixes the bug. It has been tested and hopefully should be obviously correct from examining the changes. I'll give a brief explanation.

When the palette is set with SDL_SetPalette, the IDirectDrawPalette_SetEntries DirectX function is invoked. However, when this happens, a WM_PALETTECHANGED message is sent to the window.

A WM_PALETTECHANGED message can also be received if the palette is changed for some other reason, like if the system palette is changed. Therefore, the palette change handler (DX5_PaletteChanged) has code to deal with this case. It distinguishes "expected" palette changes (set with SDL_SetPalette) from "unexpected" palette changes using the colorchange_expected variable, which is set before calling IDirectDrawPalette_SetEntries. However, the code to set this variable is missing in the fullscreen code path. By setting this variable, the palette change is handled properly and the freezes go away.

On 2009-04-12 17:53:27 +0000, Sam Lantinga wrote:

Thanks, your patch was applied to subversion. :)