Restore contoler mapping behavior from previous version?

[Tasosgemah]

I noticed that in the new 0.9.8 version, you can no longer change the device from the quick menu/controls anymore. instead, you can only do these changes through the DOSBox Pure start menu/remapper.

However this feels like a regression. Before, you could load a game and then do the changes you want and test them in real time and then save a remap file, just like every other core. But now you have to restart the game so you can go the the start menu and make your changes from there. And i'm not sure how you can save these per-game (didn't go that far, i restored the core to an older version after that).

IMO, this isn't an improvement but an inconvenience compare to the previous version.

Is it possible to be able to change the devices, like enabling mouse through the analog sticks, through the quick menu/controls like before?

[schellingb]

For years I told myself that using the controller device feature of libretro in its fullest was the correct way to go. But the way this is implemented in RetroArch never worked great for me. Unless a user fully understands RetroArchs complex configuration capabilities (storing separate per-core or per-content controller configs) having multiple devices ends up messing with other cores. I switched to a "Mouse" config in DOSBox and it ended up being set to "SNES Mouse" in a SNES core or something. So by default in RetroArch, switching the device in one core affects settings of another core. I found this most annoying.

If you look at the Documentation you can see it says:

To open it (Gamepad Mapper), select "CONTROLLER MAPPER" in the start menu or click the "PAD MAPPER" button in the On-screen keyboard.

So it is always available during the game. Unless you disable the On-screen keyboard.

Gamepad Mapper settings are always stored per game, there is no option to have a different core-wide setting anymore.

Btw. the default mapping is now "Generic Keyboard". Before, the default input device was a "Gravis Gamepad", which was the default because it was closest to "RetroPad". But this meant by default DOS was told there is a joystick plugged in. This caused a few games like Tomb Raider to be unplayable by default (because it constantly scrolls the menu when DOSBox reports a joystick). This was unfixable in RetroArch because RetroArch only tells the core about what device type is selected AFTER the game starts. So at game start the core had to assume it is in its default settings (Gravis Gamepad) and only after startup (after starting the game) it would realize the user had switched to something else. Now that the core manages the preset and mapping itself, this is no problem anymore.

Personally I think all this is better for usability. Having no option to infect other cores (which was the default!). Having no option to have the mapping be core-wide (makes no sense, pretty much all DOS games are controlled differently).

But we can talk about it. Maybe there could be a core option to bring back the old behavior which presented 13 available device classes and subclasses to libretro. I'd need to figure out how that would play nice with the new preset selection in the mapper. Maybe such a core option would just disable the in-core gamepad mapper.

[Tasosgemah]

Unless a user fully understands RetroArchs complex configuration capabilities (storing separate per-core or per-content controller configs) having multiple devices ends up messing with other cores. I switched to a "Mouse" config in DOSBox and it ended up being set to "SNES Mouse" in a SNES core or something. So by default in RetroArch, switching the device in one core affects settings of another core. I found this most annoying.

I'm not sure how you ended up with this behavior. The separate "per core/directory/game" settings ensure each core/directory/game" works in it's own sandbox basically. And when you change the controls via the "quick menu" it can only ever affect the current core you are running.

RA has two areas where you can change the controls, the main "input" menu where it affects the general "retropad" and the controls settings in the "quick menu" where it affects whatever core/game you are running like i already described above. The main "input" menu affects everything (the general retropad) so were you fiddling with this when you tried to change a specific game's controls?

I run 75 systems with RetroArch and i never had a "per game" or "per core/directory" config spill to an unrelated core, as long as i only fiddle with the options in the "quick menu".

If you look at the Documentation you can see it says:

To open it (Gamepad Mapper), select "CONTROLLER MAPPER" in the start menu or click the "PAD MAPPER" button in the On-screen keyboard.

So it is always available during the game. Unless you disable the On-screen keyboard.

Gamepad Mapper settings are always stored per game, there is no option to have a different core-wide setting anymore.

Yeah, i think i figured out how this works now. Though this makes me wonder, are the pre-configured per game auto-configs still a thing? This was a pretty great feature for this particular core. Do they still work with this new behavior? Also, do the old saved remaps work? Maybe some of them? Or maybe it's best to delete them all and start from scratch?

Edit: Ok i see, if a pre-configured remap file exists it appears in the remapper as an option. In this case, the old remap files do work (i tested with a few games). Still need to re-configure the ones that don't have one though.

[InterClaw]

I'd also like the possibility of switching back to the previous behavior. Restarting to change the settings is a hassle. And enabling the on-screen keyboard has the problem of being hardcoded to L3. I'd like to use this button for other things. If it would be possible to use another hotkey for the on-screen keyboard, then I could work around it by binding that key to another layer on the controller (e.g. PS+L3 could be some function key or whatever and then map that as the on-screen keyboard button).

While one benefit of the new approach is that you can now bind more than one control to a single button, I can accomplish this by mapping more than one port control to the same controller device. I have both "Port 1 Controls" and "Port 5 Controls" set to the same device. And then in the game remappings set "Port 1 Controls" to for instance "Control both DOS joysticks" for the main controls and "Port 5 Controls" to "Custom Keyboard Bindings" for any additional keyboard keys needed that are not available otherwise, or if I need a button to do two things (I use these mappings sparingly).

I also found a problem with the new bindings. The left stick also sends D-pad input. So if you map the D-pad to something else than movement, moving the left stick also performs the D-pad actions. This is with "Analog to Digital Type" set to "None" btw, and all but "Port 1 Controls" set to disabled. (This kind of reminded me of what I reported here. Perhaps it's due to the same underlying problem? That there is hardcoded D-pad input for the left stick somewhere...)

I do agree that it takes a significant amount of time to fully grasp how controller mappings work in RA, it is ultimately pretty powerful in what you can do. I can understand the thinking to simplify how RA works here, but in doing so it in someways also gets worse, since it causes overal fragmentation.

Where are the new gamepad mappings stored btw? They don't seem to go into the regular .rmp files.

[schellingb]

@Tasosgemah You're right, in latest RetroArch I'm unable to have the device changed in one core affect another core. But I'm also unable to change the device and have it stick for the next time I load the core unless I go into Manage Remap Files and manually save a remap file. I'm quite sure that didn't use to be the case.

Besides worrying about the default RetroArch behavior (how it can be hard to grasp for especially new users) I have the following issues with the input handling:

• For a DOS core control customization should always be per game, without the need to press "Save Game Remap File" on every game
• Unable to provide more than 24 mappable actions (we have 130)
• When having a keyboard device class we can't map anything but keyboard keys
• When starting the core, it is impossible with RetroArch for the core to know what device type is selected, this is only told later after startup (because in RetroArch the input driver only starts up shortly before the video driver does, which both do much later after core startup).

The first problem is certainly the smallest, up until recently I just accepted it as part of the overall hurdle to use RetroArch, where there is some learning curve for new users to get used to how input is handled.

The latest problem is what breaks games like Tomb Raider, there is no way to fix this with the old system.

The remaining issues were reported here as soon as I released the first version of the core. It is the whole reason why the in-core gamepad mapper was added in version 0.9.0. To enable customization beyond the capabilities given by libretro. As soon as that went in requests came in to allow remapping of controller ports besides just the first as well as the ability to remap the on-screen keyboard button. All this is now implemented in 0.9.8.

@InterClaw Assigning 2 ports to the same device is an interesting approach, that has not occurred to me. Does the RetroArch menu hint in any way that this is a perfectly feasible way? Maybe it's just luck that this works at all :-)

I'll look into the D-pad stuff.

Ever since the Gamepad Mapper was introduced I was annoyed of there being 2 ways to do many (but not all) input settings. Unifying that fragmentation was resolving a bunch of usability issues and complexities in code. But I understand that users who are used to the RetroArch way of remapping - and who are happy despite its limitations - would want the old way back. I'll see if I can reintroduce it without needing too many hacks in code. The issue with the old way of not knowing if a DOS joystick should be presented to an auto-starting game or not is real though, I just don't know how to deal with that one...

The Gamepad Mapper config goes into the save ZIP, into a file called PADMAP.DBP.

[InterClaw]

Assigning 2 ports to the same device is an interesting approach, that has not occurred to me. Does the RetroArch menu hint in any way that this is a perfectly feasible way? Maybe it's just luck that this works at all :-)

It kind of is, yes. 😄 I got the idea from here. It seems only odd numbered ports work for this, because why not. I guess this workaround solves the 24 mappings lmitation above, since you can define whatever keyboard key you need on a button on the second port. I use it for games like Descent where you have a lot of stuff to map.

I'll look into the D-pad stuff.

🙏

I'll see if I can reintroduce it without needing too many hacks in code.

That would be highly appreciated for sure! Otherwise, the D-pad thing is the main blocker for me to be able to fully adopt this new concept. The hardcoded L3 button for the on-screen keyboard is a bit annoying, but I can always turn it off after having set up the controls initially to get the pure L3 button back.

The Gamepad Mapper config goes into the save ZIP, into a file called PADMAP.DBP.

Ah! It seems 0.9.7 also reads this file, huh? Because I went back to 0.9,7 and put my original .rmp files in \config\remaps\DOSBox-pure, but still got weird mappings in the RA menues. 😱 Now I know why, hehe.

[schellingb]

@InterClaw Hey there, I cannot get the D-pad thing to happen. For testing I created a custom mapping like this: And tested in the command line. Correctly, the left stick only typed "A" while the D-pad only typed "L".

Maybe this is a side effect due to using the same device on multiple RetroPad controller ports?

[Tasosgemah]

You're right, in latest RetroArch I'm unable to have the device changed in one core affect another core. But I'm also unable to change the device and have it stick for the next time I load the core unless I go into Manage Remap Files and manually save a remap file. I'm quite sure that didn't use to be the case.

I don't think it has to do with RA being a later version. The override hierarchy works at least since the first time i used it many years ago. I'm gonna say your "spilling" issue was a user error/misconfiguration but since i don't know many details i can't be 100% sure.

And yeah, saving a remap file for a core/directory/game was always the way to have separate controls per core/directory/game from the default. I don't know why that seems like an issue in your view. Basically the manual remap file does the same thing as the "PADMAP.DBP" in the new approach. The difference is that the later gets saved automatically. But i think there is a way for RA remaps to be saved automatically as well. Though i prefer the manual way so i can fiddle with the controls and test whatever i want without fearing it will mess with my last good remap. With the new approach the automatic save means you always have to be careful to not mess your last good config and revert any changes you made so they don't get saved.

I'm also curious about your issue with Tomb Raider. Because to me it looks like something minor. When i start the game i do get that auto select bug but it only lasts for a couple of seconds. Also, i made a remap for this game that doesn't even do that at the start so from my experience at least it doesn't look unfixable.

Anyway, i think i don't have any other arguments about the new approach now that i got how it works. It's fine for me. Or at least i didn't bump to any other problems from the few games i tried to map. I didn't try too many games though because i had to revert to 0.9.7 anyway due to the soundfont issue i posted.

[schellingb]

I'm also curious about your issue with Tomb Raider. Because to me it looks like something minor.

Tomb Raider (at least the 3dfx demo) is missing some form of joystick calibration and when running it in any version of DOSBox (I tried many) it always forever scrolls the main menu to one side if DOSBox is configured to present a plugged in joystick. Because it non-stop scrolls the menu, it is unusable and the game can't be started.

In DOSBox Pure the core decides to present a plugged in joystick if the controller mapping has any DOS joystick actions mapped. In 0.9.7 the core would have no way to know whether the user has a device type set that has joystick actions mapped or not until late during startup.

When a game that checks for a DOS joystick on startup and it is set to be auto started, the game will check for the DOS joystick before the core knows what device type the user has selected.

That is the conundrum. It can't be solved with how RetroArch does the core startup sequence (which is core first, later video and input). It makes Tomb Raider unplayable, but other games that check for a joystick on start are affected, too. The only solution would be to add an ugly core option ON TOP OF the device type selection.

Another not-great solution would be to delay auto start so we can wait a few frames until we know RetroArch is done starting up. This is also not acceptable because we want to tell the frontend the game's resolution so that with auto-start the correct resolution is set at the very start.

Basically the manual remap file does the same thing as the "PADMAP.DBP" in the new approach

We have had PADMAP.DBP since 0.9.0, it was requested all the way back a few days after the core was released in #57.

[InterClaw]

Yes, maybe a side effect. I'm not sure how to reproduce the effect. But when I deleted the .rmp file and restarted the core and set it up again the problem went away.

The second port does interfere in the sense that I get the port 5 mappings as well. But disabling that pad in the RA menues for the game took care of that. 👍 I do however think that "disabled" should be an option in the gamepad mapper also (and to be able to control the analog to digital setting as well) if it's going to be a true replacement of the native RA menues.

Another problem I discovered with 0.9.8 (which I should maybe create a separate issue about) is that the L2/R2 triggers are always only digital, even if you map one of the four axes to them (Joystick 1/2 X/Y). This was not the case under 0.9.7. Is this a known problem?

[schellingb]

@Tasosgemah @InterClaw Please try out 0.9.9. The control selection in the frontend is back again. It should map to the same devices as were in older versions so hopefully any override control configs made in 0.9.7 and before should work again. When selecting one of the fixed controller presets in the frontend, the in-core gamepad mapper will be disabled and show this message:

Gamepad Mapper is disabled for this controller port Set 'Use Gamepad Mapper' in the Controls menu

Please give it a try and report back, thanks.

[Tasosgemah]

Works like you are describing except i'm not sure about how previous remaps should work. I tried Normality where i made some specific changes and my old remap didn't work at first, i had to go to the frontend control options and change it to the new [Pad Mapper] option, which then made my old remap work. So the new option made the old remap work, is that how it's supposed to be? If yes then it works OK.

Another thing i noticed is that the D-Pad no longer works in the DOSBox-Pure menu when i load a game. I have to use the analog stick to make a selection.

Edit: Seems like the reason the D-Pad doesn't work in the DosBox-Pure menu is because it depends on what the specific game controls are. For instance, in Quake, the D-Pad is not mapped to the arrow keys so it also doesn't work in the main menu. In other games where it does, the D-Pad also works in the main menu.

I think the DosBox-Pure Menu should be independent like before, and not rely on whatever random control scheme any specific game has.

[schellingb]

So the new option made the old remap work, is that how it's supposed to be? If yes then it works OK.

Yeah, as of now that is how I implemented it. Before the in-core Pad Mapper could overwrite any thing selected in the frontend. That seems a bit confusing to me, a user might forget about customization (or make it by mistake) and then any change to the control setting in the Quick Menu would be ignored with no warning. So now the default "Pad Mapper" device is the only one that can be customized in the in-core mapper. If selecting a different device in the frontends control settings it will disable the Gamepad Mapper. I can see it being a bit confusing/annoying for users with existing customizations but I think it's best for new users.

Another thing i noticed is that the D-Pad no longer works in the DOSBox-Pure menu when i load a game. I have to use the analog stick to make a selection.

Yes, that was a bug that was introduced when I added support for analog triggers mapped to analog functions. I fixed this a day after the 0.9.9 release and pushed that to the RetroArch online updater. So it is still 0.9.9 but the bug is fixed when downloading the latest version of the core with the online updater. I probably should put up new builds on GitHub, too...

[InterClaw]

I tried this out now in the 0.9.9 version downloaded with the core updater. Went straight from a 0.9.7 setup, so remaps etc. where based on 0.9.7 and had not been intereferred with by 0.9.8.

Works straight out of the box with 0.9.9 now. It respected my preexisting configurations with other device types, typically "Both DOS Joysticks" on port 1 and "Custom Keyboard Bindings" on port 5 (getting input from the same physical controller to both RetroPad 1 and 5 as mentioned before. 😉)

This is awesome to be able to retain what we had. But I will also experiment more with the new "Use Gamepad Mapper" that will override it. Best of both worlds! I love how you decided to implement this. 😍