Keyboard inputs not read correctly after load state

[zass30]

If you save a state and then load it using the standard load and save state hotkeys, keyboard input will not be read until buttons are released.

I originally thought this was a bug in peon2's fbneo-training mode, and filed this as an issue under that repository, but he has investigated and determined that the problem lies in the fbneo code:

https://github.com/peon2/fbneo-training-mode/issues/94#issuecomment-1223108538

I've created a youtube video with a step by step repro:

https://www.youtube.com/watch?v=GhN7HS9oicU

[barbudreadmon]

Does it still happen if you enable "Always process keyboard input" ? It seems this behavior is intended if that setting is disabled.

[dinkc64]

Hi, I know about this bug, I just never looked into a solution. Let me dig a little.. [little digging later..] The bug I'm thinking about is similar but not the same, pausing and unpausing the emulation forgets the keys. hmmm.... let's see..

[dinkc64]

Things I've noticed (I'm just taking notes here, trying to figure this out): 1: "case MENU_STATE_LOAD_DIALOG:" is for the load state "File Dialog", the one to load a state is scrn.cpp #1331 "case MENU_STATE_LOAD_SLOT:", which doesn't call InputSetCooperativeLevel()..

2: "rbff2" (neogeo), the problem doesn't appear to happen in this game

2: "sf2" I can't get the problem to happen here either? I made a state where p1 and p2 are standing, set the state load key to semicolon. I press and hold down (END), then press semicolon to load state. Player 1 kneels down after loading the state, which is a different effect from your video above?

Appears to work the same with the lua training script loaded or not. Maybe I'm missing a step?

best regards,

• dink

[barbudreadmon]

it seems the user is using an unsupported fork, he'll have to confirm his issue is actually happening with official fbneo

[dinkc64]

zass30, can you please check to see if this happens with our official fbneo, latest binaries are here: https://github.com/finalburnneo/FBNeo/releases/tag/latest

best regards,

• dink

[dinkc64]

I tested in Fightcade's FBNeo, and the bug does indeed happen in it.

[zass30]

I tested in Fightcade's FBNeo, and the bug does indeed happen in it.

Thanks for testing and confirming @dinkc64 !

[dinkc64]

@JordiRos do you know about this bug?

[fightcadedev]

The root problem is that DInput keyboard device won't detect keyboard values that were pressed before an Acquire (that either is intentional or a bug, but it's at driver level so can't be fixed) FBNeo seems to trigger a SetCooperativeLevel when things change (change focus, load state, some more), and that triggers an Unacquire / Acquire to the keyboard. Ideally I would review the SetCooperativeLevel calls and maybe do not call on some of these cases, but someone with more FBNeo codebase would know better. A safer easy fix we will apply is to remember the Foreground value on all keyboard SetCooperativeLevel calls, and only do acquire/unacquire if we are really modifying the cooperative level (ignoring exclusive mode as Keyboard never uses that)

inp_dinput.cpp

int setCooperativeLevel(bool exclusive, bool foreGround)
{
    if (keyboardProperties[0].lpdid && keyboardCooperativeModeForeground != foreGround) {
        keyboardCooperativeModeForeground = foreGround;
        // Do unaquicer/acquire etc

That fixes the issue, but I don't know if that will have other side effects. With this fix, you can even change focus (ALT+TAB) and keys will still be read when you get back to the game after regaining focus.

[dinkc64]

@fightcadedev, I probably should have made this clear earlier: this problem doesn't happen in this branch of fbneo, only in the fightcade version - which is why I'm letting you know :)

best regards,

• dink

[fightcadedev]

Thanks dink, maybe it was fixed somehow after the Fork, or we changed something else, Thanks for the heads up

[dinkc64]

closed because doesn't involve fbneo-main