mac os x port

[abs1nth]

hello alli wanted to compile a macosx binary of vdrivft, expecting that it would be more or less straightforward, since it only depends on libraries that are available on macosx too (opengl, sdl, openal, etc.).first i had big troubles using ./configure, it did not find opengl or openal, even with some tweaking...finally gave up on the autotools route and i produced an xcode (the free mac-IDE) project. to get it to compile not many changes were needed, mainly replacing outdated (not defined) opengl *_EXT_* defines with their *_ARB_* counterparts. getting the executable to do something was a bit trickier, since vdrift has some c++ initializers call opengl functions, which lead to crashes, had to move those call to places that are called later...(when opengl is initialized). after these steps i finally had an executable that would allow me to start some race, just to soon after crash in some audio related code.... what lead me to abandon my effort (for now) was looking at some errors spit out in some file-loading code (.joe files or something like that) .... and realizing that the whole file would only work on little-endian machines, and i would have to add quite some bit of byte-swapping to make it work on big-endian...i guess it's also endian issues that led to the audio crash.so if you ever want a mac (ppc), linuxppc, or sparc port you should look into making your code endian independent...if these issues are taken care of it will be easy for me to produce a macosx binary, in case there is any interest.if none of you has any big-endian machines, you could use qemu with linuxppc to do some testing without spending money...

[thelusiv]

It would be really cool if this game worked for OS X too. Thanks for investigating!The VDrift SCons branch is almost done, that might do a better job of building without needing autotools. I suspect that much of the SCons configuration I've done can be copied for an OS X setup. If Xcode works, though, I guess we could use that too.On the issue of endianness, I'm not sure what all that would entail, but it would be good for us to get something like that out of the way sooner rather than later...

[joevenzon]

I'm totally unfamiliar with writing endian-independent code (just aware of the issue). Could you point to any resources or provide any advice? I'd like to have an OS X port available.By the way, I doubt that the audio code is crashing (openal should be able to deal with little-endian wav files, right?) -- VDrift just often crashes with openal "inrange" errors when it segfaults.Also, I'll try my best to get around to replacing the EXT opengl defines and removing any opengl calls from C++ initializers -- that's just sloppy on my part.

[thelusiv]

It would really be nice to do an OS X port, so here's what I think we should do:I can set up a branch in SVN called vdrift-osx. It will be a copy of the current main trunk. I can then give someone access to just that branch, and they can work on all aspects of the code that need to be adapted for OS X. Once they're done, Joe can check over their code and we'll try to merge the changes back into the main branch.Since neither Joe nor I have a PPC machine or plan to buy one, it would be much easier to do this way...while we could use qemu or something like that, I still think it would be faster if done by someone who a) already knows his way around OS X and b) has some experience with coding for PPC. abs1nth, are you interested?

[abs1nth]

I'm totally unfamiliar with writing endian-independent code (just aware of the issue). Could you point to any resources or provide any advice?

well the basic issue is that the ordering of bytes is not the same. so everytime you read or write (to a file or to the network) something thats bigger than one byte (short, int, long, float, structs..) you have to take care of that (also when doing bitshifting). practically that would mean inserting macros that do nothing on little-endian, but swap the byte ordering on big-endian. there is on article on the topic here, altough the proposed solution seems a bit overengineered:http://www.gamedev.net/reference/articles/article2091.asp

Also, I'll try my best to get around to replacing the EXT opengl defines and removing any opengl calls from C++ initializers -- that's just sloppy on my part.

great!

I still think it would be faster if done by someone who a) already knows his way around OS X and b) has some experience with coding for PPC.abs1nth, are you interested?

sorry i don't have the time do that, but once the endian issues are sorted out, i will take care of the remaining issues that are needed to get vdrift running on osx, and produce binaries. and just for ironing out the endian issues you really need neither OSX nor PPC expirience (or any of that available) :wink:

[joevenzon]

Alright, I'll add this to the (ever growing) TODO. I think it's fairly high-priority, though. Really, the only impacts should be to the model loading and replay loading/writing. I probably won't put too much effort into the replay system, since leaving that alone will (I think) just mean that you can only load replays that were written by a platform with the same endian-ness as yours. As for the model loading, that shouldn't be too tough -- just need to swap endian-ness of all of the loaded data before it writes it into its geometry variables.

[abs1nth]

great! please post here when you've got something to test :wink:

[joevenzon]

So, when you did your port before, did you get (at least some) "Invalid file format (Version is %d not %d): %s" messages on stderr, indicating the model version is incorrect? Because looking at the code, I think that's what should happen when a non-little-endian computer tries to load the data.

[abs1nth]

So, when you did your port before, did you get (at least some) "Invalid file format (Version is %d not %d): %s" messages on stderr, indicating the model version is incorrect? Because looking at the code, I think that's what should happen when a non-little-endian computer tries to load the data.

yeah i did, lots of them :wink:thats also what led me to look at the code in question and concluding that it can't possibly work ;->the track loaded nevertheless...

[thelusiv]

Joe checked in some endian-independent model loading code last night. I'm working on getting qemu working with a Linux PPC install so I can test...

[joevenzon]

i also removed all of the opengl calls from inside constructors (i believe)i'll make the other change (using the ARB approved extension constants) today or something, and then hopefully the next release will be ready to port.

[joevenzon]

ok, now we're only using the ARB approved extensions in SVN. next release should be go for OSX port.

[abs1nth]

>then hopefully the next release will be ready to porti figured it would be better to try it out now so we can be sure that the next release has no port-showstoppers.so i downloaded svn trunk and started porting again *g*the problem is that model.cpp still doesn't work right on big-endian, maybe you forgot some swaps? (it hangs forever in TREES::BuildCompositeShadow())but when i turn off model-loading and specify nosound it works quite nicely and i was even able drive/drift around a bit :winko please apply the patch from:****(fixes various issues)and please add the contents of:****to vdrift's "tools" directory (it contains Xcode project files)you can also view a screenshot here:****EDIT: files removed now

[thelusiv]

Very nice! For some strange reason your patch partially fails for me though, I'll have to play with it later tonight and apply it by hand I guess...

[abs1nth]

>your patch partially fails for me thoughcould be because i edited by hand to remove some stuff...should be easy to apply by hand since it's only a few lines...if you have any questions about why i did something please ask...i know not everything is pretty...btw:• it is currently not possible to compile vdrift without either OpenAL or fmod• why is a data_dir path in the default config file? this way whatever is specified at compile time is overridden anyway