flycast icon indicating copy to clipboard operation
flycast copied to clipboard

San Francisco Rush 2049 has some "Deadzone" hardcoded.

Open exaconn opened this issue 1 year ago • 9 comments

Hello Devs. I'am playing a lot on Flaycast and it's a great emulator, but in some Dreamcast racing games the deadzone is hardcoded and therefore you can't play them nicely on a steering wheel mapped to the pad. There are at least two ways to solve this:

  • sensitivity setting for the left stick
  • setting for the inverted linear sensitivity of the left stick

Please, if possible, look into the problem, it's especially visible in "San Francisco Rush 2049" where when you map the steering wheel to the left stick the wheel gets a deadzoned by about 10 degrees or even more. Best regards and take care Devs.

exaconn avatar Dec 26 '24 05:12 exaconn

Flycast doesn't have a hard-coded dead zone. It defaults to 10% but this can be changed in Settings > Controls > (your controller>) > Settings. You can also change the saturation to make it more or less sensitive.

flyinghead avatar Dec 26 '24 10:12 flyinghead

By hardcoded deadzone I mean a specific value in the game code. For example, when someone maps a Logitech steering wheel to the left stick with Flaycast deadzone set to 0 and saturation set to 100, the real deadzone on the wheel is about 10 degrees. So I think it is hardcoded in the game code. What I think for workaround is another option that adds some values ​​to the sdl input so that when you turn the wheel 2 degrees it sends to the emulated controller that it is already turned 5 degrees for example. What do you think about this and do you understand me? Thanks for your time!

Ps. Later today i will check the saturation option and let you know if this resolve the issue in San Francisco Rush 2049.

exaconn avatar Dec 26 '24 11:12 exaconn

You can switch to "racing wheel" mode in the control options: image

flyinghead avatar Dec 26 '24 12:12 flyinghead

So I checked the Saturation option and yes on value 200 it is acceptable now, a deadzone about 3 degres each side. I will check the wheel configuration that You recomend and let You know later. Many thanks for all Your hard work.

exaconn avatar Dec 26 '24 12:12 exaconn

You can switch to "racing wheel" mode in the control options: image

Yes this works extremly well. Thank You very very much ;)

exaconn avatar Dec 26 '24 13:12 exaconn

Hello Devs. So I mapped Logiteh 180 degres ffb wheel to Flycast as Dreamcast wheel with attached vibration pack and autocentering in wheel drivers enabled. In this setup i started to test some racing games.

  • Daytona USA 2001, brilliant it is almost as good as arcade one.
  • San Francisco Rush, excellent when one turn this steering option.

Thats ok and play nice but in Demolition Racer: No Exit (USA) game things goes messy, it is like you move left a wheel 10 degres and nothing happen and then in next 30 degres or so the car wheels in the game goes all the way left, so it is tottaly umplayable in this form. Please tell me how one can change this behaviour ? I can even compile some build specifically for this game but where to look in code for what function specifically ? Thanks in advance Devs.

exaconn avatar Dec 29 '24 13:12 exaconn

Again this is very likely the game using an internal dead zone. But I don't know if this can be changed in the game options. Keep in mind that virtually nobody had the Sega racing wheel and everybody was using regular controllers. So most console games are designed to be used with a gamepad. Most of the code for controllers is in core/input/gamepad_device.cpp. See gamepad_axis_input()

flyinghead avatar Dec 29 '24 17:12 flyinghead

The best way to solve this problem would be to add an "advanced axis configuration" tab to the "psychical device, settings" with a reset button to "default settings". In this tab, One need to enter two values:

  • half_axis_start
  • half_axis_end

Now the system counts the step:

new_range = half_axis_end - half_axis_start real_device_corrected_step = real_device_half_axis_range / new_range

final_emulated_half_axis_value = (real_device_current_value / real_device_corrected_step) + half_axis_start

It is my fast implementation with no test the result but this is a basic idea to finally overcome any axis range problems real range / new range equals a new step ..

Please consider this so the Emu would be unbeatable. Thanks for your time Sir.

exaconn avatar Dec 30 '24 06:12 exaconn

Above imp .. corrected not tested.

exaconn avatar Dec 30 '24 08:12 exaconn