Win32 Palette odd case bug & fix

SDL currently does not handle the case that the program is running in a
window at depth > 8, then the user changes their desktop to 8 bit and the
SDL window is recreated accordingly. The result is the window is created
in 8 bit and has no “screen_pal”

It seems supporting this case is as simple as moving this code in
SDL_dibVideo.c (line 521) down below "#endif /* !NO_CHANGEDISPLAYSETTINGS */"
i.e. have it apply to all windows, not just changed display settings:

if ( screen_pal != NULL ) {
/*	RJR: March 28, 2000
	delete identity palette if switching from a palettized mode */
	DeleteObject(screen_pal);
	screen_pal = NULL;
}
if ( bpp <= 8 )
{
/*	RJR: March 28, 2000
	create identity palette switching to a palettized mode */
	screen_pal = DIB_CreatePalette(bpp);
}

There may be a similar issue with the directx driver

–Manny

SDL currently does not handle the case that the program is running in a
window at depth > 8, then the user changes their desktop to 8 bit and the
SDL window is recreated accordingly. The result is the window is created
in 8 bit and has no “screen_pal”

It seems supporting this case is as simple as moving this code in
SDL_dibVideo.c (line 521) down below "#endif /* !NO_CHANGEDISPLAYSETTINGS */"
i.e. have it apply to all windows, not just changed display settings:

I have committed this code in CVS. It does change the semantics of the
video code by now using a palette in windowed mode, which I’m not sure
is the intended behavior. Can you check to make sure the new code works
properly both in fullscreen mode and windowed at 8-bpp?

Thanks!
-Sam Lantinga, Lead Programmer, Loki Software, Inc.

Using our app and the nifty sailboat testpalette program it works either
way … in windib mode - seems there is a difficulty with directx
palettes(?) (windowed & fullscreen) but I haven’t had a chance to investigate.

InitVideo does create a screen_pal for the window if the display is 8 bit,
so this is just matching that behavior if the desktop is changed from
outside after the Init, so I think it’s all ok.

What I’m doing (and what didn’t work without the change) is if the desktop
gets switched to 8 bit while the program is running, then I make an 8 bit
surface and set the 332 palette. Setting the palette would always fail if
the desktop wasn’t 8 bit when SDL was initialized. Then I make a
backbuffer of the original depth so everything keeps working and dither the
backbuffer to the 332. Not great (though surprisingly ok), but before we’d
just bail with a “hey you changed the display to 8 bit” sort of message, so
it’s an improvement of sorts. Pretty much what SDL does automatically, but
with a dither.

Thanks,
–Manny

At 06:50 AM 6/7/2001 -0700, you wrote:> > SDL currently does not handle the case that the program is running in a

window at depth > 8, then the user changes their desktop to 8 bit and the
SDL window is recreated accordingly. The result is the window is created
in 8 bit and has no “screen_pal”

It seems supporting this case is as simple as moving this code in
SDL_dibVideo.c (line 521) down below "#endif /*
!NO_CHANGEDISPLAYSETTINGS */"
i.e. have it apply to all windows, not just changed display settings:

I have committed this code in CVS. It does change the semantics of the
video code by now using a palette in windowed mode, which I’m not sure
is the intended behavior. Can you check to make sure the new code works
properly both in fullscreen mode and windowed at 8-bpp?

Thanks!
-Sam Lantinga, Lead Programmer, Loki Software, Inc.