Input to game completely blocked if injecting late

[Godnoken]

I've noticed that all game input gets blocked if you inject a .dll into a few games (BloonsTD6, Valheim..) late into the process, as in; the game has been up and running for a few seconds. However, if you inject it within ~ 1 second of the game launching, game input works as usual.

I'm not entirely sure that this is a problem that only occurs with the Hudhook hooks, hence why I didn't raise this as an issue for now. I'm super fresh on this kind of work and if I had to guess - it has to do with what type of input the game uses and when the game's input is injected into the game.

Any ideas?

[veeenu]

In Elden Ring and Dark Souls III I've observed pretty much the opposite -- the game crashes if you inject too early, but has no problems when injecting later.

I noticed the two games you mentioned are OpenGL, BloonsTD6 is OpenGL 2 according to its Steam store page.
At the moment we only have hooks for OpenGL 3; I don't know that API at all, so I'm not sure whether it should be backwards compatible. I'm not ruling out that the way the hook works has some problems with setting the WndProc.

It would be good to have OpenGL integration tests (see #42) to test these kinds of things but I haven't gotten around to implementing those yet because I have to learn the API first.

[Godnoken]

I'm wondering how that's even possible, if BloonsTD6 is truly OpenGL it should go nowhere near the DX11 calls. Maybe it's not OpenGL after all? 🤔 Either way, it's worth digging deeper. Do you have other games where you can reproduce that?

OyxgenNotIncluded and 0 A.D. can render IMGUI on both DX11 and OpenGL3 hooks - without changing the renderer in-game..
However, using the DX11 hook makes the input a bit iffy sometimes.

0 A.D. states that OpenGL is the backend of the game, and it is also not possible to change it to DX11. Could we assume that it is possible to use both these hooks due to these games using DX11 for one part (let's say the main menu) and then OpenGL for the in-game rendering?

[veeenu]

Having two graphics APIs seems like a super weird design choice to me. Not sure what we should do in such a case, but I'd say it would be safe to just stick with one, provided it works consistently? The fact that both work at the same time means that something is calling SwapChain::Present and the OpenGL equivalent all the time, at the same time. I don't know what to make of that, but I'm not sure it's a use case that we want to support unless we find some pertinent documentation (i.e. blog posts, etc) that proves this is an actually legit technique.

[Godnoken]

It's a strange one, for sure.

I'm mostly wondering if this somehow affects game input. Hard to tell what's going on..
It doesn't happen with Reshade in the games I've tried, but it may very well just be that DLL proxying is a much safer bet for avoiding interfering with the game?

I wish I had more experience, sucks to just be playing the guessing game 😆

[veeenu]

That makes two of us 😅

I'm not sure that DLL proxying is the thing that makes the difference with Reshade. I assume if Reshade was injected later it would behave just as well. It is much more complex and, if anything, we should study it in depth to understand what it does differently, but at the end of the day -- it's reverse engineering, the guessing game is all that we have :D

[Godnoken]

Ah, interesting. I was thinking about trying to use DLL proxying but maybe it's not worth a shot then.

Reshade is indeed really quite complicated, just wish it was made in Rust.. Having a hard time understanding the C++ syntax. It is what it is though, I hope & think I will have enough time to spend on it to eventually make some improvements.