Unexpected DirectX9 behavior
Alex141642 opened this issue · comments
Hello,
First of all, thanks for this library!
I am opening this issue because the DirectX9 hook does not seem to be behaving correctly when the PC stops rendering the window.
When rendering on the window is not possible, such as:
- Pressing ctrl+alt+del
- Window changing resolution
- Screen going into sleep mode
This causes an error on hudhook:
ERROR hudhook::hooks::dx9 - Render error: Error { code: HRESULT(0x8876086C), message: "" }
This error appears to be caused here: src/renderer/backend/dx9
: self.render_draw_data(draw_data)?;
Once the error has occurred, the main window no longer updates, leading me to believe it is a panic.
When testing with openGL, it works as expected.
Here is the code for the menu:
pub struct Menu {}
impl Menu {
pub fn new() -> Self {
Self {}
}
}
impl ImguiRenderLoop for Menu {
fn message_filter(&self, io: &hudhook::imgui::Io) -> hudhook::MessageFilter {
let mut filter = MessageFilter::empty();
let pos = io.mouse_pos;
if pos[0] > 0. && pos[0] < 420. && pos[1] > 200. && pos[1] < 600. {
filter = MessageFilter::InputMouse;
}
return filter;
}
fn render(&mut self, ui: &mut Ui) {
ui.window("Demo")
.movable(false)
.position([0., 200.], Condition::FirstUseEver)
.size([420., 400.], Condition::FirstUseEver)
.resizable(false)
.build(|| {
ui.text("Hello world")
});
}
}
Do you have any idea what might be causing this?
I made a draft PR wich seems to prevent the menu to disapear. Hower the code is ugly and not fully fonctional.
Thank you! I briefly checked the PR out and I wouldn't say that the code is ugly at all. I am not sure naming wise whether "reset" is the correct semantics and whether WM_ACTIVATEAPP
should be handled for other renderers as well. For these reasons I wouldn't add an element to the trait before thinking it through, but overall I think it's a good start.
Hi @veeenu
After a lot of try, i can't find a way to make it work properly.
I tried with differents DirectX libs i found (c/c++/rust), and they all have the same behavour.
Edit: I just noticed you reviewed the initial PR i made. What should we do about it?
Might that behavior depend on the implementation of the host application? Can you reproduce the behavior with a different dx9 application? If we confirm that the behavior is application dependent, I wouldn't upstream the change, as the aim of the library is staying generic. But if we discover the opposite, I'd go ahead and adjust and merge the PR.
I'll take a look