-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Game input not registering correctly #79
Comments
Is this something you noticed when you built the DX9 renderer @FrankvdStam? |
Double rending was fixed. Only issue I know of that I didn't fix has to do with scaling/mouse positions. What you're having seems more like a race condition, where the WndProc hook is not always installed at the right time. My guess would be to inspect the initialization steps carefully, maybe add some logging to steps to figure out if something is crashing and burning, causing the hook to not be installed sometimes. |
Hmm, okay, interesting. I will start there. However, just to be clear - Game input isn't completely dead, it's just that sometimes input doesn't reach the game, and these messages always log in the same games. This happens with the example hooks too, so it's not on my end at the very least, unless it is hardware related. I'm starting to understand how all of this works but I'm still miles from being able to make good educated guesses, so really - any input is super valuable! |
Oh. Here's an interesting one.. Disabling Steam overlay fixes the game input on Shelter2 & Car Mechanic Simulator 2015 (both DX9), while Niche (DX11) still breaks. |
That log message shouldn't really be an error -- we make no assumptions over whether the game should run the wnd proc or the hooked function first, the global mutexes are just there for synchronization and I think this should be expected to some degree. With that being said, this could either be a race condition or some mistake in our wnd proc code that eats up inputs instead of forwarding them to the game. We should probably gather a collection of easily accessible games and build tests for them, but right now I don't really have the bandwidth to take care of it -- it's been a pretty hectic couple months, hopefully it'll get easier soonish. |
Had this same issue. This is basically correct #104 (comment) Made some hacky changes that work for my use-case https://github.com/camas/hudhook/tree/input-issue-hack |
That's great news! Thank you for reporting this. Considering it's a synchronization issue, we at least now know where to intervene. I think the current code is too mutex heavy and we could use lighter weight synchronization which should hopefully solve the issue. |
After #143 render and wnd_proc are on different threads so can try locking at the same time. wnd_proc quicker so more likely to fail, but when render does it crashes. Doesn't seem to be happening for you though so maybe I'm missing something Still not sure why it wasn't originally working either. Can't remember if wnd_proc actually was coming from a different thread like I mentioned before. From what I can tell it should always be the main one. personal todo list: check why the older version didn't work. see if raw input or attachthreadinput could be useful |
GWYF works for me without crashing. I tried to run your project, though, and with it I'm getting crashes as well immediately, both with your branch and Could you try checking out event viewer to confirm it's an issue with |
Haha, yeah it breaks every time gwyf updates and I've been lazy. To test before I was skipping any initialisation and just showing the imgui demo window. Reproduced again today with the simple_hook example and the first dll injector google gave me. Takes a while for the render lock to fail. Seems more likely to happen when cpu is maxed. Getting wnd_proc fails before render failed too. Clicks not going through etc. Put a breakpoint on where try_lock fails internally and you can see the two threads. breakpoint hit when wnd_proc lock fails other thread paused in render |
Mmm, I'm a bit hesitant to use channels and process events out of band because I'm afraid that might introduce weird undebuggable input issues. It's peculiar that the breakpoint stopped the other thread right in the middle of |
I was being dumb. Same issue. Render and WndProc have always been on two different threads. Agree that wnd_proc probably shouldn't hang. Created an example using channels to queue input changes which are then resolved before rendering. Seems to work without crashing or missing input. |
Can you try spamming keyup/keydown very fast with autohotkey a given number of times while in a textbox and see whether the correct number of characters is typed? I think not because if more than one keyup-keydown pair gets consumed at the same time updating imgui's input will show only the last "event" (a misnomer as it only has last frame state, really) as the ones in the middle get overridden.
I think if the rendering is happening on a separate thread anyway you'd most likely want to properly synchronize the resize and have it happen before the render is started, otherwise there could be frames in flight on the gpu and the command queue would most likely complain.
I think that should definitely stay, as a simple call at the beginning of the function. If anything, it's the user's responsibility to not hog the proc. if the user doesn't implement it then it'll get inlined as a noop anyway. I don't think it's necessary to introduce a breaking change for that. An acceptable breaking change could be to listen for a return value to choose the next action (return lresult, call DefWindowProcW, call old wnd proc). |
There's an issue with game input that pops up in some games, seemingly primarily DX9 games, although I have had limited possibilities to try lots of games with the other renderers.
Basically, input sometimes registers fine, and other times not.
The "WndProc called before hook was set" log from the imgui_wnd_proc function always show up in the games where this happens.
I'm not sure what the cause of this is yet. I'm going to investigate further and I'd be happy if anyone knows anything that'd help.
The text was updated successfully, but these errors were encountered: