SDL + DirectX Palette issues on newer Windows systems

Hey everybody!

We've recently had a lot of Odamex bug reports that indicate running with directx as your video drivers will create rainbow-like palette issues on newer windows systems. This seems to happen on Windows Vista/7 in particular (though there have been a handful of XP cases as well). This only occurs in full screen modes.

I asked a few of these people to try other SDL engines (like Eternity) with -directx and they report the same issues. I've heard that this happened with old versions of ZDoom as well but that it has been fixed in ZDoom 2.0. Does this problem actually have anything to do with SDL specifically, has it been resolved in any other engines, and what needed to be done to correct it?

Thanks in advance!

Basically every game that only uses 256 colors in fullscreen is going to be very problematic with Windows 7 and possibly Vista.

Starcraft, Diablo, Age of Empires, Warcraft II.. these are the games I've personally seen this problem with, along with running, say, PrBoom+ in 8bit color mode, same with eternity, I had to use -32bit or something like that to make it stop doing that shit.

The common work around is to open the screen resolution window. I have no idea why that works.

Sorry, wish I had more info to help you with.

Ralphis said:

Does this problem actually have anything to do with SDL specifically, has it been resolved in any other engines, and what needed to be done to correct it?

1. Do not use obsolete 'directx5' driver
2. Ask SDL guys why they dropped support for 'directx' and did not add vsync support for 'windib', because lack of vsync is the only reason why 'normal' people would want to use 'directx'
3. Ask Microsoft guys how to force that directx's compatibilities for win32 executables, because it is possible for DOS applications.
4. TASKKILL /F /IM explorer.exe

SDL just sucks. I don't even know the progress on the next version, since nothing has been announced or talked about since. Last I heard, 1.3 was going to be aimed at iPhones as well.

This happens with any palette based game that doesn't apply a work around for explorer.exe. I have a Windows 7 machine and the rainbow problem is solved by either opening the screen resolution window, or killing explorer.exe before I run the program.

Example of the problem:

The interesting question though is, how come 8-bit color works perfectly fine in ZDoom in Windows Vista and 7?

because it isnt 8-bit.

Spleen said:

The interesting question though is, how come 8-bit color works perfectly fine in ZDoom in Windows Vista and 7?

8-bit color works perfectly fine in all SDL ports in Windows Vista and 7. You just should not use obsolete directx5 sdl driver (which is not used by SDL by default)

Csonicgo said:

because it isnt 8-bit.

At least for me the DDraw 8 bit code still works as well as the new D3D code, except for the lack of color resolution, of course.

Csonicgo said:

because it isnt 8-bit.

I don't think EE is 8bit either.

kristus said:

I don't think EE is 8bit either.

It is unless you run in -8in32 mode. I'm not sure if there's a config option anywhere to make this a default; if there's not, there should be, since many users (like myself) don't use the command line at all when we can possibly avoid it. Thankfully I haven't had the issues that make -8in32 necessary for some users, but if I did, I'm sure I'd be bitching about it ;)

entryway said:

8-bit color works perfectly fine in all SDL ports in Windows Vista and 7. You just should not use obsolete directx5 sdl driver (which is not used by SDL by default)

If mouse movement wasn't dependent on resolution and other such factors in gdi, which cause weird crap to happen, then I wouldn't ever have to suggest anybody use -directx. Unfortunately, nobody has figured out how to implement the mouse fix (that you came up with but never commited :[) in Odamex yet, so players have to choose between having a crap mouse and fine colors or great mouse and crap colors.

Ralphis said:

If mouse movement wasn't dependent on resolution

It does not depend on resolution (i mean sensitivity). Issue appears when you use small resolutions like 320x200 (minimal resolution I can use is Vista/7 is 800x600) and high-rate mouse or just extremely high sensitivity. Plus you always can copy/paste support for dinput mouse from zdoom, right? Should it work in windib mode?

I think, that issue with mouse appears for people who use low resolutions and windowed mode. But palette issue does not affect windowed modes, so you can force 'directx' for them.

entryway said:

It does not depend on resolution (i mean sensitivity). Issue appears when you use small resolutions like 320x200 (minimal resolution I can use is Vista/7 is 800x600) and high-rate mouse or just extremely high sensitivity. Plus you always can copy/paste support for dinput mouse from zdoom, right? Should it work in windib mode?

I think, that issue with mouse appears for people who use low resolutions and windowed mode. But palette issue does not affect windowed modes, so you can force 'directx' for them.

Another issue with the mouse actually happens in fullscreen. If you play with fullscreen in GDI, and alt-tab, your mouse gets stuck in the left corner in the screen.

Spleen said:

Another issue with the mouse actually happens in fullscreen. If you play with fullscreen in GDI, and alt-tab, your mouse gets stuck in the left corner in the screen.

Bullshit. Ask port programmer about wtf with your mouse. I have no such issue with prboom-plus. Also ask GrafZahl why he does not restore HW gamma when gzdoom window is not focused. It annoys me for years :)

