SDL palette freeze issues

[fraggle]

[split from the other thread]

raptir said:

I did try out ChocolateDoom, and for some reason it runs terribly on my computer. I know it's not specs related, but it lags and "locks up" for short periods constantly.

Does this happen when there are palette changes (when the screen "flashes" yellow when you pick up an item, or red when you're injured, etc)? This is a fairly well-known problem. Try changing the video driver from "DirectX" to "Windows GDI" in the setup program.

[DuckReconMajor]

fraggle said:

Does this happen when there are palette changes (when the screen "flashes" yellow when you pick up an item, or red when you're injured, etc)? This is a fairly well-known problem. Try changing the video driver from "DirectX" to "Windows GDI" in the setup program.

Yay! The chocolate is tasty again!

[chungy]

fraggle said:

Does this happen when there are palette changes (when the screen "flashes" yellow when you pick up an item, or red when you're injured, etc)? This is a fairly well-known problem. Try changing the video driver from "DirectX" to "Windows GDI" in the setup program.

Why is this even a configurable option if it's known to cause problems? I'd say to just remove that option altogether.

myk said:

Chocolate is less taxing on the system

Indeed; this doesn't just go for old computers, but different CPU architectures as well. For example, I can run Chocolate Doom just fine on my Nintendo Wii; DOSBox also runs on the Wii, but due to the full CPU emulation required, anything more than Wolfenstein 3D = not playable.

DirectX does have higher priority with SDL, so Chocolate should force the use of windib on Win32. Perhaps because of this, the video_driver item in chocolate-doom.cfg should remain, but it defaults to windib when the user hasn't edited it to something else.

[myk]

MikeRS said:
Chocolate should force the use of windib on Win32.

On my system it's the other way around; DirectX must be used. It would be convenient to determine the most bug-free option (on systems likely to be used with Chocolate), so it can be chosen as the default. If the issues can be detectable (such as whether failure is due to the operating system or the graphics card) maybe the choice written into chocolate-doom.cfg could depend on that.

[entryway]

MikeRS said:

DirectX does have higher priority with SDL, so Chocolate should force the use of windib on Win32. Perhaps because of this, the video_driver item in chocolate-doom.cfg should remain, but it defaults to windib when the user hasn't edited it to something else.

DirectX is preferable for Win9x. PrBoom-Plus uses "DirectX" for Win9x as default value and real "Default" mode for other cases. For Win32 systems it's equal to "windib"

[fraggle]

MikeRS said:

Why is this even a configurable option if it's known to cause problems? I'd say to just remove that option altogether.

Both have issues on different systems. On my system, when playing in windib mode the colors all look washed out.

I might be able to put SDL into a different palette mode, I know that there are hardware and software palette options but I have to admit that I don't entirely understand them :-)

[Quasar]

There's nothing you can do to fix the DirectX palette changing bug except to get Sam Lantinga to fix it in SDL 1.2 branch.

The problem is that in one branch of the DX5 palette change handler, a certain variable is not asserted that is asserted in a different branch. This variable tracks whether or not the palette change is "expected," that is, whether it comes from user code (a call to SDL_SetColors), or "unexpected" (comes from Windows itself, via a WM_ event).

The de-assertion of this variable causes SDL to run an extremely expensive, undocumented, unnecessary, and horrific operation to remap every pixel of the framebuffer from the currently set palette to the closest color in the new palette.

The operation would be slow no matter what. But because under DirectX fullscreen the framebuffer is likely to be a hardware surface, this means that the lock performed on it causes the entire surface to be copied from video memory into a shadow surface, and back again after unlock.

And if that's not bad enough, when using hardware surfaces, the program will also be blocked until the next hardware screen refresh (VBLANK) occurs, causing an additional layer of inconsistent stall.

This bug will not be in the 1.3 branch of SDL because it no longer includes the DX5 video driver at all. But SDL 1.3 is almost an entirely new API, and adapting DOOM ports to it will take time and significant testing work. It would be a lot easier if someone would adequately address these issues with the SDL dev team.

I have already tried myself, and haven't gotten anywhere.

[fraggle]

Quasar said:

There's nothing you can do to fix the DirectX palette changing bug except to get Sam Lantinga to fix it in SDL 1.2 branch.

The problem is that in one branch of the DX5 palette change handler, a certain variable is not asserted that is asserted in a different branch. This variable tracks whether or not the palette change is "expected," that is, whether it comes from user code (a call to SDL_SetColors), or "unexpected" (comes from Windows itself, via a WM_ event).

It sounds like you know a lot more about this than I do. Where exactly in the SDL source is the bug? If we can get a patch, I'll do what I can to push it to the SDL developers. Even if they won't take it, there's no reason that we can't ship a fixed SDL dll with Chocolate Doom / Eternity / Prboom / etc.

Edit: I think I found the code you're referring to. Can someone who experiences the problem try this custom SDL dll that I built and see if it fixes the problem? (I don't seem to experience it). Please back up your old SDL dll before trying. Also, make sure you set Chocolate Doom to use DirectX :-)

[Quasar]

Somebody who is having the palette issue please step up and help us test this patch. I am no longer able to get it to happen on my machine since upgrading my video driver - SDL appears to be using shadow surfaces now, which ruins this problem that only occurs on real 8-bit video surfaces.

[Csonicgo]

I think my GeForce 7300 does it. I'll check today when I have time.

[DuckReconMajor]

Okay guys, here goes.

I switched back to Direct X. Then I played Doom 2 Map01 - Map04, about twice as far as I usually get without the palette bug, and picked up everything. No flash, works so far. Then I threw together this wad (a room with almost 10,000 armor bonuses) and strafe ran like a madman. Screen turned yellow, and it took about 5 seconds to return to normal, but it did. At least on my machine, this bug has been squashed. Plus it doesn't slow down anymore. Thanks!

Feel free to use my wad to test it on your own system.

[fraggle]

DuckReconMajor said:

Okay guys, here goes.

I switched back to Direct X. Then I played Doom 2 Map01 - Map04, about twice as far as I usually get without the palette bug, and picked up everything. No flash, works so far. Then I threw together this wad (a room with almost 10,000 armor bonuses) and strafe ran like a madman. Screen turned yellow, and it took about 5 seconds to return to normal, but it did. At least on my machine, this bug has been squashed. Plus it doesn't slow down anymore. Thanks!

Thanks very much for testing this.

I've uploaded a patch to the bug on the LibSDL bug tracker, so hopefully we should see it fixed soon. In the mean time we can ship patched versions.

[exp(x)]

I'll include that SDL.dll in my svn builds.

[Csonicgo]

I can confirm that this patch indeed works. Good job, team.

[Dragonsbrethren]

The updated dll solved it for me as well.

I have another problem with the DirectX renderer though - my mouse sensitivity really drops when I use it compared to the Windows GDI renderer. Is this a common problem? I'm guessing it's another SDL issue since it affects DOSBox for me too; I need to use one of the OpenGL renderers or increase the sensitivity value in the configuration file to use any of the others.

Edit: After doing a bit of poking around, I found this is caused by the enhance pointer precision option in the control panel. This setting applies when using the DirectX renderer, it doesn't when using the GDI renderer. I don't know why I had it on in the first place.

[fraggle]

Good news everyone, the patch has been applied to the SDL 1.2 maintenance branch.

[DuckReconMajor]

Awesome.

[esselfortium]