FS-UAE 3.1-stable

[-fun-]

Ok, so the game configuration remembers the old controller name (starting with "Unknown") and this is not changed when I select the correct controller in the settings in the Launcher.

I manually edited the configuration file and added the correct controller name. The game then starts with the controller connected. Check.

The button mapping is still not working. Is there an issue with the numbering of devices?

In the game configuration there is:

joystick_port_1 = 8Bitdo SFC30 GamePad

So I added to the configuration in the Launcher:

joystick_1_east_button = action_key_space
etc.

in addition to

joystick_0_east_button = action_key_space
etc.

But no.

[-fun-]

Button mapping is still not working.

What i tried so far:

• Using joystick_1_east_button = action_key_space in addition to joystick_0_east_button = action_key_space
• Referencing the device by name: 8bitdo_sfc30_gamepad_east_button = action_key_space
• Putting the button configuration into the game configuration file

Nothing worked.

The auto fire problem appeared once again but I cannot correlate this to any of my actions.

[FrodeSolheim]

@fun I did not managed to reproduce the problem, but I'm sure we'll get it working for you.

But first of all, can you confirm that you are actually using the latest 3.1.x versions available for FS-UAE & FS-UAE Launcher?

And in particular, can you confirm that you have not tried FS-UAE 4 preview earlier, and the Launcher does not actually start the FS-UAE 4 preview version? That could explain a lot of your issues. FS-UAE 3.1 should like more or less like 3.0. If the UI is different, then you're running version 4.

If this is not the problem, I'd like to see the logs for both FS-UAE and the Launcher (https://fs-uae.net/log-files-needed). You can post them here or send to frode@fs-uae.net.

[-fun-]

I never had version 4 installed. Latest versions 3.x: Yes, checked.

Attached are the logs and the game config. On this run there was no problem with auto fire, just the button mapping missing.

Thank you for looking!

[FrodeSolheim]

Originally Posted by -fun-

Attached are the logs and the game config

Thank you, the log files are enlightening I'll probably get back with an update in a day or two.

[FrodeSolheim]

Version 3.1.57 of FS-UAE & Launcher is available. Changes in this version:

* Prefer $HOME/FS-UAE if it exists, otherwise use $DOCUMENTS/FS-UAE.
* Support joystick_port_[port]_[gamepadinput] input mapping.
* Read [guid].fs-uae-controller controller configs.

@-fun- This version should support your controller out of the box. The issue was that FS-UAE never read the [guid].fs-uae-controller files, only the older name-based config files, which was not included.

It also contains a very use input mapping improvement. You can now do input mapping based on the joystick port, for example:

joystick_port_1_east_button = action_key_space

This allows you to map player-specific commands onto (only) the gamepad inserted in the relevant port (and also without having to refer to the gamepad model, which was already possible).

Also, I found the explanation for both ~/FS-UAE and ~/Documents/FS-UAE being used. I had added some code to the Launcher which looked up both directories to see if either one existed - and use that, but it defaulted to ~/FS-UAE. FS-UAE itself did not have this code (not a problem when used from the Launcher), but if used standalone, it would use ~/Documents/FS-UAE while the Launcher might already have created/used ~/FS-UAE. I cleaned up this mess the following way.

Both the Launcher & FS-UAE now agrees to use ~/FS-UAE if it exists, otherwise use ~/Documents/FS-UAE. (~/FS-UAE will also probably become default in the future).

[qupe]

I don't know if this will help the issue above.

I have just replaced 3.02 with this version and had to set my gamepad mapping like this
Xbox_360_Controller_button_5 = action_warp and it worked. It ignored the old xinput setting I had. So I changed it to match my controller config names, I didn't have to do that before.

I am setting up individual game settings for all the games as 2 player games weren't setup for 2 joysticks in the old build so I've carried over those configs.

[FrodeSolheim]

Originally Posted by qupe

I don't know if this will help the issue above.

I have just replaced 3.02 with this version and had to set my gamepad mapping like this
Xbox_360_Controller_button_5 = action_warp and it worked. It ignored the old xinput setting I had. So I changed it to match my controller config names, I didn't have to do that before.

I am setting up individual game settings for all the games as 2 player games weren't setup for 2 joysticks in the old build so I've carried over those configs.

This is not a bug in FS-UAE as such. The reason is that the updated SDL2 library has changed the name of some devices. In this case, it's really an improvement ("Xbox 360 controller" actually being named as such and not only "Xinput controller"), but it unfortunately means interfering with joystick name-based configs.

The best solution is probably to move away from using joystick names where possible. For example, instead of

Xbox_360_Controller_button_5 = ...

you can in FS-UAE 3.1.57 or higher do:

joystick_port_1_right_shoulder = ...

(Note: There will probably be an minor update really soon where the option scheme is renamed to

joystick_port_1_controller_right_shoulder = ...

)

[jbl007]

So this means

$controller_name_button_x

will stop working entirely?
This would be very sad because this makes my app completely useless.
https://github.com/sonnenscheinchen/fsactioneditor

In my opinion 1:1 button_no:action mapping is the way to go. This SDL north, west, south, whatever button is extremely confusing. Especially if your controller has lots of buttons you still need to guess which one is which.

[FrodeSolheim]

Originally Posted by jbl007

So this means

$controller_name_button_x

will stop working entirely?
This would be very sad because this makes my app completely useless.
https://github.com/sonnenscheinchen/fsactioneditor

No, I haven' removed any features It's just that the SDL library has added code to override the name of *a few* controllers. And in addition, the SDL library in some cases sidesteps the OS and talks more directly to Xbox and PS controllers using the USB protocol instead of going through the host joystick system. This could affect SDL's naming of devices. The point is SDL library upgrades *might* change the names of *some* devices, which will require reconfiguration if configuration is based on the (changed) name.

Originally Posted by jbl007

In my opinion 1:1 button_no:action mapping is the way to go. This SDL north, west, south, whatever button is extremely confusing. Especially if your controller has lots of buttons you still need to guess which one is which.

It should not be confusing or guesswork. In fact, the point is to make mapping both easier, more stable, and remove guesswork. The right shoulder button will *always* be called

right_shoulder

for all devices, instead of having to use

button_10

for some device and

button_6

for another. The only requirement for this is that the controller is recognized by the Launcher/FS-UAE *or* the user has used the controller configuration screen in Launcher settings to let FS-UAE know which button is which.

And the config will be generally more useful as well. If for example you replace your Xbox controller with a PlayStation one, the config will still work and make sense (mappings on the right shoulder button will still work the same, etc).

But again, no functionality has been removed. I just recommend moving away from hardcoding joystick device names when possible. And the new functionality where you can specify controller actions based on the port is especially useful to add stuff like player-based keyboard shortcuts to controllers

[FrodeSolheim]

Alright, version 3.1.59 is available now with the previously mentioned option rename. You can now use

joystick_port_[index]_controller_[event]

to match a game controller in a specific port, or

controller_[event]

to match all connected controllers. Some random_examples:

joystick_port_1_controller_left_shoulder = action_key_space
controller_left_shoulder = action_warp

(I also updated some included controller configurations that were broken)

[jbl007]

Originally Posted by FrodeSolheim

No, I haven' removed any features

Ah, that's relieving. I think I just misunderstood then....

It should not be confusing or guesswork.

As long as the controller database is up to date, yes, it works more or less...

Alright, version 3.1.59 is available now with the previously mentioned option rename.

Thanks. This is very useful.
Now I feel the need of touching my code after 6yrs... lol

[-fun-]

Originally Posted by FrodeSolheim

Version 3.1.57 of FS-UAE & Launcher is available. [...]
* Support joystick_port_[port]_[gamepadinput] input mapping.
[...]

joystick_port_1_east_button = action_key_space

This allows you to map player-specific commands onto (only) the gamepad inserted in the relevant port (and also without having to refer to the gamepad model, which was already possible).

Thank you for the update!! (I have yet to test it ...)

I'm a bit confused though: I definitely used the input mapping with the first version I installed. It sounds above as this was a new feature.

Originally Posted by FrodeSolheim

Both the Launcher & FS-UAE now agrees to use ~/FS-UAE if it exists, otherwise use ~/Documents/FS-UAE. (~/FS-UAE will also probably become default in the future).

I definitely prefer this default. As I wrote earlier as long as only one place is used both is fine, but still I believe this kind of stuff belongs into a user's home (at least in a Unix like environment, I couldn't care less about Windows :-)).

[FrodeSolheim]

Originally Posted by -fun-

I'm a bit confused though: I definitely used the input mapping with the first version I installed. It sounds above as this was a new feature.

Input mapping has existed for a long time. The news here is that the mapping can now be applied to (only) the controller inserted into a specific port, which generally makes much more sense than mapping to the "arbitrarily" Nth connected joystick.

[ztronzo]

Awesome implementation! I am already making good use for this feature..
For example we can now use the following configuration rows to play "Smash TV" using dual stick controllers to emulate 4 joy-sticks, with easy to to pick which controller you need attached at any time.

joystick_port_0_mode=joystick
joystick_port_1_mode=joystick
joystick_port_2_mode=joystick
joystick_port_3_mode=joystick

