Skip to content
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

SDL Regression - Wrong Fullscreen Resolution Chosen at High DPI #2699

Closed
2 tasks done
BreakPoints opened this issue Jun 6, 2023 · 8 comments · Fixed by #2729 or #2730
Closed
2 tasks done

SDL Regression - Wrong Fullscreen Resolution Chosen at High DPI #2699

BreakPoints opened this issue Jun 6, 2023 · 8 comments · Fixed by #2729 or #2730
Labels
bug Something isn't working
Milestone

Comments

@BreakPoints
Copy link
Contributor

BreakPoints commented Jun 6, 2023

Acknowledgements

  • I have searched for duplicate or closed bug reports
  • I understand that I am supposed to provide my own legitimately obtained copy of the game

Describe the Bug

Since the SDL changes, swapping to fullscreen mode with a non 100% scale set in Windows results in the wrong resolution being chosen.

From what I can see the desktop is forced into 100% scaling and a set resolution when fullscreening but if scaling was not set to 100% before swapping modes an incorrect desktop resolution is set. This means running at native resolution from the games settings still looks blurry.

Notes: Different scaling levels in Windows will lead to different incorrect desktop resolutions set, 2560x1600 125% ends up in a 4:3 resolution.

How To Reproduce

  • Set Windows display scaling to a non 100% value
  • Boot game and set display mode to fullscreen
  • Dev topbar is a good reference to check resolution as it does not scale

Does this problem occur on original hardware or PCSX2?

Not needed, bug is obvious

Expected Behavior

Native display resolution is selected for fullscreen

Operating System

Windows 11 22H2

OpenGOAL Version

dev

Game Version

NTSC 1.0 (black label)

Are you using a high refresh-rate monitor (>60Hz)

No

@BreakPoints BreakPoints added the bug Something isn't working label Jun 6, 2023
@xTVaser xTVaser self-assigned this Jun 7, 2023
@xTVaser xTVaser added this to the June 2023 milestone Jun 7, 2023
@xTVaser
Copy link
Member

xTVaser commented Jun 9, 2023

@BreakPoints Let me know if this works better #2713

as for ImGUI being blurry, I think that is expected as you have to do a bunch of other work to get that right, and it's probably not worth it since it's just for debugging - https://github.com/ocornut/imgui/blob/master/docs/FAQ.md#q-how-should-i-handle-dpi-in-my-application

But I was able to reproduce the imgui bar not spanning the entire width, as well as the resolution clearly being wrong when you attempt to minimize the game (indication that the fullscreen window size was too small (25% scaled down for example)). Both of those are now fixed on my end.

@BreakPoints
Copy link
Contributor Author

Tried #2713 and it's an improvement, the Windows Desktop is now kept at native resolution.

The ImGUI being blurry is still being caused by the same issue as the rest of the game. On your PR the framebuffer of the game + ImGUI is being chosen based off of Windows scaling so on my 2560x1600 screen with 200% scaling I get a sharp 800p integer scaled image. With 150% scale we are now at an uneven scale so bilinear scaling is used from 1200p and that's when the whole image looks blurry.

In game resolution is scaled to this incorrect intermediate resolution, then scaled again to the desktop resolution Windows is running in. Same in fullscreen and borderless modes.

Windowed mode allows Windows scaling to scale up whatever game resolution is chosen, any resolution over 800p at 200% scaling is progressively more offscreen.

@ManDude
Copy link
Member

ManDude commented Jun 10, 2023

Can you post screenshots? So the problem is easier to visualize.

@BreakPoints
Copy link
Contributor Author

BreakPoints commented Jun 10, 2023

So it looks like currently things are being handled correctly but my problem is Windows needs to be told to not scale the window in order to play at resolutions higher than the scale would allow.

Windows at 200% scale:
200% Zoom

Windows at 150% scale:
150% Zoom

Windows at 100% looks normal but for some reason I am unable to take Windows snip or Gamebar screenshots of either fullscreen or boarderless at this scale. I get black or stale frames.

Edit: Windows 100% in current release build for comparison, would recommend opening images in new tab:
100% Zoom

@xTVaser xTVaser removed their assignment Jun 10, 2023
@xTVaser
Copy link
Member

xTVaser commented Jun 10, 2023

I really have no idea how this stuff is supposed to be handled properly and I couldn't find a consistent reference for how it's supposed to be done either. In my linked PR I reference some SDL hints related to windows DPI awareness that may help (some solutions referenced these, I saw absolutely no difference using them).

I'll leave this to someone who has more of a clue than me.

I can also reproduce snipping tools problems / sometimes the borderless window doesn't want to minimize as gracefully as it should -- but I believe this is unrelated to scaling and is a separate issue. For what it's worth -- I can replicate these same problems on the old GLFW code if i change the scaling while the game is running.

@BreakPoints
Copy link
Contributor Author

I think it would be a flag that needs to be set that tells Windows that the application handles scaling itself. Forcing it in the compatibility settings results in native resolutions while scaling is enabled in Windows:
image

I'll have a dig but at least with #2713 and the above setting the issue can be worked around.

@ManDude
Copy link
Member

ManDude commented Jun 10, 2023

Just wondering - is this with MSAA on? Does this act differently with MSAA off in windowed mode?

@BreakPoints
Copy link
Contributor Author

BreakPoints commented Jun 10, 2023

This is all with MSAA off, windowed mode just increases the size of the windows by the display scaling percentage still leading to blurry images.

The reason the 200% imagine looks like it's got MSAA on is because it's rendering at 1600p internally then being scaled to 800p (effectively super sampling), then back to 1600p using nearest neighbour

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment