[chief1983]

On top of that, a lot of Linux platforms don't even have 1.3 in their package managers yet.  It'd be an install from source situation in those cases and likely cause people a lot of headache, just to try to get FF working.

[taylor]

SDL 1.3 is a highly unstable API which isn't remotely ready for any type of release, so it shouldn't be in distros at all in the first place.  There isn't any point in worrying about it at this time, or even this year for that matter.

The haptic support in 1.3 is pretty stable and can be backported to 1.2 though, so if we want FF with the least amount of fuss then that's how we should do it.  It will be the same or less amount of work than getting iAuxINP in there, and users would have to install a lib by hand either way so that isn't an hit on either option (although in the SDL case they would have source as well).  The 1.2 backport means that the code will automatically be ready for 1.3 when the time eventually comes though and that means far less long term work than messing with iAuxINP.

[chief1983]

Just curious, do you mean essentially doing this for an internal SDL lib, or going through SDL and providing them with the fruits of our labor?

[taylor]

Just an internal lib.  SDL 1.2 is frozen and I don't think there will be any more releases from it unless there is a major bug or something.  I seem to remember the conversation of putting haptic support in 1.2 as well but they didn't want to add to the API at this point.

I do believe that the work has mostly been done already though, since I'm pretty sure that Palm (or someone just working on the port) did all of the work for the WebOS version of SDL.  I remember seeing a diff for it against official 1.2, or something to that effect, which contained the haptic code.  SDL is LGPL of course, so the changes have to be released.

And it should be possible to set it up in the FSO code so that it will dynamically load the functions out of the SDL lib, so the special SDL lib wouldn't be required for existing functionality.  People that want FF could then just drop a single lib in the game directory and things should just work.


I think I might try and look into this over the weekend and see if I can find out exactly what it would take to do.

[taylor]

So as it turns out the haptic code was originally developed based on SDL 1.2.11 for GSoC.  I have now gotten current SDL 1.2 patched with this code, it compiles, and the haptic test binary works too!  I still need to track down any possible bug fixes that were made later, after it was merged into SDL 1.3, but that shouldn't be much of an issue.  After that it's just a matter of writing the FSO code. 

I'll see if I can find some time to whip up the necessary code for FSO later this week.  I'm not going to be able to produce any builds, but I can provide the necessary diffs for others to make some builds (both SDL and FSO).  Stay tuned...

[taylor]

FSO code support pretty much done now.  The effects need to be tweaked a bit (damn near broke my hand when firing a missile for the first time, wasn't quite ready for that ) and it still needs to be made to not require the modified lib, but it is working in-game on Linux at least.  Should work even better under OS X too, since it has better OS level haptic support than Linux does.

This stuff really came together a lot faster and easier than I could have guessed.  Total time on both things (SDL and FSO) was probably about 6 hours.  I'll try and find an hour or two to finish up the code tomorrow and test it better, and then get the diffs out by the weekend.

[chief1983]

* chief1983 is happy.

And I don't even have a working FF joystick around!

[iadesdragon]

but i have ;-) keep it rolling in i'll be testing :-)

[chief1983]

This does mean we'll have to build against a custom SDL on Linux then I suppose?

[taylor]

Nope, it will be totally optional.  I'm going to include the necessary header info in there, so nothing new external will be required.  It should build just fine against normal SDL libs/headers.  When loading it will try to dynamically load the function ptrs out of the SDL lib, and if they are found then it will allow for use of haptic.  If the ptrs aren't found then FF will just be disabled and it will function like it always has.

[taylor]

Dynamic usage code implemented and tested.  This is only tested under Linux so far, but the code should work the same on OS X builds.  It builds fine against default system SDL 1.2, runs fine with haptic disabled using default lib, and runs fine with haptic enabled using modified lib. 


Also, here is the haptic patch for SDL 1.2.  I'm posting it now to give a couple days head start on getting a new framework built before the game patch is released this weekend.  Hopefully somebody will be able to take care of getting it built and ready for use.  Do note that the Xcode project hasn't been updated in the patch, so please send me those changes so that I can include them in an updated patch later on.

