Dual-joystick setup (port 0, port 1) not working properly in some games

[Drag0nFly]

Apologies if this has been reported earlier (nothing showed up with a search - on Github or elsewhere), but as I've just spent the better part of a day trying to get this working without any success I am submitting this as a potential bug report.

I have two wireless joysticks (“joypads”, rather). One is a Gioteck VX2, and the other is a DualShock 3, connected via bluetooth. They both work great individually, but not at the same time (which was the intention for using two in the first place). The Gioteck is the one I use as the primary in EmulationsStation.

Let me clarify–they both show up in Amiberry (providing the DS3 is turned on). Whichever stick is then set for Port 1 will be the one being used. The other controller does nothing (tried setting it to 'mouse' or 'gamepad', etc. to not effect) Also tried the custom controls menu to change 'joystick port' to 0, as well as set one of the controllers as an “emulated parallel port joystick adapter”.

I've tested with a few games (currently testing with SWIV_v1.7_0038.lha), and the problem appears consistent. Since these are launched via WhdLoad, I've also verified its settings in whdload_db.xml (config included at the bottom).

I can safely say that there are no driver issues causing this, as I can switch on-the-fly between the DualShock 3 and the Gioteck after the game has launched, it works without issues.

I've also tested running “jstest /dev/input/js1” (js1 being the joystick which isn't responding while in Amiberry) but all buttons register.

However, the second joystick never sends any actual input to the game, whereas the keyboard does. (R_Shift acting as the firebutton, at least in SWIV)

