veeenu / hudhook

A videogame overlay framework written in Rust, supporting DirectX and OpenGL
MIT License
209 stars 30 forks source link

need ways to filter certain windows message, without blocking everything #182

Closed ruby3141 closed 6 months ago

ruby3141 commented 8 months ago

My payload uses should_block_message() to prevent propagating keyboard input to game when my overlay should handle one. For my target game there's no problem about that (It seems the target only uses wndproc to get keyboard event).

Recently I tried to use imgui-rs hello_world example window as a test rig for my overlay UI, and quickly got into trouble.

Turns out the example program uses WM_PAINT message as render logic entry. For that situation, if should_block_message() got set, next frame will be unreachable. (Filter and unsafely send message back on on_wnd_proc() approach is impossible due to that.)

Since current "block them all" thing seems very limiting and dangerous in some cases, I think we need other approach.

veeenu commented 8 months ago

The example program you are targeting is hardly a supported use case. As you yourself mention, games don't rely on WM_PAINT because that's generally intended for desktop applications (see documentation).

WM_PAINT generally happens as a consequence of interaction whereas games will render their frames continuously and will flat-out ignore it. For this reason, should_block_messages is going to get invoked every frame unconditional of incoming messages. The current asynchronous messaging design relies on this assumption to minimize the computations happening in the window procedure.

If you have an alternative design to suggest, that can selectively block messages without introducing too much overhead, feel free to share that through a pull request!