State of SDL on MacOS?

Tord_Jansson · March 1, 2001, 9:19am

Hello everybody,

I’ve recently been offered a contract for developing some commercial
multimedia that needs to run on MacOS and in order to speed up the process
and keep the door open for a future Linux port, I’m thinking about using SDL.

I have good experience of SDL on Linux but hardly knows anything about the
state of the MacOS version except what I’ve been able to read on the homepage
and in the news archive.

What I need to know is if there are any known deficiencies, performance or
compatibility issues (OS version or compiler) that can cause me any trouble.
Is it feasible to build a commercial MacOS game on the state of the current
SDL?

I have a very tough deadline, so I don’t have any time to dive deeply into
SDL, but could handle/fix a few small bugs when I run into them.

Also, is there anyone out there prepared to some quick additional development
on SDL for MacOS (possibly paid) if some showstopper is found?

Please answer asap, I need to know within HOURS!

Best Regards,

Tord Jansson
Moonbridge Software
BladeEnc Maintainer

David_Olofson · March 1, 2001, 12:34pm

Hello everybody,

I’ve recently been offered a contract for developing some commercial
multimedia that needs to run on MacOS and in order to speed up the process
and keep the door open for a future Linux port, I’m thinking about using
SDL.

Might be a good idea to use SDL whether or not you’re going to port anything,
in my experience. Not having to worry about messy multimedia APIs saves a
great deal of time, and I think SDL is pretty much as clean and simple as it
gets, while still delivering excellent performance.

I have good experience of SDL on Linux but hardly knows anything about the
state of the MacOS version except what I’ve been able to read on the
homepage and in the news archive.

What I need to know is if there are any known deficiencies, performance or
compatibility issues (OS version or compiler) that can cause me any
trouble. Is it feasible to build a commercial MacOS game on the state of
the current SDL?

I think there already are a few very high performance MacOS games based on
SDL, but I don’t know much more than that about MacOS, as I’m not using Macs
at all… (If I had one, I’d probably run Linux on it - the G3 and G4 CPUs
are great for DSP, and Linux/lowlatency make it easy to do reliably in real
time.

I have a very tough deadline, so I don’t have any time to dive deeply
into SDL, but could handle/fix a few small bugs when I run into them.

How tough is that, and what are you going to do?

Also, is there anyone out there prepared to some quick additional
development on SDL for MacOS (possibly paid) if some showstopper is found?

Sorry; as I said, I don’t do MacOS…

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 01 March 2001 10:19, Tord Jansson wrote:

Darrell_Walisser · March 1, 2001, 1:22pm

The only really major deficiency is lack of thread support on MacOS 8.x, and
9.x. There are some other minor issues:

Paletted 8-bit modes do not work quite right in window mode. Fine in
fullscreen mode.

There is no accelerated YUV overlay support, but that feature is rarely
used.

Accelerated 2D is sketchy because MacOS doesn’t have very good accelerated
2D stuff yet. I haven’t tested 2D with OpenGL blitting functions, but I
think it would be easy to fix if it’s broken.

other platforms in all of the critical areas (sound, blitting, and events).

I think that’s about it.

If there are any other small problems with SDL that you run into, I can
provide additional help and/or code patches.

Regards,
Darrell>From my porting experience, I feel that performance is comparable to the

From: Tord Jansson <tord.jansson at swipnet.se>
Organization: Moonbridge Software
Reply-To: sdl at lokigames.com
Date: Thu, 1 Mar 2001 10:19:59 +0100
To:
Subject: [SDL] State of SDL on MacOS?

Hello everybody,

I’ve recently been offered a contract for developing some commercial
multimedia that needs to run on MacOS and in order to speed up the process
and keep the door open for a future Linux port, I’m thinking about using SDL.

I have good experience of SDL on Linux but hardly knows anything about the
state of the MacOS version except what I’ve been able to read on the homepage
and in the news archive.

What I need to know is if there are any known deficiencies, performance or
compatibility issues (OS version or compiler) that can cause me any trouble.
Is it feasible to build a commercial MacOS game on the state of the current
SDL?

I have a very tough deadline, so I don’t have any time to dive deeply into
SDL, but could handle/fix a few small bugs when I run into them.

Also, is there anyone out there prepared to some quick additional development
on SDL for MacOS (possibly paid) if some showstopper is found?

Please answer asap, I need to know within HOURS!

Best Regards,

Tord Jansson
Moonbridge Software
BladeEnc Maintainer

Johannes_Fortmann · March 1, 2001, 1:33pm

What I need to know is if there are any known deficiencies, performance or
compatibility issues (OS version or compiler) that can cause me any
trouble.
Is it feasible to build a commercial MacOS game on the state of the
current
SDL?

I did some things in SDL/Mac (i.e. ported my game), and I can say: Graphics
work great, sound doesn’t.
At least a month ago, the sound support in SDL was really crappy. But it
should be no problem to do that
with QuickTime. (as I did)

Darrell_Walisser · March 1, 2001, 3:22pm

What I need to know is if there are any known deficiencies, performance or
compatibility issues (OS version or compiler) that can cause me any
trouble.
Is it feasible to build a commercial MacOS game on the state of the
current
SDL?

I did some things in SDL/Mac (i.e. ported my game), and I can say: Graphics
work great, sound doesn’t.
At least a month ago, the sound support in SDL was really crappy. But it
should be no problem to do that
with QuickTime. (as I did)

What to you mean by “really crappy”? I thought that sound support was
quite good, at least up to par with the other platforms.

The only problem with sound is that you can’t call some functions that are
not interrupt-safe in the mixing routine. It would probably be bad
programming practice anyway to call such functions (like malloc) many
times during the main execution loop of your code.

And there is no code yet (or perhaps never will be) to play mac-standard
AIFF files.

With the SDL_Mixer library, which does mixing in the correct,
platform-agnostic way, there should be no problems (and there are none
that I know of). SDL_Mixer should be used by everyone who wants to play
sound with the easiest API, lowest latency, and greatest portability,
IMHO.

Regards,
Darrell

P.S. I wrote the first stab at sound code about a year ago, and little
has changed, so I’d really like to know what the problem is! Thanks!On Thu, 1 Mar 2001, Pius II. wrote:

Johannes_Fortmann · March 1, 2001, 3:53pm

With the SDL_Mixer library, which does mixing in the correct,
platform-agnostic way, there should be no problems (and there are none
that I know of). SDL_Mixer should be used by everyone who wants to play
sound with the easiest API, lowest latency, and greatest portability,
IMHO.

I used SDL_Mixer with

theSound = Mix_LoadWAV(path);
…
if (theSound) Mix_PlayChannel(-1, theSound, 0);
…
if (theSound) Mix_FreeChunk(theSound);

to play a sound. That sounded ok under all platforms, except MacOS, where
the sound would be distorted.
Perhaps there was something wrong with the samples that only showed up in
the Mac routines… Anyway, QuickTime works great for me, and is installed
on every real Mac, so…

David_Olofson · March 1, 2001, 4:15pm

[…]

The only problem with sound is that you can’t call some functions that are
not interrupt-safe in the mixing routine. It would probably be bad
programming practice anyway to call such functions (like malloc) many
times during the main execution loop of your code.

Besides, you’re almost guaranteed to get random drop-outs if you do any
system calls but the audio API calls from within a low latency thread/ISR,
regardless of platform. That’s just the way is is with real time stuff, even
on real RTOS platforms… (A hard RTOS will either just not provide such
functionality to RT tasks, or silently turn soft when you do Bad Things.)

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 01 March 2001 16:22, Darrell Walisser wrote:

Sam_Hart · March 1, 2001, 6:29pm

But QuickTime is not the best platform-independent way to do things… and for
those of us with no Mac hardware/OS to test on… it becomes very difficult to
use ;-)On Thu, 01 Mar 2001, you wrote:

