SDL/Mac

SDL Development
1

Sam,

I am thinking of either writing wrappers for SDL routines so that MacOS
code will compile and link on linux, or helping with the porting of SDL to
MacOS.

Porting SDL to MacOS will by far be the easiest of the two to do, and I would
appreciate your knowledge and help with the MacOS port.

What stage is this at now, and can I get hold of the source so far,
so I can see how you are doing it ?

Right now I am at the stage of writing working Mac programs to figure
out how things work under MacOS. In about three or four days, I’ll have
a working prototype you can play with.

I have no experience with linux/windows, but plenty on MacOS (Monkey Shines).

Yay! Do you use SoundManager and QuickDraw, or Sprockets?
Is your monitor capable of 16/32-bit display?

Are you using CodeWarrior or MPW?

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

2

Sam,

I am thinking of either writing wrappers for SDL routines so that MacOS
code will compile and link on linux, or helping with the porting of SDL to
MacOS. What stage is this at now, and can I get hold of the source so far,
so I can see how you are doing it ?

I have no experience with linux/windows, but plenty on MacOS (Monkey Shines).

Mark--------------------------------------------------------------------------------
Dr Mark Elliott Tel. (+44)(0)1222 874686
Department of Chemistry Fax. (+44)(0)1222 874030
University of Wales, Cardiff
PO Box 912
Cardiff CF1 3TB
UK email <@Mark_Elliott>

3

Sam,

I am thinking of either writing wrappers for SDL routines so that MacOS
code will compile and link on linux, or helping with the porting of SDL to
MacOS.

Porting SDL to MacOS will by far be the easiest of the two to do, and I would
appreciate your knowledge and help with the MacOS port.

QuickDraw/sprockets. I guess I could write some of the routines pretty
quickly, but I won’t have much time for at least a week.

Right now I am at the stage of writing working Mac programs to figure
out how things work under MacOS. In about three or four days, I’ll have
a working prototype you can play with.

I have no experience with linux/windows, but plenty on MacOS (Monkey
Shines).

Yay! Do you use SoundManager and QuickDraw, or Sprockets?

All of them (well, I use DrawSprocket and InputSprocket - if you forget
about standard input for a little while, I don’t think it will take long to
get the input stuff running. I haven’t looked at your structure definitions
much, but I guess an SDL_Surface is simply an offscreen area for drawing (a
GWorld in QuickDraw). If the void *pixels is a pointer to pixel data either
in true colour or indexed depending on the colour mode, then it shouldn’t
be too hard. Writing directly to screen memory is fairly easy, and pretty
compatible despite what some people would have you believe. Mind you, I
would be tempted to put an intermediate gworld in just as a compatibility
OPTION.

Actually, my first instinct with this was that SDL_BlitSurface is a
CopyBits by any other name, and if we can redefine an SDL surface as

typedef struct SDL_Surface {
GWorldPtr theGWorld;

// followed by all the other stuff

}

it would actually simplify things.

The blitters could be replaced by CopyBits (or more accurately the blitters
could call CopyBits after a bit of setting up), and the pixels would be a
pointer to the start of the GWorld data, so this could be used directly.
You change your structure definitions, but immediately gain the choice of
using quickdraw or direct blitting of data.

I guess I am not much of a purist, but if you can wrap it all up so that
the function calls are the same on all platforms, it wouldn’t matter if
some internal parts of the data structures are platform-dependant, and if
the actual functions handle those data differently.

Maybe I should get a basic library running with SDL_GetVideoMode,
SDL_GetDisplayFormat, SDL_ListModes, and the other video mode stuff,
followed by SDL_AllocSurface (effectively a wrapper for NewGWorld).

I would add SDL_LoadPICT, to handle Mac PICT files, just for simplicity at
first (I don’t know how to handle BMP files, but it can’t be that hard).

In fact, the more I think about it the more I want to start writing code.

Is your monitor capable of 16/32-bit display?

I guess millions of colours is 32 bit, not 24. I can handle millions of
colours at resolutions from 512 x 384 to 1024 x 768.

Are you using CodeWarrior or MPW?

CodeWarrior. I have MPW but have never used it, and I don’t have it
installed at the moment (the learning curve is pretty steep, and I like
CodeWarrior).

Let me know what you think of my ideas.

Mark>From my cursory look, there are enormous similarities between SDL and

Dr Mark Elliott Tel. (+44)(0)1222 874686
Department of Chemistry Fax. (+44)(0)1222 874030
University of Wales, Cardiff
PO Box 912
Cardiff CF1 3TB
UK email <@Mark_Elliott>

4

In fact, the more I think about it the more I want to start writing code.

My plan is to attack the ports similar to the way I’ve been doing it on
other platforms – implement a few system dependent files, and leave everything
else alone.

True, you could redefine SDL surfaces as GWorlds and use QuickDraw on them,
but that wouldn’t be portable.

It’s just as easy to use existing code (which is very flexible) and write
directly to the display.

In a few days I’ll have something up there you can look at. :slight_smile:

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

5

All of them (well, I use DrawSprocket and InputSprocket - if you forget
about standard input for a little while, I don’t think it will take long to
get the input stuff running. I haven’t looked at your structure definitions
much, but I guess an SDL_Surface is simply an offscreen area for drawing (a
GWorld in QuickDraw).

Yes, but don’t forget that both GWorlds and SDL_Surfaces can be on
screen… :slight_smile:

If the void *pixels is a pointer to pixel data either
in true colour or indexed depending on the colour mode, then it shouldn’t
be too hard. Writing directly to screen memory is fairly easy, and pretty
compatible despite what some people would have you believe. Mind you, I
would be tempted to put an intermediate gworld in just as a compatibility
OPTION.

I would think that using copybits would possibly cause problems - copybits
has trouble with big images(rowbytes > 16383 or whatever) and there may be
numerous other out by like problems.

Actually, my first instinct with this was that SDL_BlitSurface is a
CopyBits by any other name, and if we can redefine an SDL surface as

typedef struct SDL_Surface {
GWorldPtr theGWorld;

// followed by all the other stuff
}

Yes, but they may also have legal problems if we use it on other
platforms…

In fact, the more I think about it the more I want to start writing code.

Good to hear! :slight_smile:

CodeWarrior. I have MPW but have never used it, and I don’t have it
installed at the moment (the learning curve is pretty steep, and I like
CodeWarrior).

The big advantage of MPW is that is can read Makefiles. when it comes to
portability, porject files are useless - how many times have you got code
which has a 3 version old project in it which you have to jump through
hoops to read?

Good luck is your adventures, and when it is finished - don’t forget to
post to mgd!

njh