WND proc not reset on DX12 hook about hudhook HOT 8 CLOSED

Nice. I’ll give it a test here in the next few days. Thanks for that!

from hudhook.

Just was able to test this. Working great! Thanks again :)

from hudhook.

Oh, that is not a hack! There may be more or less clean ways of going about it, but definitely having a destructor kind of thing is a good idea -- after all, RAII is the pattern in Rust.

Feel free to share your PR if you'd like to! Even if it didn't fit with the code style for the rest of the code, it'd still be a great contribution and would help me figure out how to get some things right in the implementation -- and I could always request changes or modify it afterwards anyway.

Unhooking has been planned for a while, just never really figured out how to get it going properly. So thank you!

from hudhook.

I noticed I am already storing the window proc in ImguiRenderer, see this; cleanup is invoked in the ResizeBuffers hook, like this: the ImguiRenderer is just taken out of the OnceCell and later on recreated.

Is this similar to your solution?

from hudhook.

The one you’re storing is the overridden one though. Not the original from the process. I wasn’t sure why you were doing that. But yes, very similar. The only difference really is I created a shutdown function, that I call from my detach, that did the same thing but with the one originally from the process. I obtained that with the get function I shared above. The unhooking and everything else was working great.

from hudhook.

How/where did you write your detach function? I tried calling FreeLibraryAndExitThread from inside the UI loop but that resulted in crashing, as the function does not return and so its whole call stack doesn't get to do any cleanup.

The one you’re storing is the overridden one though.

I'm not sure that's the case:

• Here we're retrieving the preexisting wnd_proc value: as stated by MSDN, "If the function succeeds, the return value is the previous value of the specified offset."
• Here we're storing it in the ImguiRenderer instance.
• Here we are retrieving that wnd_proc value, and forwarding non-consumed events to it; if we didn't do that, the game wouldn't be able to receive some important events at all.

from hudhook.

Oh, I didn’t realize that function returned the preexisting one. What is that cleanup function called from? It reads like resize so I’m guessing it could be called a lot. What happens if it’s called multiple times? Would it lose the original or the hooked one?

How/where did you write your detach function? I tried calling FreeLibraryAndExitThread from inside the UI loop but that resulted in crashing, as the function does not return and so its whole call stack doesn't get to do any cleanup.

I created a static mutex and condvar. I locked the mutex in my render loop and if they click the exit button I set it to true and notify all on the condvar. In my attach, I spawn a thread that blocks on the condvar. Once that triggers and the mutex is set to true then I free library.

from hudhook.

What happens if it’s called multiple times? Would it lose the original or the hooked one?

It should not be called multiple times, only in the event that there is an actual window resize. We have a lax guarantee that it will not be called twice in a row as the renderer object will be dropped afterwards, to be recreated at the next invocation of Present.

I created a static mutex and condvar. I locked the mutex in my render loop and if they click the exit button I set it to true and notify all on the condvar. In my attach, I spawn a thread that blocks on the condvar. Once that triggers and the mutex is set to true then I free library.

That's a nice approach!

In #11, I instead opted for building a function that spawns its own thread, unhooks everything and frees the library. You can call it from anywhere in your render loop via hudhook::lifecycle::eject(). I'm not 100% sure on concurrency issues but I have been testing it for a bit and found no problems with it.

from hudhook.