Add flick stick support

[JustinWayland]

So I gave your source port a whirl on Linux yesterday just to see if the controller support is better than DSDA-DOOM's, and to my surprise it was. That being said, the one thing keeping me from switching to this source port and making an effort to fumble through learning controller is a complete and utter lack of flick stick support. I have faked it through Steam Input, but that involves a lot of fiddling and is way harder than just flicking a toggle in the setting. In addition, those settings could then be applied to DSDA-DOOM, which has an OpenGL renderer that drastically increases performance over the software rendering.

Usually, flick stick is implemented in tandem with gyro aiming to allow for one-to-one aiming on multiple axes, but that's less necessary here due to the fact that we are usually locked to one axis anyway, and the latter would add even more complexity on top of the complexity that's probably already needed to implement flick stick.

[ceski-1]

I think this is a neat feature, so I'll probably experiment with it. Some questions:

1. What would you consider to be a good example of a built-in implementation in a game you've played? I tried Deathloop and it works nicely there.
2. It seems like it would require a considerable number of settings to satisfy each player's personal preference. What would you consider to be the most essential? e.g. 4-way vs. 8-way, gyro sensitivity, etc.
3. Can you clarify how adding this to Woof would affect DSDA-Doom?

[JustinWayland]

Sorry I am late with this.

1. Honestly, I first experienced it using Steam Input's ability to fake it on DSDA-DOOM. It was very fiddly to set up, to the point I had to change the mouse sensitivity settings to get it working, but once it was dialed in it was great. It made maps that would be a nightmare with a regular FPS control scheme (like Ichinichi MAP02) manageable.
2. From my experiments with the above setup, a choice between four-way and eight-way would be good. If you decide to implement gyro (which I don't think is strictly necessary), gyro sensitivity would be a good option.
3. Whoops, I didn't mean to imply that this would have an effect on DSDA-DOOM. I meant to say that implementing this would cause me to switch from DSDA-DOOM to Woof!.

If there is anything else unclear, please let me know.

[ceski-1]

@JustinWayland I added flick stick support here. Please try the AppImage here and share your feedback. You can select flick stick from the menu:

There are several new advanced joy_flick_* settings in woof.cfg as well.

[JustinWayland]

I tested this with a DualShock 4 controller, and it definitely feels like a promising first attempt, especially in four-way, but it has some issues.

It fails the "flick the stick right four times to get back to the neutral position" test, although to only a slight degree in four-way mode. (In four-way mode, flicking right four times results in the camera being off by one pixel from where it started, which I verified using the frontmost left column in E1M1.)

That being said, a quick play session of the original DOOM using flick stick was promising. Unfortunately, it also convinced me that gyro aiming is more necessary than I thought it was at first, as my right thumb was getting noticeably fatigued after just 10-15 minutes of gameplay. In addition, gyro input seems to be a humongous pain from a quick google search.

I still think we should move forward with this, because gyro support is way less fiddly to add using Steam Input than flick stick, so this would go a long way towards making it easy to use a modern controller scheme to play DOOM.

If we decide to implement gyro the hard way, I do have a Switch Pro controller to test with.

[JustinWayland]

I just realized that a potential candidate for why the "flick joystick right four times to get back to original position" failed is because there was no way to turn off the turn after flicking functionality. Could you implement changing the sensitivity of the turning so that I can turn it off and see if the basic flick functionality works?

[ceski-1]

Thanks for the feedback! I'll take a look at snap to angle flick behavior. I'm currently adding native gyro since I think a complete solution makes the most sense.

https://github.com/user-attachments/assets/4ccef3aa-0d0f-4245-af4e-b53c6d950dc2

[JustinWayland]

Make sure to add an option for how much the camera turns when you revolve the control stick so I can test the underlying flick support! It could be that the underlying flick implementation is sound and would normally return the camera to it’s original position, but that tiny vibrations made at the edge when testing the flicking interfered with the result.

For a similar reason, if the next AppImage you provide me has preliminary gyro support, make sure I can turn that off too.

I remember having to do that when configuring the fake flick stick on the Steam Deck. God that was fiddly…

[ceski-1]

It seems like a limitation of the original implementation in JoyShockMapper. It provides different "modes" to work around it, so I added joy_flick_mode to woof.cfg which does the same thing:

[0-2(0)] Flick mode (0 = Default, 1 = Flick Only, 2 = Rotate Only) 
joy_flick_mode               0

AppImage is here.

[ceski-1]

And this one adds joy_flick_rotation_speed as an alternative for fine control:

[0-50(10)] Flick rotation speed (0 = 0.0x; 50 = 5.0x) 
joy_flick_rotation_speed     10

[JustinWayland]

Just tried out the version where you can turn off the rotation functionality. I can now definitively say that the basic flicking functionality works.

That being said, there is some shaking when I just hold the right stick forward with the rotation functionality on with my old but barely used DualShock 4, so I think we need to implement some sort of deadzone functionality for after we flick to support older controllers. That seems like the hardest part to implement.

[ceski-1]

That being said, there is some shaking when I just hold the right stick forward with the rotation functionality on with my old but barely used DualShock 4, so I think we need to implement some sort of deadzone functionality for after we flick to support older controllers. That seems like the hardest part to implement.

Do you notice this issue with JoyShockMapper or Steam Input?

[ceski-1]

I tested it myself. Steam Input + Woof and Fortnite (implemented by the JoyShockMapper author) have the same issue, which is down to the low-res DualShock4 analog sticks (they're only 8-bit I believe). There's already some smoothing applied in all three implementations (it's much worse without it). I don't think it can get much better than this.

[JustinWayland]

Damn, that sucks. The Steam Deck has spoiled me. Maybe it's time to pony up for a DualSense, or wait for the HORIPAD for Steam to be released.

Go ahead and start the gyro implementation then. I barely used the turning functionality in DOOM anyway when I was using it on the Steam Deck. I just used the gyro to turn.

Make sure to add the ability to bind a button to turn off the gyro, so that the controller can be set back to neutral.

[ceski-1]

Maybe it's time to pony up for a DualSense, or wait for the HORIPAD for Steam to be released.

DualSense is also 8-bit. I'm not sure about the HORIPAD.

Make sure to add the ability to bind a button to turn off the gyro, so that the controller can be set back to neutral.

Absolutely! (Watch the video and look closely!)

[JustinWayland]

Can see you are doing good work on the gyro implementation. If you want me to test it with my collection of sketchy controllers on Linux, just provide me the AppImage and I will gladly look at it.

[ceski-1]

That would be very helpful, thank you. Here's the latest AppImage. I recommend using a default woof.cfg (delete or backup your current one) since a lot has been shuffled around. Also, the gamepad/gyro menus are different, so please let me know if you find it easy to navigate when going in blind.

[JustinWayland]

Just downloaded it, but don't expect feedback for a while. I have to deal with a project for a program I am doing that will take some time, but once that gets done I'll hop onto this.