FS#3447 - [OSX] SDL port is unuseable

Attached to Project: OpenTTD
Opened by Ingo von Borstel (planetmaker) - Tuesday, 29 December 2009, 19:37 GMT
Last edited by Remko Bijker (Rubidium) - Sunday, 06 February 2011, 21:15 GMT
Type Bug
Category Core
Status Closed
Assigned To No-one
Operating System Mac OS X
Severity Very Low
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Using MacOSX 10.6.2, I compiled OpenTTD rr18656 with ./configure --with-sdl --without-cocoa-quartz --without-cocoa-quickdraw in order to test SDL under MacOSX. This setup has various issues.

a) The colour of the display has a nice blue-ish note (see attached screenshot)
b) The default OSx window resize button in the lower right smears under certain conditions into the window. For this the window has to be large enough in both x and y extend. The smear is achieved by moving the map.
c) The console issues zillions of debug warnings:
2009-12-29 20:15:25.105 openttd[31007:8f0b] *** __NSAutoreleaseNoPool(): Object 0x11a15dee0 of class NSWindowGraphicsContext autoreleased with no pool in place - just leaking
d) OpenTTD produces sometimes an assertion upon quitting the application. See attached crash information. A newly created game was running, just command+q and confirming the "do you want to exit" dialogue leads to this behaviour. "Assertion failed at line 90 of trunk/src/fileio.cpp: f != NULL" This information is not contained in the attached crash information.
e) The speed compared to the native port feels slower

Using SDL installed via macports:
libsdl @1.2.14 devel/libsdl
This task depends upon

This task blocks these from closing
 FS#2782 - [OSX] Port hopelessly outdated 
Closed by  Remko Bijker (Rubidium)
Sunday, 06 February 2011, 21:15 GMT
Reason for closing:  Bug in external library
Additional comments about closing:  But documented in r22003
Comment by Ingo von Borstel (planetmaker) - Tuesday, 29 December 2009, 20:46 GMT
This patch fixes one warning about an usused variable I got (and forgot) during compilation with --without-cocoa-quartz --without-cocoa-quickdraw
The 2nd version fixes only that line while the first patch makes the #ifdefs in that function better readable from my POV by combining them into one #if
Comment by Remko Bijker (Rubidium) - Sunday, 03 January 2010, 17:39 GMT
  • Field changed: Status (New → Not confirmed)
Unconfirmed only because there's no developer that can confirm it. Given the amount of information given it seems to be a valid bug report though.
Comment by Brad Oliver (hoserama99) - Saturday, 23 January 2010, 17:46 GMT
Does anyone care about the status of the SDL build on the Mac side, given the native Mac back-end?
Comment by Remko Bijker (Rubidium) - Saturday, 23 January 2010, 18:10 GMT
Yes, the people that claimed that we should just use SDL and drop the Mac back-end. This definitely shows that it does not work. Furthermore, if it does not work configure should not be able to be detect with SDL for OS X, however AFAIK the (unofficial) iPhone port uses SDL so doing that would kill that port.

So, there are two "fixes":
- fix the SDL issue
- make SDL unavailable at all for OS X (and thus 'kill' the iPhone port)
Comment by Ingo von Borstel (planetmaker) - Monday, 25 January 2010, 23:39 GMT
I tested this stuff again in r18917:
* Upon startup (in windowed mode), SDL port seems to fail to set a video mode properly according to the console output:
~/ottd/trunk> dbg: [driver] Setting video mode failed, falling back to 640x480 windowed mode.
* I cannot reproduce the crash / assertion upon exit with this version.
Comment by urdh (urdh) - Saturday, 10 July 2010, 13:33 GMT
I can reproduce a, b and c on OSX 10.6.4 with SDL 1.2.14 in r20110.
I did get a segmentation fault on exit (no assert failure though, crash.log attached), as well as the "dbg: [driver] Setting video mode failed, falling back to 640x480 windowed mode." message on start. Going to take a closer look at the video mode failure.

Edit: the debug message is on line 250 in src/video/cocoa/ - should openttd ever reach this code, considering the function (QZ_CreateSubdriver) only tries to set up Quartz and Quickdraw subroutines? ./configure should have disabled these, no? If so, no wonder the SDL port isn't able to set a video mode. (I'm no Obj-C coder, and I don't have much experience with these APIs, but it doesn't seem right)
Comment by Ingo von Borstel (planetmaker) - Friday, 08 October 2010, 09:26 GMT
Compiling OpenTTD r20904, x64, with on-board graphics, on 10.6.4 with gcc version 4.2.1 (Apple Inc. build 5664), using
./configure --with-ccache --with-sdl --disable-cocoa-quartz --disable-cocoa-quickdraw
/Users/ingo/ottd/trunk/src/video/cocoa/ In function ‘CocoaSubdriver* QZ_CreateWindowSubdriver(int, int, int)’:
/Users/ingo/ottd/trunk/src/video/cocoa/ warning: unused variable ‘ret’
and on start still issues a) - d)
dbg: [driver] Setting video mode failed, falling back to 640x480 windowed mode.
2010-10-08 11:11:21.049 openttd[92049:460b] *** __NSAutoreleaseNoPool(): Object 0x116a4da30 of class NSWindowGraphicsContext autoreleased with no pool in place - just leaking
(... repeated zillion times ...)
dbg: [driver] cocoa_s: Core_CloseAudio: AudioOutputUnitStop failed

The smear of the re-size button on the lower right seems to be related to the failure to set a proper video mode. It only smears outside the upper left 640x480 pixels of the window.
Comment by Ingo von Borstel (planetmaker) - Wednesday, 15 December 2010, 01:33 GMT
Issues a), and b) seem gone after having updated libsdl to version "libsdl @1.2.14, Revision 8 (devel, multimedia)" - thus seem to be an issue with the SDL implementation on OSX which got fixed in at least revision 8 of macport's SDL 1.2.14
Comment by Remko Bijker (Rubidium) - Wednesday, 15 December 2010, 09:22 GMT seems to imply c is an SDL issue as well. e probably is also something that's basically SDL. Only real issue remaining is d, though you seem to not be able to reproduce it anymore right?

Maybe it's time to move this to the external type?
Comment by Ingo von Borstel (planetmaker) - Wednesday, 15 December 2010, 10:36 GMT
Thanks for that hint wrt. c) As I could re-recreate the crash described as in d) yesterday, there seems to be some twist to that it only triggers under some conditions.