-
Notifications
You must be signed in to change notification settings - Fork 72
[GEN][ZH] Center Game App Window on startup and resolution change #541
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 6 commits
befdc31
6a9ae12
4fc326e
966c029
7373baa
d72405a
d8aaf71
033be37
1fa513b
6ef01fa
659f87b
d798005
6bcd039
dbeb66c
f47c74e
5585646
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -371,6 +371,13 @@ void GameEngine::init( int argc, char *argv[] ) | |
#endif///////////////////////////////////////////////////////////////////////////////////////////// | ||
|
||
|
||
// TheSuperHackers @bugfix helmutbuhler 04/14/2025 | ||
// Pump messages during startup to avoid "(Not responding)" in the window title | ||
// on slower computers and in debug build. | ||
// This also ensures that the window is correctly positioned, because Windows | ||
// apparently ignores the SetWindowPos call when the window is not responding. | ||
serviceWindowsOS(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How can this problem be reproduced? I tried this on my machine with Debug configuration and I cannot get the Window to be non responding during boot with and without this change. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm, are you perhaps having a debugger attached? The buggy behavior will only occur if there is no debugger attached. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I cannot confirm that this avoids "(Not Responding)" in the window title. I tested this with serviceWindowsOS();
Sleep(10000);
serviceWindowsOS(); But it does fix the window positioning as you say. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, of course it shows the "(Not Responding)" if you put a Sleep in there :) In case you are interested. MS has a little bit of documentation about this feature: |
||
|
||
|
||
#if defined(_DEBUG) || defined(_INTERNAL) | ||
// If we're in Debug or Internal, load the Debug info as well. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment says "apparently". What does that mean? Does it ignore the SetWindowPos or not? If it factually ignores the SetWindowPos, then there should be no word of doubt in the comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, Windows behaves as if it ignores the call. Does it actually ignore it, or does the GhostWindow implementation have bugs that ignore that call, or is it some other bug? I don't know, I don't have the code. All I know is that Windows appears to ignore the call, so I think the comment is accurate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok if we do not know what Windows really does, then how about we just describe the observed issue? This way there will be no speculation.
Example: "Windows behaves as if the call to SetWindowPos never occurred".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the mistake causing this issue is inside the d3d8 wrapper setRenderDevice function. Even when passed the argument to resize, inside it's using flags for no resize and no reposition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xezon In my opinion the comment is fine as it is and means the same as your suggestion. If you feel the comment needs to be changed, can you do it?
@aliendroid1 No, the flags are correct.