entryway said:

bullshit. ask port programmer about wtf with your mouse. i have no such issue with prboom-plus

This happens in Odamex, not PRboom-Plus. Sorry for the confusion.

entryway said:

Also ask GrafZahl why he does not restore HW gamma when gzdoom window is not focused. It annoys me for years :)

Not only GZDooM did this shit, many programs(DooM3 did this, I'm sure)/source ports(not-DooM ports too, like eduke32 or some OpenGL Quake ports) did this shit, always. Annoying, but it's not really affect gameplay or something in game, just you Alt-Tab out or it crashed and say "Ahhh...WTH? it's so ****ing bright!" or something complains about gamma isn't reset, huh.

Oh yeah, I like see this get fixed on GZDooM, if possible... :)

There are many problems with gamma in GZDoom.

playerlin said:

Not only GZDooM did this shit, many programs(DooM3 did this, I'm sure)/source ports(not-DooM ports too, like eduke32 or some OpenGL Quake ports) did this shit, always. Annoying, but it's not really affect gameplay or something in game, just you Alt-Tab out or it crashed and say "Ahhh...WTH? it's so ****ing bright!" or something, huh.

glboom-plus restores HW gamma when window is not focused almost from the same day when I implemented it.

How do you do it?

Gez said:

How do you do it?

case SDL_ACTIVEEVENT:
  UpdateFocus();
  break;

static void UpdateFocus(void)
{
  Uint8 state = SDL_GetAppState();
  window_focused = (state & SDL_APPINPUTFOCUS) && (state & SDL_APPACTIVE);
  gld_SetGammaRamp(window_focused ? useglgamma : -1);


int gld_SetGammaRamp(int gamma)
{
  if (gamma == -1)
  {
    succeeded = (SDL_SetGammaRamp(
      gl_oldHardwareGamma[0],
      gl_oldHardwareGamma[1],
      gl_oldHardwareGamma[2]) != -1);


void gld_CheckHardwareGamma(void)
{
  gl_DeviceSupportsGamma = (-1 != SDL_GetGammaRamp(
    gl_oldHardwareGamma[0],
    gl_oldHardwareGamma[1],
    gl_oldHardwareGamma[2]));

playerlin said:

or it crashed and say "Ahhh...WTH? it's so ****ing bright!"

You can restore the gamma values to a linear value with glboom-plus -resetgamma

entryway said:

You can restore the gamma values to a linear value with glboom-plus -resetgamma

Oh, I forget said I never using glboom-plus, sorry. :(

But, I use a program called "SetGamma.exe" and use it (SetGamma -reset)when I get this shit happens. :)

I accidently stumbled upon a workaround for this. I KNOW it works for Odamex, but have not tested it for other SDL source ports.

Start Odamex with -directx. When you first start the colors will be borked (normal). Now navigate to the "Set Video Mode" menu. Whatever resolution you have set, set it again. And like magic, no more messed up colors! If you want to change resolutions, just set the resolution and hit enter again to get the fix.

Bad part is when you exit Odamex and restart you will have to go through this simple process again until some kind of permenant fix can be figured out from this.

<HeX9109>Maybe as a workaround Odamex can simply draw the screen twice when it starts and when a user switches resolutions?
<tm512>sounds hacky
<Hyper_Eye>If it works you do it only when the directx driver is used and you don't label it "hacky," you label it a "workaround"
<Hyper_Eye>The people that it benefits aren't going to care how you are doing it and it probably wouldn't be very noticeable if at all.
<Manc>maybe there's a specific part of setresolution that can be called twice?
<Hyper_Eye>I would like to play with it... maybe doing a reinit on the video subsystem after setting the video mode will work.
<Manc>go for it