New files to add to project:
include/SDL_haptic.h
src/haptic/*
src/joystick/darwin/SDL_sysjoystick_c.h
src/joystick/linux/SDL_sysjoystick_c.h
src/joystick/win32/SDL_dxjoystick_c.h
test/testhaptic.c

And be sure to add the ForceFeedback framework to the project as well.

[taylor]

And although it probably still needs a bit of work and testing, I'm going to go ahead and post the FSO patch as well in case I end up too busy this weekend to do it.

http://icculus.org/~taylor/fso/misc/fso_haptic.diff.gz

Remove from project file(s):
src/io/joy-unix.cpp

Add to project file(s):
src/io/joy-sdl.cpp
src/io/joy_ff-sdl.cpp
src/io/SDL_haptic.h

And with any luck, applied to trunk and built with nothing special, it should work just fine.  That should probably be the first test too.  If that works out then testing with the modified SDL framework would come next to see how well haptic actually works in-game for everyone other than me.

Do be warned that some of the effects might be a little strong though, so be prepared.  This is something that I'm definitely going to need feedback on from everyone to make sure all of the effects are set up properly.  We'll also probably have to work out some additional support for game pads (rumble) in the future.  Right now it will most likely only work with regular force joysticks.


Enjoy.  

[iadesdragon]

i would really love testing but, sorrily i'm not set up for compiling the stuff myself...

is there a stupid guys guide to compiling FSO on Mac?

[Echelon9]

i would really love testing but, sorrily i'm not set up for compiling the stuff myself...

is there a stupid guys guide to compiling FSO on Mac?

Ask, and you shall be rewarded. Here's a guide I've just written up, please let me know if it's clear enough or if any sections should be further detailed.

[chief1983]

3.1.x on 10.5.x was working last I used it, can't check any more though.

And, even longer ago when I first started making Mac builds, it was on a Blue and White G3 running 10.4 and 2.5.x, and it worked then too.  But I believe there's been recent reports that we broke that since then.

[Echelon9]

Yes, I remember 3.1.x on 10.5.x was working for me too, a fair few revisions ago now.

I'd like to keep it as 'Unknown' until we get a recent confirmation. Having said this, Xcode has improved so much over the last 2 years that developers should be using the most recent version available for their platform to get the most out of it.

[SiriusGrey]

Linux user here - it works (patched 3.6.12)!

Thanks taylor - this is the proper way to implement it

A quick note to Linux users: the device /dev/input/eventX must be _writable_ by the user you run fs2 as. There should probably be an automatic UDEV rule for this; but there is none currently in my distribution (Debian sid).

For me the effects were quite weak (Saitek Cyborg EVO Force) - I myself implemented a rather hackish linux-specific version of FF here: http://www.hard-light.net/forums/index.php?topic=67253.0 and the effects were stronger there. Maybe the strength multiplier could be turned into a configuration option?

I'll be available for testing this further.

Cheers,
Sirius

My Procedure:

* download SDL-1.2.14 source; patch with taylors patch;
* sh autogen.sh; ./configure --prefix=/home/me/software/sdl-1.2; make -j3; make install
* checkout fs2_open_3_6_12 from svn; patch with taylors patch;
* sh autogen.sh --with-sdl-prefix=/home/me/software/sdl-1.2 --enable-inferno; make -j3
* LD_LIBRARY_PATH=/home/me/software/sdl-1.2 dev/fs2_open_3_6_12/code/fs2_open_INF_r -mod fs2,mediavps_3612

[taylor]

Good to hear that it works for someone else.

The effects were rather strong for me so I was worried about it.  Not sure how we should handle it if there is a lot of variation among different joysticks.  I don't know if a strength multiplier is the best option overall, but I can't claim to know of any better options either.


Oh, and you really don't need to build FSO against the patched SDL either.  Just using your default system one should work fine.  There is only one additional header for SDL and it is included with the FSO patch so that nothing external would be required to build.

[chief1983]

So to use this on Mac/Linux, we need to:

Patch FSO in SVN
Update the Mac's Frameworks.tgz with a new SDL framework built with the patch
Have users compile their own SDL on Linux or include a custom lib for linux users

Is that about right?  I'm not really sure what to do to make it easy on the linux users, but it seems like we should be able to pull this off for Mac users with the way things are currently set up.  We need to update the Ogg framework still anyway, which we had a user looking at.

[taylor]

Yeah, that's pretty much it.

For Linux users we can have a pre-compiled .so available, and they can have script actually set LD_LIBARARY_PATH properly to use the custom version in the game directory instead of the system version.  Still a bit more complicated than the OS X version of course, but not terribly difficult.