Odd input behaviour when assigning multiple inputs to a single button

wmd
Posts: 46
Joined: Sun May 21, 2023 9:55 pm
Has thanked: 2 times

Odd input behaviour when assigning multiple inputs to a single button

Unread post by 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
Posts: 39
Joined: Fri Jan 15, 2021 7:54 am
Has thanked: 2 times
Been thanked: 7 times

Re: Odd input behaviour when assigning multiple inputs to a single button

Unread post by 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
Posts: 46
Joined: Sun May 21, 2023 9:55 pm
Has thanked: 2 times

Re: Odd input behaviour when assigning multiple inputs to a single button

Unread post by 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
Posts: 94
Joined: Sun Aug 15, 2021 2:44 pm
Has thanked: 16 times
Been thanked: 16 times

Re: Odd input behaviour when assigning multiple inputs to a single button

Unread post by 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
Posts: 46
Joined: Sun May 21, 2023 9:55 pm
Has thanked: 2 times

Re: Odd input behaviour when assigning multiple inputs to a single button

Unread post by 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
Posts: 170
Joined: Sun Mar 07, 2021 12:28 pm
Has thanked: 31 times
Been thanked: 48 times

Re: Odd input behaviour when assigning multiple inputs to a single button

Unread post by 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
Posts: 94
Joined: Sun Aug 15, 2021 2:44 pm
Has thanked: 16 times
Been thanked: 16 times

Re: Odd input behaviour when assigning multiple inputs to a single button

Unread post by jd213 »

wmd wrote: Wed Sep 20, 2023 4:52 pm

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
Posts: 46
Joined: Sun May 21, 2023 9:55 pm
Has thanked: 2 times

Re: Odd input behaviour when assigning multiple inputs to a single button

Unread post by wmd »

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

wmd
Posts: 46
Joined: Sun May 21, 2023 9:55 pm
Has thanked: 2 times

Re: Odd input behaviour when assigning multiple inputs to a single button

Unread post by wmd »

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

pac
Posts: 76
Joined: Mon May 25, 2020 6:11 am
Has thanked: 64 times
Been thanked: 26 times

Re: Odd input behaviour when assigning multiple inputs to a single button

Unread post by 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
Posts: 94
Joined: Sun Aug 15, 2021 2:44 pm
Has thanked: 16 times
Been thanked: 16 times

Re: Odd input behaviour when assigning multiple inputs to a single button

Unread post by jd213 »

wmd wrote: Wed Nov 15, 2023 9:49 pm

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.

Post Reply