7-10 release breaks compilation

[ninjagumby]

I'm on an AMD64 FC4 system, and successfully compiled the 6-25 release, but the addition of FMOD in 7-10 breaks on my system during compilation:g++ -Wall -O1 -o vdrift main.o utility.o font.o backdrop.o quat.o camera.o weather.o keyman.o Car.o Aerodynamic_Device.o Brake.o Clutch.o Contact_Point.o Differential.o Engine.o Exerter.o Frame.o Fuel_Tank.o Gauge.o Gl_Car.o Particle.o Rigid_Body.o Suspension.o Tire.o Transmission.o Wheel.o Inertia_Tensor.o Linear_Interpolator.o Material.o Sample.o Spline.o Three_Matrix.o Three_Vector.o Two_Point.o XML_Parser.o Road_Segment.o Strip_Track.o World.o Drivetrain.o Gl_Texture_Image.o Texture_Image.o model.o vamosworld.o mouse.o messageq.o terrain.o sound.o menu.o timer.o controls.o replay.o particles.o -L/home/richard/firefox/VDrift/lib -lfmod-3.74 -L/usr/lib64 /usr/lib64/libSDL.so -L/usr/X11R6/lib64 -lpthread -lSDL_image /usr/lib64/libGL.so -L/usr/X11R6/lib -lm -lXext -lX11 -ldl -lGLU -Wl,--rpath -Wl,/usr/lib64 -Wl,--rpath -Wl,/usr/lib64/usr/bin/ld: skipping incompatible /home/richard/firefox/VDrift/lib/libfmod-3.74.so when searching for -lfmod-3.74/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../libfmod-3.74.so when searching for -lfmod-3.74/usr/bin/ld: skipping incompatible /usr/lib/libfmod-3.74.so when searching for -lfmod-3.74Ideas?

[joevenzon]

You're going to have to find (or build) an AMD64 version of the FMOD library and copy the .so file to VDrift/lib

[thelusiv]

I looked for one earlier and couldn't find anything, but it seems Gentoo has an ebuild for it. I did however find an AMD64 fmod binary for Win64 on their site. No mention of anything for Linux.If anyone comes up with anything, please let me know, because eventually there should be VDrift binary packages for Linux including amd64 and it would be nice to package the fmod lib with it, since many distros don't even have an fmod package at all due to its license.

[Nexus6]

Sadly, there is no current libfmod available for AMD64 even though a 64bit windows library exists In the meantime, I may investigate compiling VDrift in 32bit mode and seeing whether I have sufficient libraries to carry that off on my Ubuntu box.Cheers,Toby Haynes

[joevenzon]

It'd be easy to revert to OpenAL, I just wish it didn't sound so crappy on Linux... a ./configure option would be ideal, but I don't know how to do those.

[ninjagumby]

I have tried compiling in 32 bit mode, and had no success. I used 'setarch i386 xterm' to launch a terminal I could ./configure and make with. It did exactly the same thing as before. If I've done anything wrong here, I'm open to suggestions.Also, when it had OpenAL as the sound lib, I thought it performed perfectly. Well, at least I don't know what you mean by sounding crappy.

[joevenzon]

OpenAL wasn't doing a very good job of changing the pitches for samples. It could only double the pitch, and sounded grainy. On windows it sounds fine (maybe because it was using sound hardware), but on Linux it sounds very poor (for me, anyway).However, I'd like to include the option to compile with OpenAL for the next release. Does anyone know how to do ./configure options with automake??

[Nexus6]

I can hardly call myself an autotools expert but I do have the GNU manual There are two ways of playing this game:1) you could try to detect the fmod headers and library. If they are found, use them. If they are missing, search for the OpenAL headers and library and use them. If they are missing, fail the configure.2) default to FMOD. Provide the option --enable-openal in configure.ac which would disable FMOD and enable OpenAL. You want the AC_ARG_ENABLE macro.If you need more info, I recommend the autoconf manual from the GNU software site. It's pretty good (albeit large). The AC_ARG_ENABLE stuff is in section 12.2.Cheers (and THANKS!)Toby Haynes

[joevenzon]

No longer an issue for the latest version of the code (in the SVN repository, it'll make its debut in the next release). Thanks to Jens Granseuer, the autotools are set up much better. ./configure now defaults to openal, but you can ./configure --with-fmod to get FMOD, if you want it. He also fixed a number of other issues with the autotools, including:* throw out all Anjuta-generated autotools cruft. You really should forbid anjuta to touch the build files. It's no wonder noone understands autotools if they start out with the generated templates...* use automake --foreign instead of --gnu. That way, you can dump all those stupid unused files like AUTHORS, NEWS, etc.* add a configure check for std::ios_base which I needed to make the game compile with gcc 2.95* add a configure switch for fmod (--with-fmod). configure defaults to OpenAL otherwise. I also merged the sound.h.* and sound.cpp.* files. Both of those could still be cleaned up a little if you used a truly generic interface.* fix 'make dist'. You should really use that instead of manually tarring your releases. This also fixes the issues with install-sh and other files being symlinks. There also is a standard 'make distcheck' target. If a release passes this test, chances are you probably didn't forget anything important.* add a missing include in the Vamos sources

[Nexus6]

Thank you thank you thank you hock: Many thanks,Toby Haynes

[Nexus6]

OpenAL wasn't doing a very good job of changing the pitches for samples. It could only double the pitch, and sounded grainy. On windows it sounds fine (maybe because it was using sound hardware), but on Linux it sounds very poor (for me, anyway).

Brain wakes up...You aren't, by any chance, running OpenAL against the OSS interface are you? OpenAL defaults to OSS for compatability but it's not a good idea when running against ALSA because it messes up the sound quality...You can either have an /etc/openalrc system wide config or a personal one in ~/.openalrc. It is configured with a lisp-like language but the following should serve for most two-speaker systems.<pre>(define devices '(alsa sdl arts esd native null))(define alsa-device "dsp0")(define speaker-num 2);(define sampling-rate 22050)</pre>Cheers,Toby Haynes

[joevenzon]

It seems I'm running it with ALSA.What's odd is that OpenAL sounds great in Windows... hrm.

[Nexus6]

Having exposed this wisdom I've actually tried it out on my box... :oops:Cheers,Toby Haynes

[thelusiv]

OK, I played around with this some. If I set it to use ALSA or 'native' first then it works like OpenAL always has. If I change it to try SDL first, it sounds even worse.What I mean is this - hold the accelerator at a constant RPM and listen. You will hear a click, click, click, in the sound as it loops, as if there were a little silence at one or both ends of the sample (actually a long time ago there was, but I trimmed it out. You can test this yourself by loop playing the sound in Audacity). This is only audible in OpenAL, on Linux. If you use FMOD or Windows, the problem is gone.If I have some time I'll try to dig deeper on this issue, perhaps contact the OpenAL folks or something...and I'll definitely put the information you've found into our FAQ. Thanks.