Mac OS X Goodies For You

I’ve been working on some native (Non-Carbon) video code for SDL
for about the past 2 month, and I finally have something to show off.
Just briefly, I’d like to outline what I have done (more info later if
there are questions), then you should download some of the stuff listed
below if you want to check it out.

 I have coded the majority of the internal video functions that 

hold up SDL’s video and event subsystems. The implementation is
Cocoa-based; the source files are compiled by the Objective-C compiler,
but on casual glance they look like normal C code (one of the beauties
of ObjC IMHO). By Cocoa-based, I mean that the window is of the NSWindow
variety, and the event loop is of the NSApplication variety. There is
still some Carbon code here, for functions that are not yet in Cocoa (or
may never be, keep your fingers crossed). The Cursor code could be
ported to Cocoa using the NSCursor class. Other things like
HideMenuBar() seem to have no Cocoa equivalents.

The drawing surface is set up either as a direct pointer to VRAM in 

the fullscreen case, or a pointer to a QuickDraw port in the windowed
case. I have made a point of optimizing the in -a-window drawing to
avoid the triple-buffer dilemma in the current Carbon video code, so you
may notice some increased fps in your apps. Currently, there is no
support for blit acceleration, although hardware palette and gamma
functions are available. There are some artefacts in fullscreen mode
that I hope to get cleared up by submitting a bug report to Apple.

Oh, and OpenGL works, except for fullscreen using the Software 

Renderer.

The event loop has support for (real) 3-button mice, and scroll 

wheel, which might interest some of you. There is still 3-button mouse
emulation for those unfortunate single-button mouse users.

The sound support is still using CarbonSound (SoundManager API). I 

have added locks to the callback to better support the LockAudio() api.

There is currently no joystick support coded yet. The HID Manager, 

part of IOKit that handles HID-class USB devices, has not been
documented until recently (today?) and sample code will follow soon that
will help speed things along once they get started (I will try if I have
the free time).

There is also no CDROM support coded yet. In Mac OS X, Audio CD's 

mount as a directory containing .aiff files, so we will require some
trickery to simulate a true CDRom device.

As a last note, I am building everything using the Framework shared 

library model in Project Builder, which is not very intuitive to the
standard UNIX shared library model that many of you already know. I’ve
tried to explain it in the README included with the SDL Project Builder
Projects. Additionally, you can read more about Frameworks here
(Generalized to Bundles, which is what a Framework really is):

http://developer.apple.com/techpubs/macosx/CoreFoundation/BundleServices/Bundle_Services/
index.html-------------------------------------------------------

In this directory you will find lots of goodies (I will add more 

later, maybe right after I write this).

http://icdweb.cc.purdue.edu/~walisser/sdl/macosx/

Here is what is there now:

SDL.tar.gz - Current CVS augmented by my new code. Will someone create
patches please?

SMPEGPBProject.tar.gz - Project Builder files for SMPEG.

SDLMixerPBProject.tar.gz - Project Builder files for SDLMixer

CircusLinux.tar.gz - Source and Project for the game.

Maelstrom.tar.gz - Same for Maelstrom GPL.

I’ve been working on some native (Non-Carbon) video code for SDL
for about the past 2 month, and I finally have something to show off.
Just briefly, I’d like to outline what I have done (more info later if
there are questions), then you should download some of the stuff listed
below if you want to check it out.


In this directory you will find lots of goodies (I will add more
later, maybe right after I write this).

http://icdweb.cc.purdue.edu/~walisser/sdl/macosx/

Here is what is there now:
SDL.tar.gz - Current CVS augmented by my new code. Will someone create
patches please?

Hi Darrell

First of all, thanks for all the hard work. Looks like you’ve put in
lots of effort.

I already have SDL 1.2.0 buidling successsfully on OS X the
"old-fashioned" way (i.e. ./configure;make), but I’m having problems
with the archive and project file you created.

I’m using Project Builder 1.0 (1.01 isn’t available for download yet).
I simply downloaded your archive, and am working from inside it’s
directory structure.
After resolving a few hard-coded absolute paths, and adding about 10
more SDL_*.h header files to the project, I’m to “almost” get the
Framework to build (the main library builds OK). I’ve included the end
part of the build log below. Do you have nay ideas why I’m having
problems? I’ve only just started using Project Buildedr/Mac OS X, so
I’m may be missing something obvious (or have done something to cause
the errors).

