Closed NABN00B closed 4 years ago
These values aren't meant to be poked at manually. However, making them make sense for that would definitely be a valid feature request, so tagging as such.
The values are also saved incorrectly when you close the window. Not sure why you would consider this a feature request instead of a bug.
Unless the window drifts by closing/restarting, I don't see how it matters for the user experience unless you poke at the ini manually.
Is that on windows? I have a custom build which has options to disable titlebar and borders(to make multiplayer on same pc nicer) which also adds option to set window coords in ui and don't remember any negative offsets. Will have to check once I get back home.
So I checked and I think it's caused by actual window border size which might be different than what we can see, maybe differ by theme or/and dpi.
Here's how the upper left corner looks like on my pc using window with border which is 7 pixels wider than actual visible window(using 1080p)
And this is using borderless window(still windowed mode as I said I have that option for multiplayer on same pc, so not to be confused with borderless fullscreen)
I don't think an "offset" is by any means a "fix" for that since with sample size of 2, we already have 2 different offsets:P(for me it was 7 for X and 0 for Y).
Edit: https://stackoverflow.com/questions/34139450/getwindowrect-returns-a-size-including-invisible-borders/34143777 In short: the coords are fine, it's just that most Windows 10 themes choose to hide the 7 pixels of the border from the sides and the bottom.
The 8th horizontal pixel is the left side of the window border, which is useless to display, so our offsets are basically the same. 😛 (If the emulator is not the active window, the border's pixel will display whatever is behind the app, like the desktop background.)
I would love to use a borderless mode, the emulator doesn't run through DXWnd which could achieve me that result - and much more (eg locking size & place).
Interesting find about the W10 theme, not sure if this is fixable in this case.
Borderless is easy see https://github.com/LunaMoo/ppsspp/commit/9b0b23934a958b08e9f46ef0e66f74934a19b0a1
It sounds like this isn't really a bug then, right? The window coordinates in the ini are the ones Windows uses. Just because Windows today offsets by 8 doesn't mean it will forever.
I would definitely be against applying hardcoded offsets, and I don't think it's worth pulling theme metrics and reversing the position/size.
-[Unknown]
Right, it's not. I'm closing.
As long as I get to keep the opportunity to apply the offsets from the config file, I don't really mind.
I think as long as Windows doesn't redesign its border theme again, the offsets you have will continue to work.
What happens?
When I change the
WindowX
andWindowWidth
settings in the config file, these settings won't get applied correctly when I launch the emulator.WindowX
is offset by +8 andWindowWidth
is offset by -16. For example, to properly position the window to 0,0 with size 1280x1024 I need to apply the following values:What should happen?
The values given in the configuration file should be applied correctly (without any offsets).
What hardware, operating system, and PPSSPP version? On desktop, GPU matters for graphical issues.
Every PPSSPP version I've ever tried. Win10 x64.