Opened 5 months ago

Closed 5 months ago

#12847 closed defect (fixed)

HQ filter broken when applied as a global setting

Reported by: tsoliman Owned by: criezy
Priority: blocker Component: Graphics
Version: Keywords:
Cc: Game:

Description

The HQ filter seems to be slightly broken for me and for sluicebox when running a hires game (e.g. COMI or KQ7) in the latest master (e6db9ded56)

I am using a 2015 macbook pro 15" (retina display)

Steps to reproduce:

  • Launch ScummVM using a HiDPI display
  • Switch to SDL HQ3X (you now have to explicitly pick SDL Surface and then pick HQ and 3x as a factor)
  • Launch a hires game
  • Note the window being abnormaly huge
  • Press Ctrl-F5
  • Note the GMM being tiny

This doesn't occur in older master (3b47e561552) so it is a recent regression.

Attachments (6)

3b47e561552 hq3x windowed.png (603.6 KB ) - added by tsoliman 5 months ago.
3b47e561552 hq3x settings.png (193.2 KB ) - added by tsoliman 5 months ago.
3b47e561552 hq3x fullscreen.png (784.5 KB ) - added by tsoliman 5 months ago.
e6db9ded56 hq fullscreen.png (1.5 MB ) - added by tsoliman 5 months ago.
e6db9ded56 hq window.png (1.6 MB ) - added by tsoliman 5 months ago.
e6db9ded56 settings.png (95.7 KB ) - added by tsoliman 5 months ago.

Change History (19)

comment:1 by tsoliman, 5 months ago

Summary: HQ3X broken in latest master in HiDPIHQ filter broken in HiDPI

comment:2 by sev-, 5 months ago

Testing showed that it did not get broken, it behaves like in pre-HiDPI. We are not applying GUI scaling in non-OpenGL because SDL reports 1:1 pixel ratio, e.g. non-retina.

by tsoliman, 5 months ago

by tsoliman, 5 months ago

by tsoliman, 5 months ago

comment:3 by tsoliman, 5 months ago

I attached screenshots from the old commit mentioned to show that this used to work fine in that commit.

by tsoliman, 5 months ago

by tsoliman, 5 months ago

Attachment: e6db9ded56 hq window.png added

by tsoliman, 5 months ago

Attachment: e6db9ded56 settings.png added

comment:4 by tsoliman, 5 months ago

I also attached screenshots from the latest master (e6db9ded56) to show what it now looks like. Note that this "giant window" effect happens in any HQ filter mode (2x or 3x) but not in normal 3x scaling

comment:5 by criezy, 5 months ago

This is not really a regression in that the current behaviour matches the behaviour in the last release.

The work on HiDPI has added the ability to scale the GUI. This was meant to be used primarily for HiDPI displays, but there were several intermediate steps with different ways to scale the GUI that had unintended consequences. What you see in your screenshots is one of those.

I suspect that changes that "breaks" that (and restores the 2.2.0 behaviour) is ad31dfc8d5. Before that commit the GUI was clipped to a resolution of 960x720 max, with a scaling applied to match the window size if greater than that. This was not optimal in the launcher where having a higher resolution for the GUI can be welcome, and it also had a few others quirks and unexpected behaviour.

The good news is that all this work to support HiDPI does mean that we can now scale the GUI, so it might not be too complicated to improve on the current behaviour. But I see this has an enhancement rather than bug fix, and I am not sure I would say the current behaviour is broken.

We could for example try to scale the GUI according to the original game resolution when displaying GUI dialogs in games. But that might not work that well for 320x200 games for example.

Note that this "giant window" effect happens in any HQ filter mode (2x or 3x) but not in normal 3x scaling

I am confused by this statement. Could you clarify what this means?
I just made a series of tests on macOS with current master and the behaviour is the same for me for both Normal 3x and Hq 3x (and I also checked it is consistent with the way it behaved in the 2.2.0 release). I also do not see any reason why HQ scalers would behave differently from Normal scalers.

Last edited 5 months ago by criezy (previous) (diff)

comment:6 by tsoliman, 5 months ago

The behavior is not the same for me in normal and hq.
HQ results in a giant window whereas normal doesn't.

sluicebox saw this as well.

comment:7 by tsoliman, 5 months ago

I just checked the latest release 2.2.0 and it behaves like the old commit (working fine)

comment:8 by sev-, 5 months ago

Priority: normalblocker

Raising priority as the release blocker.

comment:9 by criezy, 5 months ago

Let's put aside the GUI menu size for now and focus on the window size.

I am not sure what window being abnormaly huge means, but I did some additional tests and I am getting the expected window size with both Normal and HQ scalers.

You can run scummvm with -d 3 to get output on the window size.

On a Retina laptop I cannot test 3x scalers as the screen is too small, but with 2x scalers and COMI I get the following:

Normal 2x: Setting 1280 x 960 -> 1280 x 960 -- 1
HQ 2x: Setting 1280 x 960 -> 1280 x 960 -- 1

That is the expected size, and it matches what I get with ScummVM 2.2.0.

Note: with Surface SDL mode, since HiDPI is not enabled, we are running in compatibility mode and the OS applies a 2x scaler on its own. On the ScummVM side we see things as if the screen had half the DPI that it really has. So the window is actually 2560x1920.

On my non-retina iMac, I can test the 3x scalers and I also get the expected result:

Normal 3x: Setting 1920 x 1440 -> 1920 x 1440 -- 1
HQ 3x: Setting 1920 x 1440 -> 1920 x 1440 -- 1

In all cases I am getting the expected window size, and it matches the size I have with ScummVM 2.2.0.

comment:10 by criezy, 5 months ago

I think I finally understand what this bug report is about, and it is not related to HiDPI.

The issue is when setting the scalers in the global option, and not overriding them for the game. In such a case with ScummVM 2.2 we do not apply the scaler to 640x480 games (or bigger) and display them at their original resolution (e.g. 640x480).

With current master this is still the behaviour with the Normal scales, but not with the other scalers. For those the scalers gets applied to the game as well, so instead of 640x480, we get 1280x960 or 1920x1440.

I suspect this is a regression either from the scaler plugin pull request or from the pull request to split the graphics modes and scalers into two separate popups.
Indeed the HQ scalers do not have a 1x mode, which might be why it sticks with the 2x or 3x for the game as well.
https://github.com/scummvm/scummvm/pull/2358
https://github.com/scummvm/scummvm/pull/2853

comment:11 by tsoliman, 5 months ago

Keywords: hidpi removed
Summary: HQ filter broken in HiDPIHQ filter broken when applied as a global setting

comment:12 by criezy, 5 months ago

I have now verified with a bisection that this is a regression from PR 2853 GUI: Add improved scaler selection to the Options dialog

The exact commit that causes the regression is the first one from that pull request:

commit 0e6b9c2bb6738dcf15d0dcc534aedacf8de78c1b
Author: Cameron Cawley <ccawley2011@gmail.com>
Date:   Tue Jan 5 22:54:53 2021 +0000

    SDL: Begin refactoring the API for selecting scalers

comment:13 by criezy, 5 months ago

Owner: set to criezy
Resolution: fixed
Status: newclosed

Fixed in 478fbbbe9b

Note: See TracTickets for help on using tickets.