Has anybody looked at porting Soul Ride to OS X?

Well I looked at it, but that does not mean I could do it. Clearly we would not simply want an X11 port, although that would be the easiest I guess. I would certainly like to get to know the terrain code, but that's just the latest on a growing list of terrain renderers in C++ that are out there.

Maybe I'll spend some time looking over the code, maybe put together a PB project and get a feel for exactly how much work would be involved.

Actually I wonder if getting the X11 version running first would not be the most sensible approach. Personally I have done very little X11, but if it's all OpenGL, it probably won't be a big deal. That said, it probably won't be a big deal to switch over to a full screen CG app.

Isn't the linux version sdl anyway?

I see from the makefile that you are correct. I have some other apps that use SDL running (like Wings 3D), so maybe this will be a trivial port. I'll mess around with it for a little while now and see what I can come up with.

Uses linux soundcard support stuff though... Didn't someone write a little wrapper library for that though?

Funny that is what I am looking at now and why I came back to make another post.

The whole project assumes Linux with the alternative being Windows. The file gg_audio.cpp begins with a comment saying that it is a wrapper for DirectSound. I assume that is part of DirectX. For header files this is easy enough, but for everything else I will have to be be very meticulous, and even then I expect things to crop up. A lot of this file has "#ifndef LINUX ... #endif" all over it. I really wish that they had made two distinct files. I'm wondering whether I should just leave sound out of it initially.

The other thing I cannot be sure I will not have to deal with is endianness issues, since this software is targeted at x86 directly. If it uses only library calls to work with resource data, probably I won't have a problem.

Anyway I got the lua.lib and lualib.lib to compile with PB easily enough. I am working on gamegui.lib target now. I have not even really looked at the code yet, but I'm hopeful that most of the problematic junk will be in this library, and the main game/engine code will be more platform independent.

Edit: a search reveals ~130 uses of either "#ifdef LINUX" or "#ifndef LINUX". I have already fixed a few which are merely for opengl #includes. Most of these are confined to six files: gameloop.cpp, input.cpp, ogl.cpp, oglrender.cpp, gg_actor.cpp and gg_audio.cpp.

The gl stuff looks manageable, mostly relates to windows functions pointers. There are a bunch of pthread references, and I suspect those will work if I just follow the Linux path on OS X. Most other stuff seems to relate to SDL, so again I mostly expect to just convert
#ifndef LINUX
to
#if !defined LINUX && !defined __APPLE__

and
#ifdef LINUX
to #if defined LINUX || defined __APPLE__

We'll see how it goes.

Soul Ride uses powf(), asinf() and some other float-typed math functions which are not in the PPC version of math.h. Need some help here!

I could just use pow and hope the coercion works, but for safety's sake I would have to beware of rounding to zero and special case it, right?

jcr claims sin/pow should work.
http://cocoa.mamasam.com/COCOADEV/2002/06/2/37707.php

The float versions of the math functions are in 10.2, but weren't in 10.1.

I checked the file, and the prototypes are not there. I have 10.2.3. So, I am confused, but if JCR says it works, I will trust coercion.

I need a PPC version of this:

asm("fistpl %0" : "=m" (i) : "t" (f) : "st");

from the function
[SOURCECODE]inline int frnd(float f)
// Rounds f to the nearest int.
{
int i;
#if !defined LINUX && !defined __APPLE__
_asm {
fld f;
fistp i;
}
#else // LINUX (really gcc)
asm("fistpl %0" : "=m" (i) : "t" (f) : "st");
// asm("flds %1; fistpl %0" : "=m" (i) : "m" (f));
#endif // LINUX (really gcc)
return i;
}
[/SOURCECODE]

I will try to simply use straight C/C++.

On 10.2, lrint() (& lrintf()) are what you want.

Weird, I can't see powf() or sqrtf() in the header file, but it did compile when I used powf() in a test file...

OSC, I found that math function, too, and that works fine.

I had some problems fighting with a few files, only to realize that they aren't actually used.

Now I've got the problem I predicted: the sound capability depends upon SDL_mixer.h -> not in the Mac OS X port, that I can find. Is there any chance this is a subsidiary library? I'll have to look into it.

SDL_mixer is a separate framework, not part of SDL. It does work properly on Mac OS X, though. Get it from http://www.libsdl.org/projects/SDL_mixer/

Damn you are fast! I just downloaded it now, figuring that was a big hole that somebody MUST have filled. Sure enough... OK, back in a while...