Mac OS X Video Drivers [patch]

Anders_F_Bjorklund · May 30, 2005, 9:29pm

I’ve updated/added the Carbon and X11 video drivers
to the Mac OS X port of SDL 1.2 (the CVS version),
and made the Cocoa driver and runtime optional.

The default is still Cocoa, and the “Quartz” driver.
But you can now also use “toolbox” for Carbon, and
"x11" for running with Apple’s (or other) X11 server:

export SDL_VIDEODRIVER=x11
export SDL_VIDEO_GL_DRIVER=/usr/X11R6/lib/libGL.dylib

It also checks if the frameworks are available, by a:
#include <Carbon/Carbon.h> or #import <Cocoa/Cocoa.h>
(this should make it configure on plain Darwin as well?)

Here are the new configure targets:
–enable-video-cocoa use Cocoa/Quartz video driver default=yes
–enable-video-carbon use Carbon/QuickDraw video driver default=yes
–enable-video-x11 use X11 video driver default=no

./configure --enable-video-cocoa --enable-video-carbon
–enable-video-x11
–x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib

The Carbon version is just an updated version of the old
SDL driver for Mac OS 9, and could probably be improved…
(but it does work, including the Carbon version of SDLmain)

If you disable cocoa, you can run with -framework Carbon only,
and the C version of SDL_main.c. And if you disable carbon too,
you can still use the X11 version which doesn’t require SDLmain.

I updated the DrawSprocket version, but did not include it.
(no blitters or VRAM GWorlds etc. available on OS X anyway)
Besides for Mac OS 9, I don’t think there’s any use for it ?

And note that any performance on Mac OS X equals OpenGL anyway…
You can get “fair” software SDL results on captured CG displays,
but for decent frame rates you need to be using GL for rendering.

Finally, here is the patch itself:
http://www.algonet.se/~afb/SDL-12CVS-macvideo.patch

–anders

PS. It says “video”, but as usual it applies to mouse/keyboard too.

Asko_Kauppi · May 31, 2005, 8:09am

Could you write some more about the strengths of these various
approaches?

Why would I use Carbon, and why X11 mode?

Anders F Bj?rklund kirjoitti 31.5.2005 kello 0.29:> I’ve updated/added the Carbon and X11 video drivers

to the Mac OS X port of SDL 1.2 (the CVS version),
and made the Cocoa driver and runtime optional.

The default is still Cocoa, and the “Quartz” driver.
But you can now also use “toolbox” for Carbon, and
"x11" for running with Apple’s (or other) X11 server:

export SDL_VIDEODRIVER=x11
export SDL_VIDEO_GL_DRIVER=/usr/X11R6/lib/libGL.dylib

It also checks if the frameworks are available, by a:
#include <Carbon/Carbon.h> or #import <Cocoa/Cocoa.h>
(this should make it configure on plain Darwin as well?)

Here are the new configure targets:
–enable-video-cocoa use Cocoa/Quartz video driver default=yes
–enable-video-carbon use Carbon/QuickDraw video driver
default=yes
–enable-video-x11 use X11 video driver default=no

./configure --enable-video-cocoa --enable-video-carbon --enable-
video-x11
–x-includes=/usr/X11R6/include --x-libraries=/usr/
X11R6/lib

The Carbon version is just an updated version of the old
SDL driver for Mac OS 9, and could probably be improved…
(but it does work, including the Carbon version of SDLmain)

If you disable cocoa, you can run with -framework Carbon only,
and the C version of SDL_main.c. And if you disable carbon too,
you can still use the X11 version which doesn’t require SDLmain.

I updated the DrawSprocket version, but did not include it.
(no blitters or VRAM GWorlds etc. available on OS X anyway)
Besides for Mac OS 9, I don’t think there’s any use for it ?

And note that any performance on Mac OS X equals OpenGL anyway…
You can get “fair” software SDL results on captured CG displays,
but for decent frame rates you need to be using GL for rendering.

Finally, here is the patch itself:
http://www.algonet.se/~afb/SDL-12CVS-macvideo.patch

–anders

PS. It says “video”, but as usual it applies to mouse/keyboard too.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Anders_F_Bjorklund · May 31, 2005, 10:26am

Asko Kauppi wrote:

Could you write some more about the strengths of these various approaches?

Sure, I can give you some brief reasons…

Why would I use Carbon, and why X11 mode?

Carbon is good if you have an Objective-C allergy,
or want to integrate with some old Mac OS code…
(as happened to be the reason, in my own case)

The Cocoa SDL driver is much more modern and has more
features at the moment… But I guess it’s all about
"Carbon vs. Cocoa", which is quite a topic in itself ?

Much more information is available at:
http://developer.apple.com/carbon/ (“Mac OS 9-like”)
http://developer.apple.com/cocoa/ (“NeXTSTEP-like”)

The X11 version is good for two things:

Trying how it would look like on other X11 platforms
Running on Darwin, i.e. not Mac OS X but plain Darwin.

But you don’t really have to use either of them.

–anders

icculus · June 1, 2005, 7:30am

The X11 version is good for two things:

