We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 526

Summary: DirectX video driver suffers lag when changing palette on fullscreen hardware surface
Product: SDL Reporter: James Haley <haleyjd>
Component: videoAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: 1.2.12   
Hardware: x86   
OS: Windows (XP)   
URL: http://sourceforge.net/project/showfiles.php?group_id=211429&package_id=254153
Attachments: Fix for the palette bug.

Description James Haley 2007-12-21 08:53:07 UTC 
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).
Comment 1 Simon Howard 2009-03-20 16:50:56 UTC 
Created attachment 306 [details]
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.
Comment 2 Sam Lantinga 2009-04-12 17:53:27 UTC 
Thanks, your patch was applied to subversion. :)