Closed zass30 closed 2 years ago
Does it still happen if you enable "Always process keyboard input" ? It seems this behavior is intended if that setting is disabled.
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..
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,
it seems the user is using an unsupported fork, he'll have to confirm his issue is actually happening with official fbneo
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,
I tested in Fightcade's FBNeo, and the bug does indeed happen in it.
I tested in Fightcade's FBNeo, and the bug does indeed happen in it.
Thanks for testing and confirming @dinkc64 !
@JordiRos do you know about this bug?
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.
@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,
Thanks dink, maybe it was fixed somehow after the Fork, or we changed something else, Thanks for the heads up
closed because doesn't involve fbneo-main
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