-----Build log---------------

 /usr/bin/nmedit  -s "../../src/main/macosx/exports/SDL.x"  

“/Users/silvan/Desktop/SDL
Folder/SDL/PBprojects/SDL/build/intermediates/Framework.build/master.o”
-o “/Users/silvan/Desktop/SDL
Folder/SDL/PBprojects/SDL/build/intermediates/Framework.build/master.o”

…failed MasterObjectFile.EditExports /Users/silvan/Desktop/SDL
Folder/SDL/PBprojects/SDL/build/intermediates/Framework.build/master.o …
…removing /Users/silvan/Desktop/SDL
Folder/SDL/PBprojects/SDL/build/intermediates/Framework.build/master.oOn Sunday, June 3, 2001, at 08:17 PM, Darrell Walisser wrote:



David

I’m using Project Builder 1.0 (1.01 isn’t available for download yet).
I simply downloaded your archive, and am working from inside it’s
directory structure.
After resolving a few hard-coded absolute paths, and adding about 10
more SDL_*.h header files to the project, I’m to “almost” get the
Framework to build (the main library builds OK). I

Could you send the modified files back to me, or tell me what exactly
went wrong (offline to my personal email)?

've included the end part of the build log below. Do you have nay
ideas why I’m having problems? I’ve only just started using Project
Buildedr/Mac OS X, so I’m may be missing something obvious (or have
done something to cause the errors).

-----Build log---------------

/usr/bin/nmedit  -s "../../src/main/macosx/exports/SDL.x"  

“/Users/silvan/Desktop/SDL
Folder/SDL/PBprojects/SDL/build/intermediates/Framework.build/master.o”
-o “/Users/silvan/Desktop/SDL
Folder/SDL/PBprojects/SDL/build/intermediates/Framework.build/master.o”

…failed MasterObjectFile.EditExports /Users/silvan/Desktop/SDL
Folder/SDL/PBprojects/SDL/build/intermediates/Framework.build/master.o …
.
…removing /Users/silvan/Desktop/SDL
Folder/SDL/PBprojects/SDL/build/intermediates/Framework.build/master.o


This looks like the linkeditor feature in the older version of
ProjectBuilder is broken. Try turning up the log detail in the
preferences of Project Builder to (hopefully) see more information on
this. If you can’t get it resolved, I think you can get around this by
going to the Framework Target’s Build Settings->Linker Settings and
removing that text in the exports field. Hopefully that will help.On Wednesday, June 6, 2001, at 02:37 PM, David Marshman wrote:

I’ve been working on some native (Non-Carbon) video code for SDL
for about the past 2 month, and I finally have something to show off.
Just briefly, I’d like to outline what I have done (more info later if
there are questions), then you should download some of the stuff listed
below if you want to check it out.

Very cool Darrell. :slight_smile:

I’m curious what the performance is, compared to the original Carbon code?

Here is what is there now:
SDL.tar.gz - Current CVS augmented by my new code. Will someone create
patches please?

I’ve integrated your changes with the latest CVS code for SDL 1.2.1
Note that the CVS module for SDL 1.2 has changed, it’s now “SDL12”,
instead of “SDL” with a tag.

Please let me know when you have a working set of Project Builder files
for SDL, and I’ll include those as well. I noticed that somebody had
problems with the projects you had originally.

Thanks!
-Sam Lantinga, Lead Programmer, Loki Software, Inc.

I’m curious what the performance is, compared to the original Carbon code?

For in-a-window drawing, speedup should be substantial, though not nearly
as fast as OS 9 or Classic. This stems from the fact that we used to be
triple buffering our windows in the original Carbon code. Classic seems to
bypass the window server to draw directly to VRAM; there doesn’t seem to
be a way to get this going in a macho-o or CFM/Carbon application yet,
though there is hope that Retained windows will come to the rescue here.
Retained windows should be able to draw directly to the screen when they
are not occluded.On Thu, 7 Jun 2001, Sam Lantinga wrote:

Please let me know when you have a working set of Project Builder files
for SDL, and I’ll include those as well. I noticed that somebody had
problems with the projects you had originally.

Thanks!
-Sam Lantinga, Lead Programmer, Loki Software, Inc.

