[ODE] Another Cocoa port for Mac OS X

[Shamyl Zakariya]

At least recently, you can build just libode.a on Mac without 
drawstuff. At least on my box, drawstuff won't even compile, much less 
link, but it's irrelevant to me since I've written my own opengl code. 
Which was actually a great learning experience, since up until August 
of last year I was using my home-brew software wire-frame rasterizer  
which I had rolled under linux back when I didn't have a computer with 
OpenGL to work on.

So, if you just run a "make configure" and then "make ode-lib" you'll 
have a usable libode.a -- that plus adding ode's headers to XCode and 
you can have standard include directives like #include <ode/ode.h> and 
everything's peachy.

I've got some demo GLUT code which shows how to set up an XCode project 
that'll do this easy as pie. It uses my own visualization code instead 
of drawstuff, but it's the project itself that's meaningful. Anyway, I 
just offer it in case you're interested.

> I'll buy that, I can imagine it was a pain, for a project a few 
> semesters ago I tried to build a cocoa application on three levels, a 
> pure cocoa front end, a pure C++ game engine and logic (for cross 
> platform to Windows) and an Obj-C++ bridge between them.  Trying to 
> make them all play with the same loaded texture data ended up being a 
> dealbreaker (we ended up turning in the project only for windows)

It was a pain over here too. My Cocoa gui needs to "see" the underlying 
object model, and yet needs ODE hidden... so I had to write my own C++ 
object model and inheritance system which completely hides ODE 
internals. It almost was a disaster ;)

> I'll see if there's any way I can get you into the public beta pool if 
> you want :)
>
> Thanks for all the info, and thanks in advance for any help you may be 
> able to give us in the next few months!

You can count me in for both. I'm happy to help, since people here have 
been happy to help me, even when my questions are completely 
bone-headed, which of late has been embarrassingly true.

shamyl zakariya :: lorem ipsum dolor sit amet,
On May 7, 2004, at 12:23 PM, Jon Woodard wrote:

> Sorry for the inline responses, just wanted to make sure I hit all the 
> points.
>
> On May 6, 2004, at 12:51 PM, Shamyl Zakariya wrote:
>
>> I built ode.framework back for the 0.39 release, when ODE still had 
>> some troubles compiling on Mac OS X. However, ODE seems nowadays to 
>> build cleanly from nightly source tarballs just fine. It became a bit 
>> of a headache to maintain the project when the command-line build 
>> worked just fine, so I've let it go.
>
> I feel bad responding without having tried to build the nightly 
> tarball myself, but I recall the last time we tried something like 
> this, ODE wasn't a fan of compiling without the drawstuff libs, which 
> we really didn't want.  Does it build to something like a .a? or 
> something more useful?
>
>> Also, the only real thing my CocoaODE provided was a 
>> re-implementation of drawstuff using GLUT; but since you're planning 
>> on doing games I imagine you've got better a OpenGL platform anyway.
>
> Yeah, we're going to be using SDL and their OGL stuff
>
>> For what it's worth, in my experience ODE has one significant problem 
>> as regards Cocoa but since I'm not a Carbon developer I can't say if 
>> it would be a problem for you. ODE makes use, in its headers, of many 
>> function parameter names called "id" which simply doesn't play well 
>> with Objective-C or Objective-C++ where that's a reserved keyword. 
>> Accordingly, I've had to go through some hoops to hide ODE from my 
>> GUI code without hiding too much of my object model.
>
> I'll buy that, I can imagine it was a pain, for a project a few 
> semesters ago I tried to build a cocoa application on three levels, a 
> pure cocoa front end, a pure C++ game engine and logic (for cross 
> platform to Windows) and an Obj-C++ bridge between them.  Trying to 
> make them all play with the same loaded texture data ended up being a 
> dealbreaker (we ended up turning in the project only for windows)
>
>> I'd be happy to help you out, if you have any trouble.
>>
>> In my case, I'm now linking against a static binary and while that's 
>> nowhere near as slick as Mac OS X's self-contained frameworks, it 
>> does work fine. Were I more comfortable with apple's dev tools on the 
>> command line, I would consider making changes to the build scripts to 
>> build a framework target instead of a static lib. Sounds like a 
>> worthy goal to look into.
>
> That would be enough for us, though if linking statically is going to 
> cause some sort of licensing debacle or we need to to make sure our 
> engine is cleanly written, we may investigate the possibility of 
> making a .framework.
>
>>
>>> I'm in the process of founding a mac game studio
>>
>> Excellent! We mac users are generally left out in the cold :(
>
> I'll see if there's any way I can get you into the public beta pool if 
> you want :)
>
> Thanks for all the info, and thanks in advance for any help you may be 
> able to give us in the next few months!
>
> -Jon Woodard
>