Allow user to redefine up/down/left/right buttons for joypad

[pjft]

Apologies if this is not the way to go about it.

I've seen several comments and requests in the past regarding being able to configure and use a digital pad for up/down/left/right in the menus even though we'd want to use analog joysticks for the game. An example is when using a PS3 controller or XBox one. The analog controls, while fine for the game, don't allow us to navigate the menus effectively.

I added an option for "Digital Gamepad", which enables users to define up/down/left/right and use it for the menus and in-game. The option's default is off which means that it should behave exactly like before, but I may be wrong. I made the default gamepad button values be set outside of the normal range (so that they don't overlap with potentially in-use buttons in existing set-ups without the digital gamepad), but let me know if you're not happy with that.

I hope this works for you, but let me know otherwise. It was my first time looking into the codebase, and while I read it and re-read it and tested it to the best of my ability, I will likely have missed something glaringly obvious.

Thanks for the fantastic work here.

[pjft]

Hi @djyt

Apologies for bothering, but gently pinging this. Anything needed on my end here? I've been running this for the past weeks and all seems to be running well.

Thanks.

[benscarisdead2]

@pjft seems to be working fine on my end

[pjft]

@benscarisdead2 thanks for testing. By the way, slight tangent, loved your videos on OutRun week (I assume it was you), and your interview to @djyt !

[pjft]

Hi @djyt and team. Any feedback or update here?

[pjft]

Hi team. Apologies for pinging this again. Happened to play a session of Cannonball today on a PS3 controller and remembered that I hadn't heard from this in a while.

Any update would be helpful.

Thanks, and have a great week.

[djyt]

I'm leaving this open for now, as I need to fix this.

I've reworked a bunch of the joypad code, but will aim to get this functionality in to a release soon.

[pjft]

Thanks - good to hear. Cannonball is an awesome way to relive OutRun, glad to hear this can help.

[djyt]

Hello! I have implemented the following. Please try it out and let me know if it works for you. I can build you a Windows build if useful.

1/ Menu: You can use the d-pad (aka the HAT in SDL terms) to scroll around the menu. This shouldn't need configuration, so long as the controller is plugged in. (It also shouldn't matter whether you have analog enabled or not.)

2/ In-game: You can use the d-pad to control steering when analog controls are disabled.

3/ In-game: When analog is enabled, the d-pad to control steering is disabled. You need to use the analog stick.

[pjft]

Thanks for the heads up. I'm running things on a Raspberry Pi, but I'll try to build it on my end.

I'll let you know if I run into any issues - thank you.

[pjft]

I built it on the Pi4, using a PS3 Sixaxis original controller and ran it. I'm running it in a new folder, so not using the old config.xml file. It's been a while since I set it up, so memory isn't what it used to be. What am I finding:

• I can't control the menu with DPad nor analog, unless I'm missing something.
• I manage to start a game somehow - L2 (brake) seems to insert a credit, and R2 (acceleration) starts. Analog works fine without configuration.
• "Cross" changes gear.
• "Square" seems to exit the game back to the menu.

Also, the game seems to take a lot longer to load - on "top", it seems to be doing a lot of filesystem accesses and waiting on them. The first few times I thought it wasn't able to start for some reason, but only after opening "top" and noticing that the process was slowly progressing did I decide to wait.

Hope this helps, I'm happy to get some debug logs if useful.

Best.

[djyt]

I've tested on a Pi 4 here, and everything was fine in terms of loading. I haven't tested on the Pi4 with a controller though (only on Windows), as I'm using the SmartyPi interface.

In romloader.cpp, try setting this to false: const static bool CRC32_LOADING = false;

The latest build scans the roms directory by CRC32 value for the ROMs. There were so many different naming conventions out there this seemed like a good idea. It boots instantly for me on the Pi4. Do you have loads of files in your roms directory that shouldn't be there? That could slow things down.

Not too sure what's going on with your controller. I only have one controller to test with (Xbox 360) and it works fine for me (with analog enabled or disabled in the menu) - but I appreciate that isn't particularly helpful feedback for anyone! I presume you redefined the control pad in the config?

[djyt]

Read some more documentation. I think I need to write some code to handle Game Controllers for this. I'll do so...

[pjft]

Oh, I'm so, so sorry - I completely misunderstood the initial comment. When you wrote "You can use the d-pad (aka the HAT in SDL terms) to scroll around the menu. This shouldn't need configuration, so long as the controller is plugged in. (It also shouldn't matter whether you have analog enabled or not.)" I understood it as that it should work without me doing any kind of set up.

No, I did not try to redefine it in the config as I thought it would be contrary to what I being asked to test :) I'm happy to do so if you'd want me to - I probably misunderstood it.

About the CRC thing, that's probably it indeed. In my case, I just run the ROM from a NFS, and that's probably the cause for the delay in the operation - nothing more. If it loads properly in a local scenario, that's awesome.

Thanks for going at it, and I'll test both later - removing CRC loading and defining the joypad buttons.

[djyt]

No you are right. This shouldn't need manual configuration in terms of simply navigating the menu itself with up and down.

The problem I have is that I only have one controller to test with, whereas I probably need about 10!

I have made a couple of additional fixes in the latest check-in. Can you try the following:

1/ Up/Down in menus may now work for you out of the box. I've added another way of doing this which captures the controller mapping.

2/ Ensure you have Analog disabled in the Controls->Settings

3/ Try redefining the rest of the controller buttons as you see fit.

[djyt]

Right, as you will see I've done a bunch of stuff.

If, in config.xml, you set the pad controls to '-1', the code will now attempt to auto-assign some sensible button configurations.

Obviously, every joypad is different and has different buttons. So, the assignments might not be great. But everything should get assigned to something.

These can then be overridden by manually redefining the pad controls.

The main bulk of this code is in the Input::open_joy() function, if you want to delve into it and provide me with any information.

I'm hoping that as a result of this your pad should work as desired (and hopefully other peoples too!)

[djyt]

Also suggest we move further Controller chat into a discussion here: https://github.com/djyt/cannonball/discussions/76

As I'm not merging this code directly.