Please let me know when you have a working set of Project Builder files
for SDL, and I’ll include those as well. I noticed that somebody had
problems with the projects you had originally.

I grabbed the SDL12 branch, and fixed up the projects. The files 

can be found here:

http://icdweb.cc.purdue.edu/~walisser/sdl/macosx

SDLMain.nib.tar.gz - put in src/main/macosx
SDL12.diff.txt - diffs for src/main/macosx (a small
change for exports)
SDLPBProjects.tar.gz - fixed up projects

Have a nice day!
Darrell

I’m having problems with the new projects–Project Builder can’t find the
SDL headers in the various SDL/src directories (e.g. SDL_audio_c.h) unless
I add those directories to the Header Search Paths field under the “Build
Settings” tab for each target.

ChrisOn Sat, 9 Jun 2001, Darrell Walisser wrote:

Please let me know when you have a working set of Project Builder files
for SDL, and I’ll include those as well. I noticed that somebody had
problems with the projects you had originally.

I grabbed the SDL12 branch, and fixed up the projects. The files
can be found here:

http://icdweb.cc.purdue.edu/~walisser/sdl/macosx

SDLMain.nib.tar.gz - put in src/main/macosx
SDL12.diff.txt - diffs for src/main/macosx (a small
change for exports)
SDLPBProjects.tar.gz - fixed up projects

Have a nice day!
Darrell

That must be an issue with the older version of project builder (mine is
1.0.1)

Could you correct the errors and send that back to me?On Saturday, June 9, 2001, at 08:36 PM, Chris Lovell wrote:

I’m having problems with the new projects–Project Builder can’t find
the
SDL headers in the various SDL/src directories (e.g. SDL_audio_c.h)
unless
I add those directories to the Header Search Paths field under the
"Build
Settings" tab for each target.

Chris

On Sat, 9 Jun 2001, Darrell Walisser wrote:

Please let me know when you have a working set of Project Builder
files
for SDL, and I’ll include those as well. I noticed that somebody had
problems with the projects you had originally.

I grabbed the SDL12 branch, and fixed up the projects. The files
can be found here:

http://icdweb.cc.purdue.edu/~walisser/sdl/macosx

SDLMain.nib.tar.gz - put in src/main/macosx
SDL12.diff.txt - diffs for src/main/macosx (a small
change for exports)
SDLPBProjects.tar.gz - fixed up projects

Have a nice day!
Darrell

Darrell, is there any way to get stderr and stdout from the SDL test
programs built with the Project Builder projects? I’d like to compare
framerates with the Carbon code.

Thanks!
-Sam Lantinga, Lead Programmer, Loki Software, Inc.

The latest CVS snapshot has working Project Builder projects for MacOS X.

Thanks Darrell!

-Sam Lantinga, Lead Programmer, Loki Software, Inc.

If you run from project builder, the output will appear in projectbuilder

if you run from the finder, the output will appear in Console.app (in
Applications/Utilities)

The preferred method is to run from project builder, since you can edit
the arguments sent to the app (in Target Settings->Executibles)

HTH,
DarrellOn Sunday, June 10, 2001, at 12:49 PM, Sam Lantinga wrote:

Darrell, is there any way to get stderr and stdout from the SDL test
programs built with the Project Builder projects? I’d like to compare
framerates with the Carbon code.

Thanks!
-Sam Lantinga, Lead Programmer, Loki Software, Inc.

Darrell, is there any way to get stderr and stdout from the SDL test
programs built with the Project Builder projects? I’d like to compare
framerates with the Carbon code.

Thanks!
-Sam Lantinga, Lead Programmer, Loki Software, Inc.

Sam, the way I’ve been running them (after building them in Project
Builder) is to cd to the builds directory, the run the app by typing the
following:

./.app/Contents/MacOS/

