Bug Tracker – Bug 862

SDL Framework version performance conflict

Last modified: 2019-08-12 21:52:57 UTC
Bug 862 - SDL Framework version performance conflict
Summary: SDL Framework version performance conflict
Status: NEW
Alias: None
Product: Odamex
Classification: Unclassified
Component: Client (show other bugs)
Version: (old) 0.6-dev
Hardware: All Mac OS
: P1 major
Assignee: Odamex Bug Reporter
Depends on:
Reported: 2012-06-16 07:25 UTC by Mike Wood
Modified: 2019-08-12 21:52 UTC (History)
2 users (show)

See Also:


Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Wood 2012-06-16 07:25:34 UTC
When OS X 10.7 Tiger released an API change was introduced that caused a crash with SDL apps when switching to fullscreen mode or starting in fullscreen mode. The issue was "resolved" by changing a significant amount of the Mac fullscreen code in SDL and the changes were released with SDL 1.2.15. Unfortunately the new code path is not as fast and it pretty much turns Odamex into a slideshow on older Macs when running in fullscreen. My test platform is a 1.42Ghz G4 PowerPC. While Odamex 0.5.6 (SDL-1.2.14 bundled) runs well in fullscreen on it, even at 1680x1050, Odamex 0.6.0 (SDL-1.2.15 bundled) is unusable in fullscreen mode. Simply swapping the old SDL framework into Odamex 0.6.0 makes it perform the same as the previous versions on this hardware.

I created a thread on the libsdl forums describing the issue. It can be viewed here: http://forums.libsdl.org/viewtopic.php?t=8196

Short of this issue being resolved by the libsdl guys a decision has to be made on how to proceed with the Mac releases. Here are some options that I have come up with:

1) The game "Battle for Wesnoth" (great game) modified the Mac fullscreen code to use the old code path in OS X 10.6 and earlier and the new code path in 10.7+. I dropped this framework into 0.6.0 and it worked pretty well except for one issue. Apparently the Wesnoth guys also made a change to the windowed code that improves framerate but it also can cause Odamex to crash when the resolution is changed and part of the window ends up off the screen. Changing resolutions in fullscreen mode is not an issue. Using this framework would be a bit of a compromise. I could ask the Wesnoth guys for their SDL code and attempt to fix the crash as well.

2) I can essentially do the same merge between the two versions of the fullscreen code myself. This is not an immediate solution as there is a lot of code in the patch that fixed the original crash and there is Objective-C in it (which I have worked with but am no expert on). It will take me some time to be able to cleanly produce an acceptable framework. It also has to be considered that this would not be the official framework and that makes it a troublesome long term solution.

3) We can start releasing 2 Mac builds. One would be a universal build (ppc, x86) for 10.4 - 10.6. The second would be for x86 10.7+. I'm not sure if Sourceforge has the ability to default to a release based on OS version but that would be the optimal way to handle this solution.

I do not think we should stop supporting 10.4+ or PowerPC in our releases but I also don't think we should be claiming we support them when the performance is so bad. The best thing would be for this to be fixed in SDL but I hope we can come up with an acceptable solution in the meantime.
Comment 1 Mike Wood 2012-06-16 07:28:21 UTC
Just a note that I misstated the test hardware. It is actually a 1.67GHz G4 PowerPC with 2GB memory.
Comment 2 vincentmrl.paper 2014-12-13 17:00:35 UTC
Confirmed it's extremely slow in higher resolutions other than 640x480. I'm using a Late 2007 iMac 24 (core 2 duo 2,4Ghz, ATI2600Pro 256MB, 6GB RAM) and when i run the game on my native res (1920x1200) it runs at around 5fps. It gets outperformed by the windows version even on a virtual machine.
Comment 3 HeX_Vulture 2019-08-12 21:52:57 UTC
Just curious if this should be resolved with the SDL2 changes? Or how should this bug be handled?