mac os x port

[thelusiv]

could 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...

Could you remove that stuff from your source and make a new patch? That will greatly reduce the chances that Joe or I will miss something when applying the patch.

• it is currently not possible to compile vdrift without either OpenAL or fmod

Yes, what do you mean - you'd like to compile without sound at all? I know there are Apple sound libraries, theoretically we could make a compile time switch to use this instead.

• why is a data_dir path in the default config file? this way whatever is specified at compile time is overridden anyway

This is so we can distribute binaries that can change the data_dir after compilation. Some people's distributions won't want to put the data in /usr/share/games/ or whatever. So they can run vdrift -defaultdatadir /new/data/path and fix it. This system isn't perfect I know...I've been trying to think of a better way to do this...

[abs1nth]

>Could you remove that stuff from your source and make a new patch?ok i've taken the patch and project files offline, will rework/improve them and they will be up again in a few minutes>Yes, what do you mean - you'd like to compile without sound at all? yeah i just thought that was a bug that that didn't work...also since sound currently crashes it's a PITA to always specify -nosound to test things>I know there are Apple sound libraries, theoretically we could make a compile time switch to use this instead.10.4 even includes OpenAL, and fmod also works on mac, but once sound works it will be better to statically link or include the OpenAL framework, for better compatibility with older systems

[abs1nth]

so new (better :wink: versions of both the patch and the project files are up at the old locations. the diff should apply cleanly.>Yes, what do you mean - you'd like to compile without sound at all? actually i specified neither HAVE_OPENAL nor HAVE_FMOD and assumed this would try to build without sound and fail. BUT it automatically defaults to fmod when HAVE_OPENAL is not defined, so the errors i saw are related to broken fmod building and not to broken building without sound. is fmod known to be broken? i wanted to try it out to see if it works better (=>not crash) than openal.

[joevenzon]

It's very difficult for me to debug byte swapping in the model loading functions (ReadData is where most of it occurs) -- could you perhaps step through it and find out where the problem is (i.e., an int or float that doesn't look correct)? Or at the very least, could you find out where exactly it's hanging (BuildCompositeShadow doesn't sound right the problem is the model loading....)?

[joevenzon]

Hey wait, are floats and ints 32-bits on your platform? What about short ints?

[abs1nth]

>Hey wait, are floats and ints 32-bits on your platform? What about short ints?have a look here for ppc data sizes:http://developer.apple.com/documentation/DeveloperTools/Conceptual/PowerPCRuntime/Data/chapter_2_section_2.html>[...] could you perhaps step through it and find out where the problem is [...]yeah i can have a look :wink:

[joevenzon]

Make sure you're using OpenAL version 1.0. Also, the FMOD used is version 3.74.

[abs1nth]

victory! i have it running now with models ;o)the problem was that you can't swap floats the same way you swap ints...fixed that and it's running now...i will put a patch up soon...btw is there anything wrong with my previous patch because it wasnt applied yet? should i merge the new fixes in my old patch?>Also, the FMOD used is version 3.74.as i said fmod compilation doesn't work at all...does it work on linux?

[abs1nth]

i will put a patch up soon...

so the patch is updated, same location.remaining problems:• it crashes sometimes, seems like an memory bug• keyboard controls don't really work in-game • the sound problems i described• it's really VERY slow. i get about 15 fps @ 1024x768 and thats with high-end hardware. so 95% of all mac-owners shouldn't even think about trying out vdrift in it's current state.

[joevenzon]

The game uses large font textures... you could try scaling those and some of the HUD graphics down. Also, try disabling all trees and foliage and setting the terrain detail really low. What graphics card do you have?

[thelusiv]

OK I just checked a few things into SVN:<li>Merged Julian's latest OS X patch<li>Added the OS X tools to tools/osx/<li>Changed the default display settings to 800x600x16 windowed, Low Detail Trees &amp; Terrainabs1nth: the one part of your patch which I did not include is the part that ignores the data directory in VDrift.config. The build for OS X should run<pre>vdrift -defaultdatadir ./data</pre>when VDrift is compiled so it sets the correct path in the default config file.

[abs1nth]

What graphics card do you have?

ATI X800 XT it may of course be that the low performace is due to some remaining issues with the port....i had a quick look with an profiler but couldn't find anything obvious.

OK I just checked a few things into SVN:Merged Julian's latest OS X patchAdded the OS X tools to tools/osx/

great!

abs1nth: the one part of your patch which I did not include is the part that ignores the data directory in VDrift.config. The build for OS X should runvdrift -defaultdatadir ./datawhen VDrift is compiled so it sets the correct path in the default config file.

but this only changes the value in my local config file, and not in the config file that is delivered/packaged...?

[thelusiv]

ATI X800 XT it may of course be that the low performace is due to some remaining issues with the port....i had a quick look with an profiler but couldn't find anything obvious.

If you check out the code in SVN HEAD, there are now some different texture settings. Try playing with medium size textures, and see if this is much better.

but this only changes the value in my local config file, and not in the config file that is delivered/packaged...?

Well, defaultdatadir changes it wherever you tell it to change it - so giving it a path of ./data will change the config file ./data/settings/VDrift.config to have data_dir = ./data instead of /usr/share/games/vdrift/. Now, if you made a package after compiling with -DDATA_DIR=./data and then running vdrift -defaultdatadir ./data, it will have the ./data is the data path in both the compiled executable and in the default config file. Now, if someone installs it after all this, VDrift will see that they have no ~/.vdrift/ and create it, then copy the file ./data/settings/VDrift.config (and other stuff) to ~/.vdrift/. So, whenever they run it their path will be correct (as long as they run it out of the directory where ./data is...)Running vdrift -defaultdatadir is the same in this case as manually editing data/settings/VDrift.config and changing the line data_dir = ... to data_dir = ./data.Does that make any sense? :wink:

[abs1nth]

hello againsince you've fixed the car-loading problem i've spent the afternoon building a binary release of vdrift for macosx.a few notes:• when compiling an optimized build of vdrift the framerates suddenly went from 10-18 to 85-100 so this problem seems to be resolved :wink:i'm currently uploading the binary so you can put it up at sourceforge and when my svn account works i can commit my changes...

[abs1nth]

i'm currently uploading the binary

get it here while it's hot:****EDIT: already released