Here’s an example (running on my Powerbook G3 (400 Mhz):

[localhost:PBProjects/SDLTest/build] silvan%
./testsprite.app/Contents/MacOS/testsprite
Screen is at 32 bits per pixel
Screen is in system memory
Sprite is in system memory
26.30 frames per second

Hope this helps. It may not be the correct way to do it (I’m an OS X
newbie), but it works here…

BTW, the testGL app returns the following:

[localhost:PBProjects/SDLTest/build] silvan%
./testgl.app/Contents/MacOS/testgl
No OpenGL support on this system

Any ideas how to get GL support in OS X - does SDL support it yet on OS
X?On Sunday, June 10, 2001, at 01:49 PM, Sam Lantinga wrote:


David Marshman

Sam, the way I’ve been running them (after building them in Project
Builder) is to cd to the builds directory, the run the app by typing
the following:

./.app/Contents/MacOS/

You can also use:

open .app

but you lose the ability to pass arguments to the app. BTW, this is just
like double clicking on the app’s icon in the Finder.

BTW, the testGL app returns the following:

[localhost:PBProjects/SDLTest/build] silvan%
./testgl.app/Contents/MacOS/testgl
No OpenGL support on this system

Any ideas how to get GL support in OS X - does SDL support it yet on OS
X?

I made a small error in the projects. If you go to

SDLTest->Target: testgl->Build Settings->Build Settings

and put -DHAVE_OPENGL in for the OTHER_CFLAGS variable, clean and
rebuild and it will work.

Updates and fixes:

-fixed erasing window when minmizing it (with some minor window redraw
problems)
-implemented close box to send SDLQuit event
-fixed messed up alpha on 32bpp windows
-fixed an error in the projects when building testgl. If you go to

SDLTest.pbproj->Target: testgl->Build Settings->Build Settings
and put -DHAVE_OPENGL in for the OTHER_CFLAGS variable, clean and 

rebuild and it will work.

Here you will find the changes:
http://icdweb.cc.purdue.edu/~walisser/sdl/macosx

diff-1.2.1.txt – The diff for these changes. excluding the projects
(I made it with > cvs diff > diff-1.2.1.txt in the src/video/quartz
directory)

SDL-1.2.1.pkg.tar.gz - Package for installing this version of the
library. It is installing into /Library/Frameworks. You can verify that
the library works with all the tests/apps by temporarily removing
SDL.framework from ~/Library/Frameworks

Have a nice day!
DarrellOn Sunday, June 10, 2001, at 02:29 PM, Darrell Walisser wrote:

If you run from project builder, the output will appear in
projectbuilder

if you run from the finder, the output will appear in Console.app (in
Applications/Utilities)

The preferred method is to run from project builder, since you can edit
the arguments sent to the app (in Target Settings->Executibles)

HTH,
Darrell

On Sunday, June 10, 2001, at 12:49 PM, Sam Lantinga wrote:

Darrell, is there any way to get stderr and stdout from the SDL test
programs built with the Project Builder projects? I’d like to compare
framerates with the Carbon code.

Thanks!
-Sam Lantinga, Lead Programmer, Loki Software, Inc.

Updates and fixes:

-fixed erasing window when minmizing it (with some minor window redraw
problems)
-implemented close box to send SDLQuit event
-fixed messed up alpha on 32bpp windows

Committed to CVS.

SDL-1.2.1.pkg.tar.gz - Package for installing this version of the
library. It is installing into /Library/Frameworks. You can verify that
the library works with all the tests/apps by temporarily removing
SDL.framework from ~/Library/Frameworks

Thanks! I’ll release that with the SDL 1.2.1 release next week.

See ya,
-Sam Lantinga, Lead Programmer, Loki Software, Inc.

The latest CVS snapshot has added the following improvements:

  • Removed fullscreen menu option from the “Window” menu
  • Updated the BUGS file
  • Fixed command line parameters when launched from Finder
  • Implemented setting the icon window caption
  • Implemented frameless style windows
  • Added note about SDL_RESIZABLE implementation to SDL_QuartzVideo.m
  • Window close requests now go through the event filtering system

I have a hunch that the window management buttons don’t draw properly
because the SDLMain object never returns from the
applicationDidFinishLaunching() procedure. What do you think, Stan, Darrell?

SDL-1.2.1.pkg.tar.gz - Package for installing this version of the
library. It is installing into /Library/Frameworks. You can verify that
the library works with all the tests/apps by temporarily removing
SDL.framework from ~/Library/Frameworks

I wasn’t actually able to install the package. The installer program
would launch, but there would be no install prompt and no error message.
Is there a way for an end-user to create an installable package?

See ya!
-Sam Lantinga, Lead Programmer, Loki Software, Inc.

I have a hunch that the window management buttons don’t draw properly
because the SDLMain object never returns from the
applicationDidFinishLaunching() procedure. What do you think, Stan,
Darrell?

This is partliallly correct. The other issue is that the window is set
up as Retained, which doesn’t work quite right on OS X. We can fix this
by setting the backingType of the NSWIndow to NSBackingStoreBuffered
instead of NSBackingStoreRetained.

Also, when deminiaturizing the window, I am overriding the window’s
display method so that the contents don’t get erased. The side effect of
this is that the window title bar might not draw correctly.

The fact that we don’t return from applicationDidFinishLaunching causes
some headaches that are not only visual. We also have to manually send
events to the window, since we have essentially interrupted the default
event loop of the application to run our own. For example, I have to
test every a lot of events to see if then were actually in the window
before sending them to SDL. It is possible to override the sendEvent:
method in NSWindow and insert our event handler, but then our event
handler would be running in a separate thread, which is an issue I
didn’t want to deal with. There is also the problem that some events
will not get sent to the window by the default event loop, like
application activation.

To summarize, an alternative implementation would be:

in applicationDidFinishLaunching would start up a new thread that
invokes SDL_main. Events are trapped by the NSWindow’s sendEvent:
method, which we override and replace with a close copy of my current
event code.

There is another caveat with this approach; some of the OS calls I am
using may not be thread safe, so strange things might occur, or maybe it
won’t work at all. I tried running SDL_main in a separate thread a long
time ago and it didn’t work. I didn’t investigate how to remedy the
problem though.

Anyways, I think this problem is worthy of more investigation, if
anything to make the event loop seem like less of a hack.

It might also be possible to send an event to the window after launch to
get it to trick it into looking right. I’ll probably try this fix first.

Later,
DarrellOn Monday, June 11, 2001, at 01:48 AM, Sam Lantinga wrote:

SDL-1.2.1.pkg.tar.gz - Package for installing this version of the
library. It is installing into /Library/Frameworks. You can verify
that
the library works with all the tests/apps by temporarily removing
SDL.framework from ~/Library/Frameworks

I wasn’t actually able to install the package. The installer program
would launch, but there would be no install prompt and no error message.
Is there a way for an end-user to create an installable package?

See ya!
-Sam Lantinga, Lead Programmer, Loki Software, Inc.

I have a hunch that the window management buttons don’t draw properly
because the SDLMain object never returns from the
applicationDidFinishLaunching() procedure. What do you think, Stan,
Darrell?

This is partliallly correct. The other issue is that the window is set
up as Retained, which doesn’t work quite right on OS X. We can fix this
by setting the backingType of the NSWIndow to NSBackingStoreBuffered
instead of NSBackingStoreRetained.

I tried this briefly, and I didn’t get any change in framerate with a
completely exposed testsprite window at 32 bpp. I suspect that like
X11, the backing store code is only invoked when the window is partially
or completely obscured.

It’s also possible that the QuickDraw port way of doing things overrides
the default backing store behavior. I did notice that it overwrites the
title bar if you don’t correct the drawing offset, and it overwrites the
resize handle at the lower right, if that’s enabled. You can’t actually
resize the window at all …

To summarize, an alternative implementation would be:

in applicationDidFinishLaunching would start up a new thread that
invokes SDL_main. Events are trapped by the NSWindow’s sendEvent:
method, which we override and replace with a close copy of my current
event code.

I tried this last night. The MacOS X window / application architecture
is not thread-safe, so this causes all kinds of headaches.

See ya!
-Sam Lantinga, Lead Programmer, Loki Software, Inc.

SDL-1.2.1.pkg.tar.gz - Package for installing this version of the
library. It is installing into /Library/Frameworks. You can verify
that
the library works with all the tests/apps by temporarily removing
SDL.framework from ~/Library/Frameworks

I wasn’t actually able to install the package. The installer program
would launch, but there would be no install prompt and no error message.
Is there a way for an end-user to create an installable package?

I got this error, somehow the tool didn’t create the package correctly.
I think this file fixes the problem:

http://icdweb.cc.purdue.edu/~walisser/sdl/macosx/SDL-1.2.1.pkg.tar.gz

I think it will be possible to write a shell script to create the
installer. I’ll look into that tonight.

Later,
Darrell