[Feature Request]Keyboard Input Optimization "Missing down input on half circles?"

[dsafkj]

With keyboard-like half-circle (← ↙ ↓ ↘ →) inputs, ↓ is often missed.This is because if you input ↓ and ↘ in one frame, the game will only register ↘. I have recorded slow-motion videos to prove this, players do indeed input ↓. We can also check these two posts: https://steamcommunity.com/app/348550/discussions/1/2974027084060516547/ https://www.zhihu.com/question/55762884/answer/146343131

This is a widespread issue, some modern fighting games make minor optimizations for it. Unfortunately, retro games can no longer be updated.

So I sincerely suggest making some optimizations, such as adding ↓ between ↙ and ↘—A retro game battle platform called gotvg does it this way, though I’m not sure about the exact code. This wouldn’t give keyboard players any unfair advantage. Coincidentally, I noticed there’s an unused feature “input plugin.” Isn’t it meant for something like this? 😂

[barbudreadmon]

Duplicate of https://github.com/finalburnneo/FBNeo/issues/1769 Those optimizations already exist for several emulated arcade boards (cps, neogeo, pgm, ...). I can only suppose you are using an outdated version of our emulator, or are talking about boards where the necessary support code wasn't implemented.

This is where you download the latest FBNeo version : https://github.com/finalburnneo/FBNeo/releases/tag/latest

[dsafkj]

I’ve already read this issue, and these are two different problems. The issue you posted can be solved with a neutral device (SOCD-clean, ←+→=none, ↑+↓=none). What I’m referring to can’t be solved with SOCD neutral or emulated boards . Could you please take another look？

[barbudreadmon]

Read the issue again, specifically that message : https://github.com/finalburnneo/FBNeo/issues/1769#issuecomment-2096369184

[barbudreadmon]

To be clear, the current implementation behave as explained in https://github.com/finalburnneo/FBNeo/issues/1769#issuecomment-2099781415

[barbudreadmon]

Ok, i think i misunderstood. What you want is an assist mode where we predict what the user wanted to do and inject additional inputs in-between. Tbh i'm not that much interested in this.

[barbudreadmon]

Also, it should be almost impossible to do an half-circle with current implementation without down being registered alone at some point, let's dissect this :

1. player press left => game recognize ←
2. player hold down while still holding left => game will recognize ↙
3. player either stop holding left or start holding right => game will recognize ↓
4. alternatively to (3), player stop holding left and start holding right in the exact same frame => game will recognize ↘ without going through ↓ first <= that's your issue
5. player does unfinished business from (3) => game will recognize ↘
6. player stop holding down => game will recognize →

Again, i'm not that much interested in adding more workarounds to this, especially since that (4) seems extremely hard to produce. The current flow seems like a sufficient help.

Edit: tbh, that (4) is something that is just as likely to happen with sticks and pads, and has always been part of the gameplay.

[barbudreadmon]

I ended up having this on the back of my mind for the whole day, thinking it could be fun to have some sort of "easymove" mode you can enable for those games (i never had success with zangief's 360/720 because i'm too bad at this), but that seems tricky :

• you'd have to identify all gameplay inputs belonging to a single player, which isn't as obvious as it might seem (as far as the backend code is concerned, inputs are just inputs)
• everytime a diagonal is pressed, you'd want to check whether a neighbor diagonal was pressed in the previous frame
• from then on, if that's the case you'd want to :
  1. replace the input for the current frame by the cardinal direction bordering those 2 diagonals
  2. delay currently pressed diagonal and all following gameplay inputs for that player by 1 frame
  3. keep buffering/delaying new gameplay inputs from that player as long as his "gameplay input buffer" has not been entirely emptied
  4. have cumulative checking/buffering (zangief's 360/720 could end up having several frames of delay)
• you'd also need to make all of this savestate-friendly for the sake of several features

Is it even safe ? Maybe there are games that don't want this, maybe there are games where the cardinal direction needs to be pressed for longer.

Imho, let's not tinker with what is inherent to the gameplay of those games.

[dsafkj]

Thank you for the response!

I just wanted to speak up for keyboard players—they aren’t making physical mistakes, yet they’re being punished. This is a major pain point that many people don’t understand. I’ve spent quite some time digging into this issue.

But you’re right. It seems technically difficult to solve elegantly. This isn’t something that should be addressed on the gamepad firmware or by emulators; instead, it should be handled within the game itself. For instance, in SF6, even if your half-circle input misses ↓, Manon’s command grab still comes out.

[barbudreadmon]

I just wanted to speak up for keyboard players—they aren’t making physical mistakes, yet they’re being punished.

Well, again that's something that is just as likely to happen with controllers. I'd even wager that joypads are the most affected by this, considering you need some very precise timing with a keyboard to stop holding left and start holding right in the exact same frame, while that's mechanically easy to do with a joypad.

[dsafkj]

I'm not a pad player and I tested it. It does happen a lot.