You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Warhammer 40K: Dawn of War; Displays ImGui fine if injected on launch, but if you change resolution in-game then ImGui disappears due to no trigger of a device reset.
Heroes of Might & Magic 5; If injected on launch, ImGui doesn't show up & resolution change doesn't trigger device reset
The solution could be to save the previous size & check if it changes on each frame. Since we already call get_window_rect, hopefully that is enough, but it could very well be so that the device's viewport needs to be checked as well like in the OpenGL solution.
Since this is a fairly isolated thing, I'm wondering - Is the overhead of checking the viewport basically non-existent or is it something that has to be considered?
There is also another game (don't remember which one) with a similar issue. Might even have been a DirectDraw game that I ran with dxwrapper, so I'm not too sure of the relevancy here since it may be so that there is no equivalent to Reset in those games.
The only solution I could come up with was to read for calls to WM_ACTIVATEAPP and subsequently reset the device manually from there.
WM_ACTIVATEAPP => {
if let Some(device) = D3D9DEVICE.get() {
let mut present_params = D3DPRESENT_PARAMETERS {
Windowed: BOOL(1),
SwapEffect: D3DSWAPEFFECT_DISCARD,
BackBufferFormat: D3DFMT_UNKNOWN,
..core::mem::zeroed()
};
device.Reset(&mut present_params).unwrap();
}
}
It's not the prettiest solution & would require us to expose the device somehow like talked about in #80
The text was updated successfully, but these errors were encountered:
#158 does fix the Warhammer 40K issue. Heroes Of Might And Magic 5 still have issues present. Injecting early doesn't render imgui (alt-tabbing and tabbing back make it pop up). Changing the resolution does now keep imgui window rendering, however, the game starts running at like 0.5fps, lol. This issue exists on older hudhook versions as well.
Unfortunately I do not have enough expertise in DX9 to tell what the problem might be there at all, nor significant use cases for debugging this myself. I think current implementations of DX9 are backed by DX12 or Vulkan (respectively on Windows and Wine) and so I'm not sure what could be the cause for the slowdowns. Maybe something on our end causes a botched synchronization between CPU and GPU?
The solution could be to save the previous size & check if it changes on each frame. Since we already call
get_window_rect
, hopefully that is enough, but it could very well be so that the device's viewport needs to be checked as well like in the OpenGL solution.Since this is a fairly isolated thing, I'm wondering - Is the overhead of checking the viewport basically non-existent or is it something that has to be considered?
There is also another game (don't remember which one) with a similar issue. Might even have been a DirectDraw game that I ran with dxwrapper, so I'm not too sure of the relevancy here since it may be so that there is no equivalent to
Reset
in those games.The only solution I could come up with was to read for calls to
WM_ACTIVATEAPP
and subsequently reset the device manually from there.It's not the prettiest solution & would require us to expose the device somehow like talked about in #80
The text was updated successfully, but these errors were encountered: