SDL_timer code for Mac

Hello -

Here is a src/macos/SDL_timer.c with working timer code. At least it
works for testtimer and my game. :slight_smile: This code is PPC only, but if
someone is working on SDL for Mac68K I can provide code for that too.
Is anyone working on the sound for the Mac? I am about to start on it,
and I do not want to duplicate efforts.

Thanks,
Max Watson <@Max_Watson>
-------------- next part --------------
A non-text attachment was scrubbed…
Name: SDL_timer.c.gz
Type: application/x-gzip
Size: 1468 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/19990714/0370a9d0/attachment.bin

Here is a src/macos/SDL_timer.c with working timer code. At least it
works for testtimer and my game. :slight_smile:
What game might that be? I looked around the BlackHoleSun web site, but
most of the links were broken.

This code is PPC only, but if someone is working on SDL for Mac68K
I can provide code for that too.
I think that 68k is probably pointless. It’s slow and Apple doesn’t
support it any more. I think it would be more worth while trying to make
sure the Mac SDL files compile under Carbon.

Kyle Ellrott

f u cn rd ths thn u cn gt gd jb prgrmmng cmptrs---------
The opinions expressed do not reflect those of my
employer. Mostly because I’m unemployed.
-----------------------------------E-mail for public key

Kyle wrote:

Here is a src/macos/SDL_timer.c with working timer code. At least it
works for testtimer and my game. :slight_smile:
What game might that be? I looked around the BlackHoleSun web site, but
most of the links were broken.

Uh, yeah, the webmaster is a slacker. :slight_smile: The new SDL game is called
Krilo. It is a puzzle/strategy game. I will let the SDL list know when
it is ready for human consumption.

I think that 68k is probably pointless. It’s slow and Apple doesn’t
support it any more. I think it would be more worth while trying to make
sure the Mac SDL files compile under Carbon.

Sounds good to me. Mac68K programming is hairy, and there is plenty that
SDL needs still for the MacPPC part.

Thanks,
Max Watson <@Max_Watson>

Sounds good to me. Mac68K programming is hairy, and there is plenty that
SDL needs still for the MacPPC part.

How complete is it now. I know I keep meaning to do something with it, but
I never seem to find time.

I would love to start porting Gorilla Warfare (or even Monkey Shines) to
SDL. I guess I could manage with graphics and input at the moment. I would
prefer to do my development under MacOS until I know it works with SDL,
then look at other platforms.

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

http://www.cf.ac.uk/uwcc/chemy/ (Departmental homepage)
http://www.cf.ac.uk/uwc/chemy/staff/elliott.html (Personal homepage)

Mark Elliott wrote:

Sounds good to me. Mac68K programming is hairy, and there is plenty that
SDL needs still for the MacPPC part.

How complete is it now. I know I keep meaning to do something with it, but
I never seem to find time.

Video (minus 8bpp), Events (system, keys, and mouse), Timer, and some of
the WM stuff works. Cdrom and Sound are still stubbed out. I am guessing
that Threads will never work. (Someone correct me if I am wrong.)

I would love to start porting Gorilla Warfare (or even Monkey Shines) to
SDL. I guess I could manage with graphics and input at the moment. I would
prefer to do my development under MacOS until I know it works with SDL,
then look at other platforms.

I have never heard of these games. Can I get a link?

Thanks,
Max Watson <@Max_Watson>

I am guessing that Threads will never work. (Someone correct me if I am
wrong.)

I imagine they’ll have an API for OS X that’s relatively sane (maybe even
POSIX). For earlier versions, there is a thread library for MacOS. I don’t
remember where I got it, or documentation for it (somewhere on Apple’s
site, maybe), but I’ve actually written a multi-threaded webserver for
MacOS (scary, I know), so it is possible.

I would offer to add support to SDL, but I’ve already offered to do a
dozen other things on other projects, which I haven’t gotten to. And I
don’t have a Mac. And it would be so much simpler with OS X, anyway, it
seems like a waste.

In the meantime, you could probably fake a lot of the threaded stuff with
just a bit of code.

Justin

I am guessing that Threads will never work. (Someone correct me if I am
wrong.)
It will work on a machine running MacOSX. I’m assuming that the thread
interface will be the same as it is now, the only difference will be that
if you try initialize a preemptive thread (mac had those on 68k, but not
power pc, I don’t know why), you’ll have to look for an error message. If
it returns something like kInvalidPeramters then your probably on a PPC
running pre OS X. Then the thread system will have to shut down.
Of course, they also have pthreads running on MacOSX, so that might be
another option.

Kyle Ellrott

f u cn rd ths thn u cn gt gd jb prgrmmng cmptrs---------
The opinions expressed do not reflect those of my
employer. Mostly because I’m unemployed.
-----------------------------------E-mail for public key

For earlier versions, there is a thread library for MacOS. I don’t
remember where I got it,
It’s part of the Universal Headers 3.2

In the meantime, you could probably fake a lot of the threaded stuff with
just a bit of code.
The main problem with pre-Mac OSX code is that it’s co-operative. In order
the pass over the another thread, you need to call YieldToAnyThread() to
switch over.
Maybe we could could add something like
#define ThreadTime #ifdef cooperative_threading
YieldToAnyThread();
#endif
And ask nice programmer to sprinkle that inside every loop. Yes, I know
it’s a giagantic pain the butt.

Kyle

f u cn rd ths thn u cn gt gd jb prgrmmng cmptrs---------
The opinions expressed do not reflect those of my
employer. Mostly because I’m unemployed.
-----------------------------------E-mail for public key

The main problem with pre-Mac OSX code is that it’s co-operative. In order
the pass over the another thread, you need to call YieldToAnyThread() to
switch over.
Maybe we could could add something like
#define ThreadTime #ifdef cooperative_threading
YieldToAnyThread();
#endif
And ask nice programmer to sprinkle that inside every loop. Yes, I know
it’s a giagantic pain the butt.

That’s basically what I was thinking, but perhaps stick that inside some
of the SDL event stuff (SDL has a poll for events kind of call, right?).
Keep it in the SDL code, and primarily just in areas where the thread’s
likely to be sitting around and waiting for something to happen.

It certainly wouldn’t work real well, and it might still require some
changes from the non-MacOS versions of SDL apps (for instance, if you have
a thread which never waits for anything, it wouldn’t work particularly
well), but it might save a more substantial rewrite for someone who used
threads heavily.

In late August, I’ll be in an environment with plenty of Macs and Mac
compilers, so if no one gets to it by then, I might take a crack at it.

Justin