[BUG][PLAYER] Window sizing bugs

[namida]

Reported by Proxima on Discord.

a) Window size doesn't adjust when zoom is changed.
b) Default window size is too small.
c) Window size isn't remembered between sessions.

Proxima reports these happen on V12.8.X and the Jumper RC builds, but not V12.7.X.

[Proxima]

It does occur on 12.7, I just didn't notice it before because I didn't perform the sequence of actions that triggers it. (Specifically: namida has confirmed that default window size should be 320 x 160 x zoom level, but it doesn't adjust when you change zoom level, so setting the zoom level to 2x and then switching from fullscreen to windowed will make the window the smaller size.)

Regarding remembering the window size between sessions: I would only do this is there is an easy way to get it back to the default size, since it always annoys me when I resize a window by accident, and if I resize it back manually, it won't be the exact round-number size it was before. (Presumably, switching to fullscreen and then back to windowed would restore the default size.)

[namida]

(Presumably, switching to fullscreen and then back to windowed would restore the default size.)

Correct. I'd have to go out of my way for it to not do this, and I'd think if someone's making the effort to change between them regularly, they're not going to mind doing a bit of resizing while they're at it.

[namida]

Okay so, I'm not noticing anything particularly unusual here. The window sizing is preserved between sessions as expected, in both low-res and high-res. If I adjust the full screen and zoom options, no matter which order it's in (as long as it's in a single visit to the options menu), the window is suitably sized afterwards. Likewise, I notice no issues with remembering the window size between sessions. Noted that maybe this isn't always desired - will come back to this.

The window indeed doesn't change size when already in windowed mode and changing zoom levels, but that feels like the correct behaviour to me - I don't believe that we should assume that the user wants to change their window size just because they want to change how zoomed in gameplay starts at.

A "reset to default size" button should help with both (a) cases where window size remembering between sessions is not desired, and (b) if the user DOES want to change their window size based on a new zoom setting. Does anyone feel there's anything else that's needed in regards to this, or even more so, any bug case that I've overlooked (and if so - how exactly can I reproduce it, and what's the expected behaviour)?

[WillLem]

A "reset to default size" option would be great, particularly if the user can customise what the default values are.

If possible, I'd also request finer zoom options. The jump between 1, 2 and 3 is quite massive. If there's an easy-ish way to add a couple of extra increments in between each one, that would be much appreciated. (EDIT: I've created a suggestion topic for this).

[Proxima]

The window indeed doesn't change size when already in windowed mode and changing zoom levels, but that feels like the correct behaviour to me - I don't believe that we should assume that the user wants to change their window size just because they want to change how zoomed in gameplay starts at.

I've done a bit more testing, and I've discovered why I thought something needed to be adjusted.

When the mode is changed from full-screen to windowed, in high-res mode with the compact skill panel off, NL doesn't scale the skill panel correctly -- the minimap will go off the edge of the window.

All other cases seem to be handled correctly.

[namida]

Appears to be fixed as of commit 8616e85, but we'll see for sure during the RC phase. Said commit also adds a "Reset window size / position" option in the config menu.

[Proxima]

So, as we discussed in discord the other night, previous bugs with this seem to have been fixed but there is still an issue. When I change mode to windowed with 3x zoom, high res off and compact skill panel on (which are, incidentally, my preferred settings when I'm not changing settings purely to test possible bugs ), the window is the size appropriate for 2x zoom instead of 3x. The "reset window size" button doesn't fix this.

[namida]

So, as we discussed in discord the other night, previous bugs with this seem to have been fixed but there is still an issue. When I change mode to windowed with 3x zoom, high res off and compact skill panel on (which are, incidentally, my preferred settings when I'm not changing settings purely to test possible bugs ), the window is the size appropriate for 2x zoom instead of 3x. The "reset window size" button doesn't fix this.

1366 x 768, right? (I remember you saying this the other day, but just making sure in case you've switched PC / replaced the monitor / etc.)

[Proxima]

Right. I should also mention that 12.7 and previous experimentals did resize to 3x correctly; it's just the new version after fixing the other bugs that has trouble.

[namida]

I rewrote the code that determines the initial size altogether, so it might just be a difference in implementation. Here's how the current algorithm works, which would indeed be expected to produce the results you mention - though I'm open to making tweaks if desired, I don't by any means consider it "set in stone".

The window scale is calculated via the following rules (I've noted with an "HR" tag anything that's specific to high-resolution mode; if I have not made such a note, assume no difference, including that widths / heights are not scaled).

- Find the lesser of (screen width / 320) or (screen height / 200), round it down and subtract 1 from it
- Set the scale to the lesser of (the above), or (the user's zoom level) (HR: lesser of (the above), or (*double* the user's zoom level))
- If the scale is less than 1, set it to 1 (HR: if less than 2, set it to 2)

The window width is then set to 416 x the scale if using full-size panel, or 320 x the scale if using compact panel. The window height is set to 200 x the scale. Finally, the window is positioned such that it's centered on the screen.


I suspect it's specifically the "subtract 1" in the first step that's resulting in the result that you're finding unexpected. I put this here because I felt that on my screen (1920x1080), not having the -1 doesn't leave enough empty space around the sides of the window. Perhaps this could instead be addressed with a special case for 1920x1080 (or alternatively, keep the -1 and introduce a special case for 1366x768). At some point I should look at how well this works for all common resolutions, tbh, and decide from there.

[namida]

One possibility raised on Discord: Does the screen size even need to default to something that's a multiple of the "classic" size? If NL were made from scratch, rather than splitting off from a DOS clone - 320 / 416 would of course still be somewhat natural values to consider based on the skill panel's size, but 200 for height would be completely arbitrary. Perhaps a simpler formula would be better here: Figure out some border gap based on the screen's total size (perhaps 5% of the smaller dimension), and leave that much empty space each side of the window.

A counter-argument from Proxima: The existing formula will generally ensure that a 160px tall level will fill the window exactly; and 160px is by far the most common level height. Yes - 160px is only the most common because of carry-over from DOS, but this is different from a detail of DOS's UI, because this detail affects the design of many existing levels.

[Proxima]

I suspect it's specifically the "subtract 1" in the first step that's resulting in the result that you're finding unexpected. I put this here because I felt that on my screen (1920x1080), not having the -1 doesn't leave enough empty space around the sides of the window.

To be honest, I'm not understanding what you mean here. Which zoom level were you using at the time? And if this made the window bigger than you wanted, couldn't you have gotten the correct window size by setting the zoom level one lower?

[namida]

I suspect it's specifically the "subtract 1" in the first step that's resulting in the result that you're finding unexpected. I put this here because I felt that on my screen (1920x1080), not having the -1 doesn't leave enough empty space around the sides of the window.

To be honest, I'm not understanding what you mean here. Which zoom level were you using at the time? And if this made the window bigger than you wanted, couldn't you have gotten the correct window size by setting the zoom level one lower?

I'm not talking about the window size relative to the zoom level, but the window size relative to the screen size. It felt awkward to have a window that was that large, yet not outright maximized. Adding in the -1 made it a far more sensible (IMO) size.

Yes, perhaps this could in turn be resolved with a special case for my resolution, or for yours - but ultimately, I have to wonder, where do we draw the line and say "this is too complex, if you want an exact size, resize it yourself to that size"? - keeping in mind that you could achieve precision by editing the INI file that saves the size.

My resolution is 1920x1080 @ 96dpi (100% scaling in Windows Settings).

[Proxima]

No, what I'm saying is: if that's the outcome of switching on windowed mode on a 1920x1080 resolution with (I assume) 4x zoom, and you're not happy with that window size, couldn't you (under the old algorithm without the "-1") get the window size you want by setting the zoom to 3x?