Add option to disable automatic resize of main window #4011
Conversation
| { | ||
| Location = new Point(Config.MainWndx, Config.MainWndy); | ||
| if (Config.MainWndx is int x && Config.MainWndy is int y) |
There was a problem hiding this comment.
Was it necessary to make these nullable to implement this new feature? (edit: I see it's the last commit, so I'm guessing that's a no.) If you could continue using -1 as the sentinel value instead of null, I think that would be preferable. Otherwise, try Point? instead of 2 int?s.
There was a problem hiding this comment.
It's not necessary to the PR, no. I just made this change because negative values including -1 are valid window positions
There was a problem hiding this comment.
Not directly, tool window position saving is handled elsewhere
Position isn't saved anymore when minimized
| { | ||
| Config.MainWndy = Location.Y; | ||
| Config.MainWindowPosition = Location; | ||
| Config.MainWindowSize = Size; |
There was a problem hiding this comment.
To clarify for anyone else: This preserves the existing behaviour of not updating the config in the edge case where EmuHawk is closed while already minimised.
This comment was marked as resolved.
This comment was marked as resolved.
|
|
Well, I finally had to stop procrastinating to get any of this into a release before 2.10.1 in December 2025 ;) |
|
I have a few more changes that I didn't PR yet because of the merge conflicts with(out) this PR: kalimag/BizHawk@pr/disable-automatic-resize...kalimag:BizHawk:pr/disable-automatic-resize-plus Should I wait until this one is merged and open a new PR, or just push them into this PR? |
|
I don't follow. Merge conflicts with |
|
What I mean is that those changes are not strictly related to this PR, but the commits touch the same code and are based on this PR's branch rather than master. So I can't trivially open a separate PR with just those changes without (probably) creating a bunch of merge conflicts between the two PRs, and the easier option is to either have one PR (this one) containing all changes, or wait until this one is merged to open a second PR. |
…/height while this did "work", and mimicked other emulators handling internal upscaling, it was a hack, and ends up causing issue with lua padding. it is also more unneeded now that #4029 (makes the UX of a sudden "large window" more managable) and #4011 (allowing for mimicking the frozen smaller window state) are merged resolves #4039
|
Thanks, but I still can't find the new option to keep the window size:
I am using the latest |
|
|
|
thanks, that’s really helpful. Why not make it enabled by default? |
-1valueThis feature is useful for streamers who want a consistent capture size, as well as for people who want to fit the BizHawk window into a fixed layout with other windows (corner snapping etc.).
This is not the same functionality as the custom resolution in the display settings, which stretches the framebuffer to the specified size and fits the window to that size exactly.
With the feature in this PR, the window/client area stays a consistent size while automatic letterboxing/pillarboxing, integer resizing, 1:1 pixels etc. still work. This is preferable for working with multiple games, resolution changes mid-game, changing DS/WS screen rotation/layouts and similar, where squeezing everything into the same resolution is undesirable. It's also just more convenient than figuring out a resolution in the right aspect ratio and entering that in the display settings all the time.
Check if completed:
resolves #1560, #3039, and #3410