My unqualified guess would be that it appears that one of the ports may be hardcoded to the dreaded “Retroarch Keyboard as joystick [#1]” (wish there was an option to simply disable this, as it also messes up standard keyboard in Workbench when it is erroneously set – with "W" acting as fire, causing it to send a carriage return)

The abovementioned setting is not set when the game is launched btw. (only if the joystick in port#0 is switched off due to a timeout). Tested a few times with both joysticks on, and they are showing up correctly in Amiberry's Input settings as they should, so all seems well at least.

Really don't know what I could be missing, config-wise, here. It may be something trivial. So I appreciate any comments.

Relevant part of Amiberry configuration–

;
; *** Controller/Input Configuration
;
joyport0=joy1
joyport0_autofire=none
joyport0_mode=djoy
joyport0_friendlyname=Goodbetterbest Ltd Gioteck VX2 2.4G Wireless Controller
joyport0_name=JOY1
;
joyport1=joy2
joyport1_autofire=none
joyport1_mode=djoy
joyport1_friendlyname=Sony PLAYSTATION(R)3 Controller
joyport1_name=JOY2

       <game filename="SWIV_v1.7_0038"  sha1="79dc560938e33bfaef1e3e23e36306491158cea8">
                <name>SWIV</name>
                <subpath>SWIV</subpath>
                <variant_uuid>28f044ea-3089-5326-8137-90f95403b77a</variant_uuid>
                <slave_count>1</slave_count>
                <slave_default>SWIV.Slave</slave_default>
                <slave_libraries>False</slave_libraries>
                <slave number="1">
                        <filename>SWIV.Slave</filename>
                        <datapath></datapath>
                        <custom>
                        C1:B:Disable jump control (if 2nd button pressed)
                        C2:B:Unlimited lives
                        </custom>
                </slave>
                <hardware>
                PRIMARY_CONTROL=JOYSTICK
                PORT0=JOY
                PORT1=JOY
                FAST_COPPER=FALSE
                JIT=FALSE
                SCREEN_AUTOHEIGHT=FALSE
                SCREEN_HEIGHT=512
                SCREEN_CENTERH=SMART
                SCREEN_CENTERV=SMART
                </hardware>
        </game>

[midwan]

There's nothing hardcoded, unless it's configured that way externally (e.g. from amiberry.conf of other config files).
Let's start with the basics though: What if you set your 2 joysticks in the first 2 ports, then start up something like AmigaTestKit (grab the ADF from here: https://github.com/keirf/Amiga-Stuff/releases/tag/testkit-v1.18).

Set the ports to Joystick or gamepad in the AmigaTestKit and see if you get input from both of them.

If you do, the problem is not generic but more specific to WHDLoad perhaps, which might be related to configuration. If you don't get any input from one of them, then there's something more generic going on with your setup.

In general, all 4 ports should work simultaneously (the 2 Parallel port ones can only be used as Joysticks, the first 2 can have different modes, such as mouse, joystick, gamepad, cd32 etc).

[Drag0nFly]

Good suggestion. (btw., the reason I mentioned hardcoding of the “RetroArch keyboard as joystick” was that this continues to get replaced, most recently with my A1200 WorkBench HDF image. Took me a while to figure out that the keyboard actuallt wasn't broken (sending W + CR, as it was a "joystick"). Apparently RetroArch keeps introducing this for some obscure reason (as if anyone would want to use a keyboard as a joystick...)

Tried SysTest now; both the DualShock 3 (over bluetooth/port 0) and the Gioteck VX-2 (over RF/port 1) register at the same time–both with Port 0 (Port 1 in Systest) set to "Mouse" and when changing it to Joystick. Also works as Gamepad, although it states “gamepad not detected”.

See attached screenshots–

[Drag0nFly]

It's the same thing when loading the game (in this case, SWIV) from adf – input from the joystick configured in the mouse-port is not detected/ignored. When it is changed to “Mouse” in the input config, and emulation resumed, it registers in the Cracktro screen (to load the game). However, once the game is loaded, the joystick plugged into port 0 does nothing.

If the joystick is then moved to port 1 (switched with the DualShock 3), it works again.

btw.-is it possible to have the file-selector register holding the mouse button down to scroll the list? Currently it requires one to repeatedly press LMB. Since PageUp/PageDown also do not work (at least with my keyboard), navigating the file-selector takes pretty much forever if there are a few games in it.

[midwan]

I just noticed that you're not running the latest Amiberry version, from your screenshots.
Retropie is still providing 3.3 only, but hopefully that will be updated (we have an open issue with them about it).
If you can compile Amiberry from source yourself, then you can test this on the latest version, where I'm also doing the tests. Otherwise, perhaps wait until Retropie have updated their system accordingly, and can deliver the latest Amiberry version (4.1.6 currently).

[Drag0nFly]

Yes, the reason I am running v3.3 currently is due to the loading of existing savestates not working (#831). I did a search for past issues to see whether any fixes for joystick handling had been added which would impact this, but did not notice any (obviously that doesn't mean there aren't any changes to this)

As v3.3 seems to work just as well for my use, I left it as is (and since there are some config-file munging going on when moving between different version, see the comment regarding keyboard as joystick etc. which happened when moving to 3.3)

I was thinking on tarring down the Amiberry configs and giving the most recent git version a try later in order to avoid a wild goose chase wrt. trying to nail this issue down.

However, since v3.3 is standard in Retropie someone else should have noticed this (or a dual-joy setup is uncommon)

[Drag0nFly]

Upgraded to v4.1.6 – exactly the same issue when testing via WhdLoad and directly from adf (using kick 1.3, 68000, 7Mhz). Both joysticks show up in Amiberry, but the one in port 0 does nothing. When switching the joystick on the dead-input-port to port 1, it works as expected.

Curiously both the mouse (unconfigured in Amiberry) and the joystick in port 0 register in the cracktro screen (before the game loads)

Also, the “sound_max_buff” setting which was reverted by me in v3.3 to 4 (and finally became persistent) in order to solve the >1sec audio delay) is now back to 8, although it is not referenced in any config files (WhdLoaded games from EmulationStation should use the default.uae config file)–

grep sound_max /opt/retropie/configs/amiga/amiberry/conf/*
/opt/retropie/configs/amiga/amiberry/conf/a500-1.3-kick-adf.uae:sound_max_buff=4096
/opt/retropie/configs/amiga/amiberry/conf/a1200-custom-030-nojit.uae:sound_max_buff=4096
/opt/retropie/configs/amiga/amiberry/conf/a1200-custom-030.uae:sound_max_buff=4096
/opt/retropie/configs/amiga/amiberry/conf/a1200-custom-nojit.uae:sound_max_buff=4096
/opt/retropie/configs/amiga/amiberry/conf/a1200-custom.uae:sound_max_buff=4096
/opt/retropie/configs/amiga/amiberry/conf/a1200-custom.uae.bak:sound_max_buff=4096
/opt/retropie/configs/amiga/amiberry/conf/default.uae:sound_max_buff=4096
/opt/retropie/configs/amiga/amiberry/conf/default.uae.bak:sound_max_buff=4096
/opt/retropie/configs/amiga/amiberry/conf/rp-a500.uae:sound_max_buff=4096
/opt/retropie/configs/amiga/amiberry/conf/rp-a1200.uae:sound_max_buff=4096

[Drag0nFly]

So the issue is unrelated to v3.3.

[Drag0nFly]

To clarify–what I mean when referring to the mouse above is the one used to control the GUI. It is not configured in any Amiga ports, but can still be used (alongside the controller in port 0 which is otherwise dead) as LMB to bypass the cracktro screen.

[Drag0nFly]

Actually, the behaviour is not completely identical. Despite both joysticks registering on the Linux-side with jstest and showing up in Amiberry's drop-down menu, the PS3 controller cannot be selected once this has had a sleep timeout (turned back on, verified that it talks to the system with jstest)

I did not experience this issue with v3.3 but will re-test.

Selecting "PS3 Controller" causes the existing entry "System mouse" to be selected. See attached screenshot.

[midwan]

Thanks for testing.

I just tried it on Retropie here, and I found the following:

• Same problem as you described on SWIV
• Working fine in AmigaTestKit
• Working fine in Pang

This tells me the emulator is working normally, processing and sending the joystick inputs correctly to the Amiga environment. Pang works fine with 2 players, so perhaps try that on your side also?

I tested it with 2 PS4 controllers (wired).

[Drag0nFly]

v4.1.6 of Amiberry uses a different identifier for the DualShock gamepad. In v3.3 it shows up as “Sony PLAYSTATION(R)3 Controller”, but in 4.1.6 it is identified as “PS3 Controller” (which is what it reports only when wired)

btw.–I have not rebooted the pi (or restarted any bluetooth stack), only replaced the v4.1.6 version with v3.3

I re-tested this now with v3.3, and it crashes if the PS3 controller was powerd off, the mouse selected, and it re-selected again. Ah, the joys of bluetooth (took even longer to configure that on the Raspberry side for it to even get detected and pair properly...!)

[Drag0nFly]

I did struggle for a time to find an actual game to test with two joysticks. Looks like I picked the “wrong” one. (Naturally, this is based on games I'd actually want to play in two-player mode)

I don't have "Pang" available atm. but I assume it will work then. Thanks for the tip.

[midwan]

I also just tested Chaos Engine (AGA) - WHDLoad version. Also works fine.

I think this may be some sort of problem with SWIV and maybe only the WHDLoad version? Not sure, more tests would be needed - but it seems to work in general otherwise. :)

[Drag0nFly]

No, as mentioned earlier in the ticket it also affects the ADF version. I've tested that a number of times.

[Drag0nFly]

Tested Lotus Turbo Challenge 2 (WHDLoad version) and it works with both joysticks under v3.3

[Drag0nFly]

(Really weird that the one game I initially chose to test had such issues with the 2-player mode)

[midwan]

Thanks for confirming!

[Drag0nFly]

As a side note it does sound like it would be something for the WHDLoad package to address. I can also test with one of my actual Amigas (although that test will be with two Giotecks instead of one + a bluetooth controller)

(For transparency one should perhaps remove the v3.3 tag, as this works well on this version and change the “not working properly” to “not working properly for some games” if anyone is searching previous tickets for a similar issue.)