Perhaps there was something wrong with the samples that only showed up in
the Mac routines… Anyway, QuickTime works great for me, and is installed
on every real Mac, so…

–
Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >

slouken · March 1, 2001, 7:05pm

theSound = Mix_LoadWAV(path);
…
if (theSound) Mix_PlayChannel(-1, theSound, 0);
…
if (theSound) Mix_FreeChunk(theSound);

to play a sound. That sounded ok under all platforms, except MacOS, where
the sound would be distorted.

I recently fixed some serious bugs in the MacOS sound code which would
cause this.

Does it work with SDL 1.1.8?

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Johannes_Fortmann · March 1, 2001, 7:26pm

I recently fixed some serious bugs in the MacOS sound code which would
cause this.

Does it work with SDL 1.1.8?

Don’t know, I ain’t got no Mac, too expensive… (stupid folks at Apple
Germany think a dollar is 3 Marks…Ooops, it is almost there by now

Tord_Jansson · March 1, 2001, 8:30pm

Many thanks for all the answers I received on this subject, especially
Darrell’s detailed answer listing the known problems.

I’m now convinced that SDL is the right base for this project (if I get the
contract). Unfortunatelly I can’t say anything more about the nature of the
project since I’m under a NDA.

Once again, thanks for all the quick and helpfull responses!

Tord Jansson
Moonbridge Software

David_Olofson · March 1, 2001, 8:27pm

Well, either they’re not alone, or Macs are too expensive, period. Otherwise
I’d already be using one with Linux/lowlatency for audio stuff… (There are
other ways to get G3/G4 power, but nothing that resembles a real workstation.)

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 01 March 2001 20:26, Pius II. wrote:

I recently fixed some serious bugs in the MacOS sound code which would
cause this.

Does it work with SDL 1.1.8?

Don’t know, I ain’t got no Mac, too expensive… (stupid folks at Apple
Germany think a dollar is 3 Marks…Ooops, it is almost there by now

Martin_Donlon · March 1, 2001, 8:45pm

Its cyborgs, isn’t it?On Thu, Mar 01, 2001 at 09:30:16PM +0100, Tord Jansson wrote:

I’m now convinced that SDL is the right base for this project (if I get the
contract). Unfortunatelly I can’t say anything more about the nature of the
project since I’m under a NDA.
–
Martin
–
Bother! said Pooh, as he was butchered for his paws & liver.

Max_Horn · March 3, 2001, 9:22am

At 17:15 Uhr +0100 01.03.2001, David Olofson wrote:>On Thursday 01 March 2001 16:22, Darrell Walisser wrote:

[…]

The only problem with sound is that you can’t call some functions that are
not interrupt-safe in the mixing routine. It would probably be bad
programming practice anyway to call such functions (like malloc) many
times during the main execution loop of your code.

Besides, you’re almost guaranteed to get random drop-outs if you do any
system calls but the audio API calls from within a low latency thread/ISR,
regardless of platform. That’s just the way is is with real time stuff, even
on real RTOS platforms… (A hard RTOS will either just not provide such
functionality to RT tasks, or silently turn soft when you do Bad Things.)

Yes, that’s right.

Just as a note: sound works great in Chromium on Mac.

I have had problems with Exult with speech output (was distorted),
which I believe could be tracked back to an endianess error in SDL.
However, that seems to have been fixed in SDL 1.1.8, I will try it
again later today.

Also, the exult code did exactly this sort of bad things, i.e.
calling “new” in a the sound callback… erchh

It is a bad habit on all OS, but on MacOS it caused a complete
freeze every tenth time or so… took me some time to figure out what
it was, since it run fine most of the time.

Max

Max Horn
C/C++ Developer

email: mailto:Max_Horn
phone: (+49) 6151-494890

Max_Horn · March 3, 2001, 9:25am

At 8:22 Uhr -0500 01.03.2001, Darrell Walisser wrote:

The only really major deficiency is lack of thread support on MacOS 8.x, and
9.x. There are some other minor issues:

Paletted 8-bit modes do not work quite right in window mode. Fine in
fullscreen mode.

There is no accelerated YUV overlay support, but that feature is rarely
used.

Accelerated 2D is sketchy because MacOS doesn’t have very good accelerated
2D stuff yet. I haven’t tested 2D with OpenGL blitting functions, but I
think it would be easy to fix if it’s broken.

Just FYI, 2D blitting using OpenGL and/or RAVE works fine and is very
fast. SpritWorld (http://www.spriteworld.org) uses it succesfully in
the (not yet officially released) version 2.4. Maybe something
similiar could be done for SDL, on all platforms? I am very
unexperienced with OpenGL, so I don’t know exactly, but it seems not
that difficult.
The main problem is when to load sprite “textures” to the
accelerator. However, I believe this could be coupled with the "lock"
mechanism.

Max–

Max Horn
C/C++ Developer

email: mailto:Max_Horn
phone: (+49) 6151-494890

David_Olofson · March 3, 2001, 9:58am

At 8:22 Uhr -0500 01.03.2001, Darrell Walisser wrote:

The only really major deficiency is lack of thread support on
MacOS 8.x, and 9.x. There are some other minor issues:

Paletted 8-bit modes do not work quite right in window mode. Fine
in fullscreen mode.

There is no accelerated YUV overlay support, but that feature is
rarely used.

Accelerated 2D is sketchy because MacOS doesn’t have very good
accelerated 2D stuff yet. I haven’t tested 2D with OpenGL
blitting functions, but I think it would be easy to fix if it’s
broken.

Just FYI, 2D blitting using OpenGL and/or RAVE works fine and is
very fast. SpritWorld (http://www.spriteworld.org) uses it
succesfully in the (not yet officially released) version 2.4. Maybe
something similiar could be done for SDL, on all platforms? I am
very unexperienced with OpenGL, so I don’t know exactly, but it
seems not that difficult.

I’m occasionally working on something along those lines…

The main problem is when to load sprite “textures” to the
accelerator. However, I believe this could be coupled with the
"lock" mechanism.

Yeah… I don’t see any particularly big problem with that, not even
with non-power-of-2 and non-quadratic surfaces (I’m using “tile
palette” surfaces), but there could be issues with surfaces larger
than 256x256 pixels, as some 3D accelerators can’t handle that. Tiled
sprites (“multisprites”) should work just fine, though, unless I’m
missing something. (The usual “edge fixing” is required for
interpolated/filtered rendering, of course.)

Right; filtering. I’m using that for sub pixel accurate rendering and
antialiazing, and (obviously), the former requires additional
coordinate resolution. Antialiazing can be handled quite easily and
efficiently for sprites (tiling, using separate polygons for alpha
and opaque areas, conceptually similar to the RLE encoding), but
tiled backgrounds are more complicated… (The problem is that you
can’t fix the tile edges for interpolation without looking at the map
data, and you can’t do sub pixel accurate positioning without fixing
the edges… My engine is aware of tiled map layers to deal with that
kind of stuff transparently.)

Anyway, those problems are only related to sub pixel accurate
rendering - which cannot be supported anyway, as SDL is using integer
coordinates for everything. The rest is doable, I think.

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Saturday 03 March 2001 10:25, Max Horn wrote: