Our ReVolt Pub

Hi. I'm having an issue when it comes to mapping the controller buttons in the option-menu. As soon as I'm about to edit one of the keys, the menu goes bananas and suddenly jumps right to the next key and thereby races all the way to the bottom of the mapping-menu. I suppose that to map a key, I first have to click on the button with a single click, and then I'm supposed to click on the key that I want to bind to that action.

Is it supposed to work that way, or can it be that my installation of RVGL or even my PC settings are making this game misbehave? I know that I can configure the config via a text-editor, but I'm not quite sure of the naming of each of the buttons on my Xbox One or my Xbox 360 controller in this game (Axis+ Axis- and so on).

I knew I had read something somewhere

Xbox Gamepad Troubles with Revolt

Hope it helps.

All the best,

Touriga

Yes, see some of the discussion in the Re-Volt Live page that Touriga linked (specifically the report by OdieHerpaderp). Your problem sounds very similar.

I'm guessing it's an SDL2 bug or limitation that affects handling of the Xbox controllers. SDL assumes an axis input range of -32767 to 32767, but the XInput drivers use an unsigned 0 to 65535 range for at least one of the axes (Axis-4 Axis-5 according to Odie). So this axis is incorrectly detected to be always pressed.

I have uploaded a test build that displays the values of each axis in frontend. Make sure your controller is plugged in and selected for Player 1, then you should see the values displayed. Can you tell me what the values are when:
1) all axes are in rest position
2) when axis 4 is to the left and right extremes (Z-axis- and Z-axis+)

Download the test build here (both windows and linux builds included):
rvgl_controller_test.7z

While all axes are in rest position I supposed Axis 1-4 should be around 0, but it is never above +-4000 while in center/rest position. Those four axes are ultra-sensitive, and goes up av down all the time while seemingly standing still, but never above +-4000. Axis 5 (left trigger) and Axis 6 (right trigger) is at -32768 in rest-position, and they both are at +32767 while the triggers are pushed all the way in.

Axis 1 is left (-) and right (+) on the left stick, while Axis 2 is the up (-) and down (+) on the left stick. Axis 3 is the left (-) and right (+) on the right stick, while Axis 4 is up (-) and down (+) on the right stick. Axis 1-4 goes all the way from -32768 to +32768 (might be 32767 or somewhere close under some circumstances).

This is tested on a Xbox 360 controller.


I forgot to ask, but does RVGL use xinput or directinput? I read that RVGL is powered by SDL2, and I'm not personally sure if SDL2 is compatible with xinput. The problem with directinput in say splitscreen games with many controllers (wireless xbox 360/xbox one controllers in my case) is that as soon as player 2 connects, the key bindings for player one jumps over to the next controller, so the guy with the second controller becomes player one.

i ended up sticking to keyboard because revolt has a lot of issues with controllers
Z axis issues with sidewinder forcefeedback pro. xbox 360 worked fine with directinput except for the reasons why xinput was created.
huki: could a xinput enabled 1.2 be made to confirm behavior?

EDIT: SDL2 is XInput, the implementation is just wrong because all axis are NEVER zero, triggers are properly detected the issue is that it always produces input so thats why setting controls is impossible unless you know to set it via ini (this happened since 1.0: the very first input detected is set regardless, thats why its sort of impossible)

EDIT2: on my xbox 360 wireless controller i see six axes, 1 and 2 are lstick, 3 and 4 rstick and 5,6 are left and right triggers respectively, its impossible to reach 0. (answering your question)
[HIDE=Here's the readings when the controller is resting (L and R stick axes are never still) i confirm the trigger issue][/HIDE]

Excellent, now things are more clear (and thanks for the screenshot, Abc). There was a point that confused me: the axis index in the controller config menu starts from 0, but in the debug text I added, it starts from 1. OdieHerpaDerp mentioned his "axis-4 was always depressed" (in the config menu), but this corresponds to Axis 5 in the debug text (basically, all you are referring to the same axis).

The small input in axis 1-4 is not a problem (perhaps the controller is really sensitive). If it poses an issue when racing, you can set an appropriate deadzone (10% - 15% would do).

The real problem is axis 5 and 6 (the triggers) which are at -32768 when at rest. This is bad since they will be detected by the game as always pressed. I can prepare a quick test build that disables these 2 axes, then you can't use the triggers but it will work.

Gagster wrote:I forgot to ask, but does RVGL use xinput or directinput? I read that RVGL is powered by SDL2, and I'm not personally sure if SDL2 is compatible with xinput.

SDL2 uses XInput for controllers that support it, but we just use the generic Joystick API. It means we just get the raw input from SDL for each axis and assume it's 0 at rest, -32767 and +32767 at the ends. This is probably not the correct way to handle the Xbox controllers. We might have to use the GameController API if it's available.
In fact I just found this page that confirms it: Game Controller API in SDL2

XInput support on Windows:
It'd be nice if this weren't a real issue, but it is. On windows, you can read an XInput device as a raw joystick, but you get startled with a number of quirks such as the left and right triggers being treated as a single axis (one positive direction and one negative).

Gagster wrote:The problem with directinput in say splitscreen games with many controllers (wireless xbox 360/xbox one controllers in my case) is that as soon as player 2 connects, the key bindings for player one jumps over to the next controller, so the guy with the second controller becomes player one.

Can you confirm if this is still an issue with RVGL?

the sensitivity issue doesnt happen in a game that supports xinput properly, hell, it tends to have more left than right in directinput. in blur for example the stick is more still not a bit twitchy.
in dolphin i remedied this issue by setting around 18% of dead zone. (when setting gamecube controller)
i also noticed that it only refreshes controllers when you enter controller settings (actually, i am recalling this from 1.2)
the quirks they mention are actually quirks that happen in directinput which are all resolved in xinput (at least windows)

could you please make a xinput enabled 1.2 build just to see how it reacts.

Gagster: did you try with the game running or across restarts? did you ensure the controller light is proper? (it can happen that both turn off and when they're back on they end up inverted (player 2 turns into player 1) because wireless ones take a bit to connect to the reciever sometimes)
I cant reproduce gagster's issue. unless he means the binds get reset which in effect happens when you switch between controllers.

i couldnt put the controller in player 2/3/4 because it didnt let me, odd (controller testbuild)

I was talking more about directinput in general, when it comes to older games (like 4 player splitscreen in MotoRacer 2 with four wireless xbox 360 controllers). In those older directinput games the player 1s key binding moved over to player 2 once the secondary controller was attached, but I should now test it in RVGL and see how it behaves with multiple controllers attached.

That's probably because the new controller overrides the old one...
another reason of why xinput was made i guess....
the sensitivty issue happens with *all* games unless they know about it (it seems like it has some built in thing that is digitally rigid) (just like the sidewinder had a laser sensor for making the stick soft vs natural)

Fun fact: Xbox 360 controller for windows is the "golden" example for XInput (it's the original device where it all started)

Now I did try to set up a 4 player splitscreen game using 4 wireless Xbox One gamepads (I have both 4 wireless Xbox One gamepads and 4 wireless Xbox 360 gamepads). The issue here is that player 1 can choose between all the four Xbox gamepads in the options/controllers menu, while the 3 other players somehow is restricted to using the keyboard. It is not possible to choose one of the xbox controllers on neither player 2, 3 or 4.

Edit: I just tested the older Re-Vold game folder with the 1.2 community patch installed, and there I could choose an Xbox controller for each player in the options/controller menu. I even copied over the profile.cfg from the old Re-Volt folder to the RVGL one, and still I was not able to choose a gamepad on player 2-4.

It also seems like both the left- and right trigger buttons on the Xbox controller is disabled in the Re-Volt 1.2 community patch.

Gagster @ 17 Apr 2016, 09:36 PM wrote:Now I did try to set up a 4 player splitscreen game using 4 wireless Xbox One gamepads (I have both 4 wireless Xbox One gamepads and 4 wireless Xbox 360 gamepads). The issue here is that player 1 can choose between all the four Xbox gamepads in the options/controllers menu, while the 3 other players somehow is restricted to using the keyboard. It is not possible to choose one of the xbox controllers on neither player 2, 3 or 4.

Sounds like a bug in RVGL. Strange it was not reported before, but it should be simple to fix.

It also seems like both the left- and right trigger buttons on the Xbox controller is disabled in the Re-Volt 1.2 community patch.

Yes, the original versions and 1.2 disable the axes that are detected to be pressed when entering the config menu. I didn't keep the hack in RVGL. I guess we can temporarily put it back until we switch to the GameController API (which should be the definitive fix).

I'll be uploading a test build soon with the above 2 fixes...
EDIT:
Download the test build here (both windows and linux builds included):
rvgl_controller_test2.7z

changelog wrote:This build attempts to:
- fix controller selection for players 2-4
- disable funny axes

Let me know if it's working as expected.

The new build seems to fix all those issues regarding the Xbox 360/One gamepads. I tried 2 player splitscreen-mode and 4 player splitscreen-mode, and after that 1 player mode with each of the player key-configs assigned to a Xbox One controller.

Now the left- and right triggers are disabled, and it may be for the best until the other controller API (GameController API) is utilized.

The old directinput-issue where the player one keys gets assigned to the player 2 controller when the player 2 controller is powered on is not found here, so that also seems to be working as it should.


Good job.

I just found a new issue: If you start the game without any controllers connected, the players controls is viewed as Keyboard in the options/controller section. That's fine enough, but if I close the game again, and reconnect all the four Xbox controllers, I then have to manually select joypad #1, #2, #3 and #4 for each player in the Controller-menu (keyboard by default). After I have done that, my previous key-bindings are back to the default keybindings on the controllers, and I have to start all over again with mapping the buttons.

It seems like RVGL forgets all keybindings after the game is started without controllers connected.

Since there's no fix for the 360 controller trigger issue yet, i've went and made a workaround that doesn't involve breaking your drivers. Thread can be found here

I've worked on utilizing SDL GameController API for devices that support it. Here's a build:
rvgl_controller_test3.7z

Here are the new changes introduced (none of which is tested yet - I don't own any controller):
1) GameController mapping is used for devices that support it: this means Triggers should work and be selectable along with other axes.
2) The Controller Config menu should show the axis and button names (instead of simply Axis 0, Button 1, etc).
3) The buttons used for menu navigation are: forward - Fire (Button A by default) and backward - Pause (Button Y by default).
4) Devices that don't support the new API will fallback to raw joystick input and keep working as before.

I'll look forward to hearing some test results.

With 64 bit version of game brings 0xc000007b and can't run. With 32 bit version of the game runs, in the controller mapping displays the trigger. Menu navigation forward cannot work.

GreatLamer @ 11 Sep 2016, 11:38 AM wrote: With 64 bit version of game brings 0xc000007b and can't run. With 32 bit version of the game runs, in the controller mapping displays the trigger. Menu navigation forward cannot work.

I only released a 32-bit test build. About menu navigation, it uses whatever button you have set for the Fire key. This should be Button A by default. If it doesn't work, can you re-configure the Fire key and try again?
Also, what controller are you using?

Thanks for the infos. I binded the fire button to right trigger (accepted by the game) which can't work in the menus.

The controller is a Sony Dualshock 3 with SCPToolkit.

Ok, in fact only buttons were supported for menu forward / backward. Setting the Fire button to an axis makes it unusable with the menus.
I updated this part: now both buttons and axes can be used for menu navigation. Try the new build:
rvgl_controller_test4.7z

Thanks, that works so the game well playable now.