All my additions were made on an Intel iMac with an up to date Leopard 10.5.4 and Xcode 3.0 installed. Further on I've the possibility to work on an older PowerPC G3 PowerMac with an up to date Tiger 10.4.11 and Xcode 2.3 installed. I'm planning to create something like an universal binary supported Raydium framework. With my changes I've made on Raydium you should have the continuing ability to work on Linux and Windows, too.

For now you have to manually obtain and solve the dependencies. Perhaps this will be automated in the future or unnecessary with the planned Raydium framework.Dependencies (Link to the version I've used.) [Relative path to the Raydium base directory I've used.]:

Not all things fully work yet, but I want a full featured Raydium on the Mac, so any help is very appreciated:

- MyGLUT input handling is buggy, especially the mouse movement. Thankfully to Steve J. Baker's PLib it was easy to quickly get the basic structure of "raydium/myglut-macosx.c" working.- Crashing applications when dragging the window for a long time, this is perhaps because of a sound delay issue.- I didn't looked at the joystick part at all. About everything is a dummy in "raydium/joy.c" for now.- Pending live support.

Perhaps you can create a subversion account for me, so I can commit the changes myself. Otherwise I can create a patch everytime with the changes I've made. I'll append a "full" patch package which also contains the new files. The configure, Makefile and ocomp.sh files are copies of the original ones with a "-macosx" suffix in the basename. Hopefully they can be merged with the original ones in the future, we can use some magic stuff like "if `uname` = Darwin then" or something ...Subversion patch package for revision 653: Raydium-R653-MacOSX-Patch.tar.gz (136KB)

Ok, read.
First thanks for trying making the Mac port of Raydium. It was in our TODO for a long time but none of us has a Mac.
Second, yes, i think that you should have an SVN account. I have asked one for you (and another for andgfx) to Xfenec, but he is quite busy so maybe he takes a long time to respond.

Anyway I think that the mac version (cause as you said is much experimental) should be in a different trunk. In that way the mac changes won't affect the trunk of raydium. And in a future, both trunks will be merged.

Sadly the commit from Xfennec to revision 656 makes some parts of my uploaded patch useless. But this is not a problem, since I want to clean up everything anyway. The 4 spaces option is enabled now, this was a good choice.

Along the way, I've done a first test on the PowerMac, which was successfully. I had to upgrade the Xcode version from 2.3 to 2.5, to get the OpenAL interface working. I'll also give the dep. package here, but with one modification to the package for Intel Macs. The used ODE version is now 0.10.0 instead of the newest SVN revision (http://downloads.sourceforge.net/opende/ode-0.10.0.tar.gz).

Both dep. packages include needless files and debug information for now, this explains the huge file sizes. My goal is to offer one lightweight universal binary package, which includes only the needed files to get Raydium easily up and running. With that package we can then create the before described Raydium framework.

good news your hard work I think we need mac testers for your patchs, so i'll try to get a few ones from my contacts.
Also I'll try to put the dependency package in my server soon. I'll post about this.

I'd some time to create a clean universal binary package of the dependencies, which supports all kinds of i386 and PPC architecture subtypes.
Just download this package to easily set up your Raydium build environment under Mac OS X. Each library contains an information file with the used version and build options. [1]

Additionally a universal binary test package was established using the unmodified source code of the Volcano demo from the Subversion revision 665. The disk image contains all necessary resource data files to minimize the traffic on the repositories, because I want to announce this package to some public mac dominated forums to get some feedback from other systems. Currently I'm only able to test my work on the two machines posted earlier here on this thread. The executable should be runnable on any Intel Mac and on any PowerPC Mac from G3 to G5. The Volcano application was also tested with Rosetta. [2]

Further on I've cleaned up the patch, which doesn't modify existing and doesn't contain new compile scripts any more, using the new coding style. Sadly the issues written in my initial posing here in this thread still exist, this'll be the next step to deal with. [3]
Instead you've the ability to use a first version of a Xcode project, which was created with Xcode version 3.0, but should be compatible downwards to Xcode version 2.4. [4]
Alternatively you can use a shell script called iCompile that works equivalent to the existing Raydium compile scripts, e. g. "./iCompile sourcefile.c --option". [5]

Both items could take a long time to get them working for me. I never used a joystick under Mac OS X, I currently don't own a joystick, but this isn't a real problem, so I'll have to borrow or buy a Mac compatible one. Otherwise this could be a simple job, perhaps we can use some lines from Steve J. Baker's PLib again. Secondly I never used some kind of Live API (video to texture, drawing to texture, ...), so I don't have any experience in this area. My iMac has an integrated webcam, so I'll try to get both things working here.

I've to say again that any help is very appreciated to get a full featured Raydium on the Mac.

We need to find a way to merge your changes to Raydium trunk, so we can provide an official SDK for MacOSX users, even if a few features are missing (that was the case for a few years with the win32 version, for instance).

After a quick look to your patch, it's probably not a big deal by itself, but the hard part will be about maintenance: st, do you think you can maintain Raydium for the MacOSX target ? It means that you must check time to time that recent commits does not break Raydium on your target, and fix/commit it if it's not the case. I think the best way to be a "Raydium target maintainer" is to be a Raydium user on this target (as ouille is for win32).

If yes, we can give you a svn access, start to merge your patch, and release the SDK. Let me know !

Sorry for the long response time, I was busy playing ManiaDrive, currently the track before last called "Canyon 1" is something like a nightmare for me.

Hopefully I'll get it with my new joystick-, gamepad- and probably wheel-mix called SideWinder Freestyle Pro, which can be used both in analogue and digital mode pressing a sensor button switch. Regrettably, this controller hasn't any force feedback support, but I'll try to implement this also, but I cannot test this feature myself at the moment.

Xfennec wrote:

Do you think you can maintain Raydium for the Mac OS X target?

Xfennec wrote:

I think the best way to be a "Raydium target maintainer" is to be a Raydium user on this target.

I fully agree with this train of thoughts. I'm currently planning to create a game, which will use and match with nearly all Raydium features, including all supported platforms. I'm able to check and commit changes from time to time, so yes I think I'll be able to maintain this target, at least I should try it. Regarding to my initial posting on this thread were I've asked for a Subversion account, it'd be comfortable to commit and merge the changes to the trunk.

It is a huge privilege for me to join the Raydium team, thank you very much for the confidence!

I hope my first commit to revision 708 equates your conceivabilities. I'll now focus on the upcoming SDK/Framework. After that, the pending joystick and live support still exist and I want to release a universal binary based ManiaDrive disk image including the files from the data package.

Nothing to comment about the commit, it's not intrusive for the current code, and seems alright for the OSX specific code. Thanks !

About the SDK, try to follow our main guideline : make it simple ! A newbie user must be able to compile all demos simply, create a new project, ... You can have a look to the new win32 SDK, it's quiet good on this point, IMHO.

Who is online

Users browsing this forum: No registered users and 6 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum