Odd Input Behaviour When Assigning Multiple Inputs to a Single Button

[wmd]

I have noticed some odd behaviour with inputs on MiSTer when assigning multiple inputs to a single button. Consider these two scenarios:

R-Type
A = shot, B = fire pod, C = A (set C to autofire = 32ms). The goal of this configuration is to allow for autofire of the shot (hold C) and allow for shot to be charged when holding A. Keep C held down then switch to holding A to charge beam. Notice that A does not start charging the beam. The only way this will work is if you deliberately introduce a slight delay when physically switching between C and A, or A and C. At first I though this was perhaps an issue with autofire. But, I just picked up on something similar in Rastan Saga, that does not involve autofire (see below).

Rastan Saga
A = slash, B = jump, C = UP + B. Use C to jump onto a rope (to do a bigger jump) while up is pressed. Notice that even though up was help the whole time, your character does not continue to move up the rope. Much like the issue I describe with R-Type, you can't move up the rope unless you release all buttons / directions then press up again. It's only C that causes this, if you do a big jump normally (hold UP + B) you continue to travel up the rope as normal.

I tested these exact scenarios on MAME, and was not able to reproduce these issues. I am using an arcade stick that has a Brook Universal board in it, and used the same stick on both MiSTer and MAME.

The ability to combine inputs is extremely useful, so hope that it can be fixed to align with how it works in MAME.

[RiotRay]

Hi!

You´re experiencing pretty much what I described here: viewtopic.php?t=7111
According to the amount of responses not many people do seem to care about the issue...

But you´re right: Right now the way MAME handles it is far better

[wmd]

It would be a big shame if this goes unnoticed as it's something that MAME has nailed for decades, and is clearly undesired behaviour.

[jd213]

I've also noticed this in R Type, so I'd like to see it fixed as well.

Might be a good idea to make a GitHub issue, I assume it's more of an issue with the main MiSTer rather than any specific arcade core.

[wmd]

Yes, I assume it's a system-wide problem, but I have only tested on the two arcade cores I listed. Which repo would be best to raise this on?

[AtomicShroom]

The input management in MiSTer could use a overhaul. There's also other issues:

For example in a NES game if you hold Right on the D-Pad to move right, and while holding you press and release Right on the joystick, somehow your character will stop moving even though D-Pad right is still held. This makes no sense.

Opening the OSD while a button is pressed will cause that button to remain pressed during the entire duration that the OSD is open. For example if you're moving in a game and open the OSD, the character will keep moving on its own. This has led to quite a few unintentional deaths. Opening the OSD should release all buttons.

[jd213]

Yes, I assume it's a system-wide problem, but I have only tested on the two arcade cores I listed. Which repo would be best to raise this on?

I assume the Main_MiSTer:
https://github.com/MiSTer-devel/Main_Mi ... +is%3Aopen

Looks like there's already an issue for "Joystick direction input remains stuck if held while opening the OSD":
https://github.com/MiSTer-devel/Main_MiSTer/issues/628

[wmd]

Thanks. I've raised the issue there. Hopefully it gains some traction as I feel this is an important issue.

[wmd]

Unfortunately no one seems to care about this. Kind of mind boggling that fundamental stuff like this goes unfixed.

[pac]

For example in a NES game if you hold Right on the D-Pad to move right, and while holding you press and release Right on the joystick, somehow your character will stop moving even though D-Pad right is still held. This makes no sense.

Can you provide more details here - which game (hash), which input device.

[jd213]

Unfortunately no one seems to care about this. Kind of mind boggling that fundamental stuff like this goes unfixed.

It's possible it might get fixed at some point, but maybe it's not considered very high priority.

If you have the ability to look into it further yourself, it might help speed things along.
I'd like to help development myself, but there's not much I could do other than translate Japanese tech docs, and I'm already pretty busy.

[deepthaw]

I'm working through a fix myself to submit. Can anybody tell me other weird situations where this has shown itself?

[RiotRay]

@deepthaw

Weird situations? I wouldn't call the whole input system of the mister "weird", but it's inconvenient when mapping several physical buttons to a virtual one. The fact is, that you have to release the first button in order to have the second button press recognized by the mister. That breaks gameplay somehow if you want to charge the "beamshot" in R-Type for example. In Mame the secont button press "overrides" the first one and you can keep having pressed both buttons while charging up the "beamtshot". I think this should be implemented on the mister too....

[deepthaw]

@riotray check the latest unstable release, my pr to fix this got accepted. Embarrassingly I couldn’t figure out how to implement the Rastan mapping you use so I couldn’t test that but it’s working in r-type, esp.ra.de and others now.

[RiotRay]

@deepthaw

I'm sorry...but could you point me to this please?
thx

[FPGA64]

@deepthaw

I'm sorry...but could you point me to this please?
thx

https://github.com/MiSTer-unstable-nigh ... 630_072bdd

[deepthaw 2024-06-30 2bdd35c]
Change in handling overlapping button presses (fixes issue #824)

• Modifications to input handling to prevent held inputs from being
  overridden by an alternate input mapped to the same button.
  i.e. R-Type holding fire to charge special shot will not be
  disrupted if a secondary fire button is pressed, autofire
  or not.

• Modifications to input handling to prevent held inputs from being overridden by an alternate input mapped to the same button.
  i.e. R-Type holding fire to charge special shot will not be
  disrupted if a secondary fire button is pressed, autofire
  or not.

• Prevent held inputs from being disrupted by alternate inputs.

i.e. in R-Type, if holding the fire button to charge a special shot,
tapping an alternately assigned fire button will not cause the charge
to stop.

[deepthaw]

that commit message is awful because i am terrible at GitHub but at least it makes clear what it does.

[RiotRay]

@deepthaw

Just tried your mister beta. It's working fine and the way I expected it to do. Unfortunately it's not working with "groovyMister".
Could you compile one that does both?

[deepthaw]

I'm not sure how to do that, I pinged @psakhis on discord to see if they can help.

[psakhis]

I will build next MiSTer_groovy with last changes

[deepthaw]

@deepthaw

Just tried your mister beta. It's working fine and the way I expected it to do. Unfortunately it's not working with "groovyMister".
Could you compile one that does both?

@psakhis has added these fixes to Groovy.

https://github.com/psakhis/Groovy_MiSTe ... s/20240712