Trying how it would look like on other X11 platforms

Running on Darwin, i.e. not Mac OS X but plain Darwin.

And running the program remotely, which is a rare, but incredibly useful
trick when you need it.

However, I’d be less inclined to support updating the Carbon target
(because it should be considered as dead as OS9, as such, anything that
might break it on OS9 isn’t a worthwhile patch).

–ryan.

Anders_F_Bjorklund · June 1, 2005, 8:32am

Ryan C. Gordon wrote:

However, I’d be less inclined to support updating the Carbon target
(because it should be considered as dead as OS9, as such, anything that
might break it on OS9 isn’t a worthwhile patch).

Carbon is NOT confined to Mac OS 9; it used to be but is not any longer.
It is now the “procedural interface to Mac OS X”, alongside with Cocoa ?

See http://developer.apple.com/carbon/

CoreGraphics (Quartz 2D) is not a Cocoa/Objective-C technology, it can
be used from Carbon as well. CoreFoundation too ? So it’s “modern”…

Anyway, all the changes are in TARGET_API_MAC_OSX if not applicable to
Mac OS 9 (shared code has TARGET_API_MAC_CARBON, for CarbonLib stuff)

So it shouldn’t break any old code, even if not used very much anymore.
(I do try to run it through in emulation, just to see if it holds up)

And it requires Carbon.framework now anyway, so it doesn’t change much ?
(the Carbon SDL driver was already written, I just updated/fixed it…)

I’m also considering an updated (Mac OS X) version of the Carbon driver.
As for the DrawSprocket driver, now those patches can be dropped

–anders

Asko_Kauppi · June 1, 2005, 11:32am

To confuse people even more (hopefully not?) using Cocoa does not
necessarily imply you need to touch Objective-C. I don’t, and
there’s been no (major) issues with running SDL on Mac OS X. Works
fine.

What I’d like to get, however, is the CVS Altivec optimizations in a
official release. I know… it will happen “some day”. Currently, the
SDL performance on OS X is much, much less than it could be (~30fps
where Windows/Linux runs about twice the speed, on comparable machine).*

-ak

*) “comparable machine” means iMac 700MHz vs. Amilo 1.5GHz laptop.
But honestly, they should be much closer than that.

Anders F Bj?rklund kirjoitti 1.6.2005 kello 11.32:> Ryan C. Gordon wrote:

However, I’d be less inclined to support updating the Carbon
target (because it should be considered as dead as OS9, as such,
anything that might break it on OS9 isn’t a worthwhile patch).

Carbon is NOT confined to Mac OS 9; it used to be but is not any
longer.
It is now the “procedural interface to Mac OS X”, alongside with
Cocoa ?

See http://developer.apple.com/carbon/

CoreGraphics (Quartz 2D) is not a Cocoa/Objective-C technology, it
can be used from Carbon as well. CoreFoundation too ? So it’s
"modern"…

Anyway, all the changes are in TARGET_API_MAC_OSX if not applicable to
Mac OS 9 (shared code has TARGET_API_MAC_CARBON, for CarbonLib stuff)

So it shouldn’t break any old code, even if not used very much
anymore.
(I do try to run it through in emulation, just to see if it holds up)

And it requires Carbon.framework now anyway, so it doesn’t change
much ?
(the Carbon SDL driver was already written, I just updated/fixed
it…)

I’m also considering an updated (Mac OS X) version of the Carbon
driver.
As for the DrawSprocket driver, now those patches can be dropped

–anders

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Anders_F_Bjorklund · June 1, 2005, 12:12pm

Asko Kauppi wrote:

To confuse people even more (hopefully not?) using Cocoa does not
necessarily imply you need to touch Objective-C. I don’t, and there’s
been no (major) issues with running SDL on Mac OS X. Works fine.

Right, I actually meant when hacking SDL internals and the video driver.

As long as you just use the lib, it doesn’t matter all that much…
The only thing is that you need to link to Cocoa.framework (and -lobjc),
and that you get into a world of hurt if trying to mix with alternate
languages that have their own runtime requirements, like the D language.

For some reason the libSDLmain.a is missing from the binary/PKG dist,
and using the SDLMain.m source directly is advocated instead ? (ugh)
(and you need to add all the needed CFLAGS yourself to your projects:
e.g. -I/Library/Frameworks/SDL.framework/Headers and -framework SDL)

But when compiling it yourself, you do get sdl-config and libSDLmain.a.
Maybe one day the PKG installer will be fixed and install those two too?

What I’d like to get, however, is the CVS Altivec optimizations in a
official release. I know… it will happen “some day”. Currently, the SDL
performance on OS X is much, much less than it could be (~30fps where
Windows/Linux runs about twice the speed, on comparable machine).*

Make sure you compare the fullscreen performance, otherwise Quartz
will interfere with the screen updates (double buffering and “smarts”,
where it combines your small delta update rects into a few huge ones)

It’s nice if software blitting has “fair” performance on Mac OS X too,
but the only way to make it fast is to use OpenGL (which is built-in).
Fortunately, it’s not hard to accomplish (I’m doing it in SpriteWorld X)

–anders