Author Topic: Force Feedback spring fix (PR #1420) test  (Read 669 times)

0 Members and 1 Guest are viewing this topic.

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Force Feedback spring fix (PR #1420) test
This is some test builds compiled from PR #1420, an attempt to fix a problem with some force-feedback joysticks where the centering spring effect goes away after the first mission played in a session.

64-bit: http://deviance.duckish.net/downloads/fs2_fred2_open_fftest_x64_SSE2.7z
32-bit: http://deviance.duckish.net/downloads/fs2_fred2_open_fftest_x86_SSE2.7z

If you experienced that problem, try these out and let us know whether or not it worked for you. If you have a force-feedback joystick and don't experience that problem, you can try these builds out and tell us if they break anything for you.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline deathspeed

  • 28
  • i can't think of a good avatar
    • Steam
Re: Force Feedback spring fix (PR #1420) test
Thanks!  Unfortunately this did not fix the problem on my Sidewinder FF2.  I have the centering effect on the first mission, but not on the 2nd.  I have the same issue with 3.8(RC3) and the 7/14/17 nightly build, but using 3.4 the force feedback works fine throughout multiple missions.  I'm using Windows 32 bit versions of all builds. 

I forgot how to embed pics and i have to run right now, but here is a link showing the builds I tried:
http://imgur.com/a/yI8JL
Maybe someday God will give you a little pink toaster of your own.

 
Re: Force Feedback spring fix (PR #1420) test
I can verify that unfortunately this test build didn't fix the problem.  I ran "Massive Battle 2" mission twice in a row and on the second run the auto-center had disappeared.

Other FF effects ran identically regardless of how many times mission was restarted:

- Afterburner FF = worked
- Directional hit FF = worked
- Collision FF = worked
- Primary weapon FF = worked
- Secondary weapon FF = worked
- Nearby capital ship explosion FF = doesn't work

I attached a log file of me playing Massive Battle 2 two times.

PS: Interestingly there were a couple warnings of 3d sound files having more than one channel, which is prohibited. However, these warnings hardly have anything to do with Force Feedback effects.

 

Offline m!m

  • 210
Re: Force Feedback spring fix (PR #1420) test
I changed the code and now it should resemble the original code more closely. Here are test builds for all platforms: http://swc.fs2downloads.com/builds/test/forceFeedbackFix/
(This is also the first time the automated test build system has been used).

I'll take a look at the cap ship explosions once the first bug has been fixed.

Also, please add a new log file once you tested the new builds. I added some additional logging that might be interesting.

 
Re: Force Feedback spring fix (PR #1420) test
Yay!  :D The Auto-center / Spring works now after restarting missions!

Thank you m!m very much for your work! FSO is again a much smoother experience :)

I only had time to briefly test a couple of missions and restarts before going to vacation so no log file this time, I'm sorry. I can provide one once I return on monday, if needed.

-----------
-----------

Regarding the other FF effects, I actually found one additional example of FF dying = Missile hits to player ships. Notice that primary weapon hits still cause FF normally.

So this brings me to my current theory:

As it stands in FSO, Force Feedback for SDL2 joystick input is much stronger (more "violent" reaction on joystick) than Direct Input FF. Additionally there were three levels of FF strength with Direct input (default on "low" I guess?) while SDL2 only has one constant level. I presume that SDL2 FF level is even higher than the "high" setting of direct input.

This whole problem with Capship explosions and missile hits might be related to the fact that these two effects are probably the two strongest FF effects in Freespace 2. This means that while amplified too much by SDL 2 FF levels, the signal to joystick becomes too strong to handle. The joystick then kills the effect, because it cannot take it. It goes beyond the capabilities of my old joystick.

So my proposal is the following:

Add a launch parameter with additional Force Feedback levels. Maybe set the default force with SDL 2 lower than it is now.

Just my two cents  :D

 

Offline m!m

  • 210
Re: Force Feedback spring fix (PR #1420) test
Thank you for testing the builds. At least the most annoying issue has been fixed now. I'll take a look at how the effect strength is determined in the SDL code.

 

Offline deathspeed

  • 28
  • i can't think of a good avatar
    • Steam
Re: Force Feedback spring fix (PR #1420) test
I hope to check this out later as well, but I agree that the FF effects feel much stronger than with 3.4 and earlier builds.  The afterburner effect is strong enough to actually be unpleasant, and it annoys my wife even when she is in another room.  That alone is a dealbreaker that forces me to use 3.4 when she is home.  :)

EDIT:  This fix worked for me as well; thank you!  I added a link to this thread to the Joystick sticky.

I'm attaching my FS2_open log in case it helps.  (I forgot to run in windowed mode; I can re-do it if needed).
« Last Edit: July 30, 2017, 11:36:42 pm by deathspeed »
Maybe someday God will give you a little pink toaster of your own.

 

Offline m!m

  • 210
Re: Force Feedback spring fix (PR #1420) test
I looked through the FSO force feedback code and I also checked the SDL2 DirectInput code and, as far as I can tell, the SDL2 version should produce pretty much the same values as the previous DirectInput code so I have no idea why the strength of the effects have changed.

I guess I could add a configuration parameter for reducing the effect strengths and with some testing we might be able to find a good default value. I'll post new test builds here once I get the chance to write the code for this.

 

Offline taylor

  • Super SCP/Linux Guru
  • Moderator
  • 212
    • http://www.icculus.org/~taylor
Re: Force Feedback spring fix (PR #1420) test
There is an environment variable which may work. You can set SDL_HAPTIC_GAIN_MAX to a value in the range of 0 to 100 and it will adjust the overall strength of effects. It works like a percentage, so it's 0% to 100%. Set it to something like SDL_HAPTIC_GAIN_MAX=10 and it should have a strength 10% of normal. Assuming that makes a difference you can adjust the value to your liking and it will work for all SDL apps.


Progammatically, the overall gain can be set with SDL_HapticSetGain() with the same 0-100 scale. I suppose a cmdline option can be added it that method is preferred, but it would obviously only work for FSO. Gain isn't supported by all implementations though, or by all joysticks, and the proper value will be dependent on the joystick. Support must be tested by querying for SDL_HAPTIC_GAIN before trying to set gain or it's an error.

 

Offline taylor

  • Super SCP/Linux Guru
  • Moderator
  • 212
    • http://www.icculus.org/~taylor
Re: Force Feedback spring fix (PR #1420) test
Just noticed that the afterburn effect does actually have greater strength than it should. The values match what was in retail, but the effect is played back with 50% gain in retail, making the effect about twice as strong in the SDL code.

The magnitude for pAfterburn1 should be 0x3332, and for pAfterburn2 it should be 0x1999. Those values need to be corrected in both the create function and in the afterburn_on() function.


If that's still too strong then the SDL_HAPTIC_GAIN_MAX environment variable should be able to solve it.

 

Offline m!m

  • 210
Re: Force Feedback spring fix (PR #1420) test
Thank you for noticing that. I updated the FF code and submitted it as a pull request: https://github.com/scp-fs2open/fs2open.github.com/pull/1429
I also created a test build branch. The final builds should appear here soon: http://swc.fs2downloads.com/builds/test/ffEffectStrength/

 

Offline taylor

  • Super SCP/Linux Guru
  • Moderator
  • 212
    • http://www.icculus.org/~taylor
Re: Force Feedback spring fix (PR #1420) test
Found another one that's wrong. The magnitude for pDock in joy_ff_docked() should be 0x3332, and in joy_ff_play_reload_effect() it should be 0x1999. Same issue with the afterburn effects, where the magnitude was set to the gain value from the retail code instead of the correct magnitude value. So both uses of pDock were playing at more than 2x the strength that they did in retail.

I went through all of the other effects and the rest appear fine to me. But you may want to double check just in case I missed any.

 
Re: Force Feedback spring fix (PR #1420) test
The afterburner seems indeed to be fixed, but my other problems remain (lack of FF in missile hits and Capship explosions). I guess I'll have to find myself another joystick in the long run.

I know it's not probably high on priority list, but would it be possible to make it easier for players to control FF intensities? Like for example a start parameter called "-FF_strength 1.0" for default value (and 0.5 for half value etc...).

  

Offline m!m

  • 210
Re: Force Feedback spring fix (PR #1420) test
I added a config file option for specifying the global effect strength. This will only work if the joystick supports that operation, if it doesn't then FSO will show a warning at startup.
Test builds are here (might take a while until all builds are compiled): http://swc.fs2downloads.com/builds/test/ffGlobalGain/

Configuration works as follows:
Go to %appdata%\HardLightProductions\FreeSpaceOpen and open fs2_open.ini. Then append to following to the file:
Code: [Select]
[ForceFeedback]
Strength=100

You can adjust the value of Strength which is a percentage of how strong the effects should be so a value of 50 would make the effects half as strong.

 
Re: Force Feedback spring fix (PR #1420) test
Hi,

sorry it took me such a long time to respond. I tried the newest build and I can confirm that the global FF strength modification does work at the moment.  :)

I just have one suggestion: Exclude the basic auto-center spring force from this global coefficient. I have a feeling that while joystick players enjoy various intensities of FF effects, most player would want the basic "grip" to be firm. Having a decent auto-center force at any time helps immensely in precision.

-------

On a related note, while this "global coefficient" build is useful, it actually debunks my previous theory about the problem with Capship explosion and missile hit. While I managed to feel a very faint FF effect from Capship explosions, the missile hit FF effects are still nonexistent.

At this point, unless any other players confirm these similar FF problems, I am leaning to the possibility that maybe Microsoft Sidewinder 2 just isn't fully compatible with SDL2 haptic libraries.

--------

Anyway, huge thanks to you m!m for taking your time for us joystick players!  :yes: :yes: :pimp:

 

Offline m!m

  • 210
Re: Force Feedback spring fix (PR #1420) test
Excluding the spring effect from the global scaling is possible since it's, well, a global scaling value. I checked the code for the capship explosions but I could not find anything wrong with it. The FF strength scaling will not make it into the final 3.8 build since it's not really a bugfix.

 

Offline deathspeed

  • 28
  • i can't think of a good avatar
    • Steam
Re: Force Feedback spring fix (PR #1420) test
Thank you all!  I have tried this build, and confirm that the effect strength scaling works for me with my MS Sidewinder FF2.  75% is about the right spot for me to have sufficient centering strength and definite yet not overwhelming effects.

I can also confirm the I too do not feel any effects from missile hits or capship explosions (unless i collide with debris), although the latter do cause my screen to shake.  Honestly though I can live without those effects; I did not even notice their absence until Lykurgos88 mentioned it and I specifically sought them.

Maybe someday God will give you a little pink toaster of your own.