fraggle Posted March 18, 2009 [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. 0 Share this post Link to post
DuckReconMajor Posted March 19, 2009 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! 0 Share this post Link to post
chungy Posted March 19, 2009 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. 0 Share this post Link to post
myk Posted March 19, 2009 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. 0 Share this post Link to post
entryway Posted March 19, 2009 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" 0 Share this post Link to post
fraggle Posted March 19, 2009 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 :-) 0 Share this post Link to post
Quasar Posted March 20, 2009 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. 0 Share this post Link to post
fraggle Posted March 20, 2009 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 :-) 0 Share this post Link to post
Quasar Posted March 20, 2009 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. 0 Share this post Link to post
Csonicgo Posted March 20, 2009 I think my GeForce 7300 does it. I'll check today when I have time. 0 Share this post Link to post
DuckReconMajor Posted March 20, 2009 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. 0 Share this post Link to post
fraggle Posted March 20, 2009 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. 0 Share this post Link to post
exp(x) Posted March 21, 2009 I'll include that SDL.dll in my svn builds. 0 Share this post Link to post
Csonicgo Posted March 21, 2009 I can confirm that this patch indeed works. Good job, team. 0 Share this post Link to post
Dragonsbrethren Posted March 31, 2009 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. 0 Share this post Link to post
fraggle Posted April 14, 2009 Good news everyone, the patch has been applied to the SDL 1.2 maintenance branch. 0 Share this post Link to post