#Player 1 with 2 Joysticks (using Joy1 & Joy2):
joystick_port_1_controller_south_button=action_joy_1_fire_button
joystick_port_1_controller_west_button=action_joy_1_fire_button
joystick_port_1_controller_lstick_left=action_joy_1_left
joystick_port_1_controller_lstick_right=action_joy_1_right
joystick_port_1_controller_lstick_up=action_joy_1_up
joystick_port_1_controller_lstick_down=action_joy_1_down
joystick_port_1_controller_rstick_left=action_joy_0_left
joystick_port_1_controller_rstick_right=action_joy_0_right
joystick_port_1_controller_rstick_up=action_joy_0_up
joystick_port_1_controller_rstick_down=action_joy_0_down

#Player 2 with 2 Joysticks (using Par1 & Par2):
joystick_port_0_controller_south_button=action_par_joy_0_fire_button
joystick_port_0_controller_west_button=action_par_joy_0_fire_button
joystick_port_0_controller_lstick_left=action_par_joy_0_left
joystick_port_0_controller_lstick_right=action_par_joy_0_right
joystick_port_0_controller_lstick_up=action_par_joy_0_up
joystick_port_0_controller_lstick_down=action_par_joy_0_down
joystick_port_0_controller_rstick_left=action_par_joy_1_left
joystick_port_0_controller_rstick_right=action_par_joy_1_right
joystick_port_0_controller_rstick_up=action_par_joy_1_up
joystick_port_0_controller_rstick_down=action_par_joy_1_down

[DanielAllsopp]

Seems that with the latest version, `automatic_input_grab` is no longer working as it did and the mouse pointer keeps moving in and out of the window whereas previously I would have to manually un-grab it by using Alt-Tab.

Also, any news on the debugger support being fixed? The latest versions still exit the debugger immediately when accessed with F12+D.

[FrodeSolheim]

Originally Posted by DanielAllsopp

Seems that with the latest version, `automatic_input_grab` is no longer working as it did and the mouse pointer keeps moving in and out of the window whereas previously I would have to manually un-grab it by using Alt-Tab.

You're right, there seems to be an issue on macOS and Windows where the cursor is not trapped properly on startup (sometimes, it does not seems to always happen). For some reason, it does not happen on Linux. Using Alt+G twice fixes it as a workaround, but I'll be looking at this bug asap (https://github.com/FrodeSolheim/fs-uae/issues/286).

Originally Posted by DanielAllsopp

Also, any news on the debugger support being fixed? The latest versions still exit the debugger immediately when accessed with F12+D.

I have not been able to reproduce it, even on a similar computer/OS (MacBook Pro/M1/macOS12). So it does not seem to be a general issue, at least. Does it always happen for you? Does the Amiga/FS-UAE configuration matter? What about a clean install (to a portable directory for example), with just a default A500 model and no extra config, do you still get the problem?

[FrodeSolheim]

Originally Posted by FrodeSolheim

You're right, there seems to be an issue on macOS and Windows where the cursor is not trapped properly on startup

macOS: Problem is fixed and there will be a new build soon. Cursor containment fixed by creating the window with input grabbed instead of doing it right after.

Windows: There seems to be a bug in SDL 2.0.16 which causes the cursor to not be properly contained no matter what I do. Fortunately, it seems to be fixed in latest git version of SDL (I tested building it just now). Will check if I can backport the fix to SDL 2.0.16 and include in a new build, or maybe just include the latest development snapshot of SDL instead.

[DanielAllsopp]

Originally Posted by FrodeSolheim

I have not been able to reproduce it, even on a similar computer/OS (MacBook Pro/M1/macOS12). So it does not seem to be a general issue, at least. Does it always happen for you? Does the Amiga/FS-UAE configuration matter? What about a clean install (to a portable directory for example), with just a default A500 model and no extra config, do you still get the problem?

Yup, it happens every time. I've not tried it with a different configuration yet though, so I'll do that ASAP and report back.

Edit: Trying it with a plain A500 configuration and enabling the debugger does indeed work, so it looks like it's something to do with my configuration of this particular machine. The thing is it hasn't changed for months and months now... I'll investigate further.

Edit 2: So, it turns out that it was something I changed, one little character in my launch script: a lovely '&' at the end which allows the terminal the run the command in the background, similar to AmigaOS 'Run >NIL:' command. I did this because I started using the same macOS terminal to launch FS-UAE _and_ build my code when the terminal app in Atom stopped working.

All sorted now.

[FrodeSolheim]

FS-UAE 3.1.61 should fix the cursor grab on macOS. It also contains a fix for a rare crash in fs-uae-device-helper (reported by a Linux user).

The Windows cursor containment issue does only seem to occur when using display scaling in Windows settings. (e.g 150%). The problem does not occur with 100%. I haven't yet decided whether to downgrade to SDL 2.0.14, include the development snapshot, or wait until SDL 2.0.18. In the meantime, if you're having issues with the cursor hitting the right/bottom resize border of the window on Windows, you can replace SDL2.dll with the snapshot version. Download here.