Fullscreen and Integer Scale

[Chacs]

Hi
I have a laptop on Win10 with native resolution of 1920x1080.
I use Hatari 2.3.1 in fullscreen mode with "keep desktop resolution in fullscreen" option enabled, borders enabled , status bar disabled.
I would like to use integer scaling to get crisp pixel.

here is my cfg file

Code: Select all

[Screen]
nMonitorType = 1
nFrameSkips = 5
bFullScreen = TRUE
bKeepResolution = TRUE
bResizable = FALSE
bAllowOverscan = TRUE
nSpec512Threshold = 1
nForceBpp = 0
bAspectCorrect = TRUE
bUseExtVdiResolutions = FALSE
nVdiWidth = 640
nVdiHeight = 480
nVdiColors = 2
bMouseWarp = TRUE
bShowStatusbar = FALSE
bShowDriveLed = FALSE
bCrop = FALSE
bForceMax = FALSE
nMaxWidth = 832 
nMaxHeight = 588
nZoomFactor = 1
bUseSdlRenderer = TRUE
bUseVsync = FALSE

With a integer scale of 1 (nZoomFactor = 1), i would expect black margins up and down of 246 pixels (1080 - 1 * 588) / 2 , but the screen height is entirely filled.
The result is not bad, but i can see clearly that the pixels are a bit blurry and the GL_NEAREST is not used by SDL.


I tested with

Code: Select all

nMaxWidth = 1280
nMaxHeight = 1080
nZoomFactor = 1 

or

Code: Select all

nMaxWidth = 832
nMaxHeight = 540
nZoomFactor = 2

with these values, as excepted the screen height is fitted (1080 = 2 * 540) but the result still a bit blurry and GL_NEAREST is seems not to be used by SDL


Do i misunderstood something ?

[Eero Tamminen]

I don't have a FullHD monitor to check what values would fit, but I think the problem is that:

• With Hatari SDL2 auto-scaling, that scaling check is done with non-zoomed resolutions. So max resolution needs to be something between 320-416 x 200-276
• atari screen conversion functions require horizontal border sizes to be divisable by 16, so Hatari enforces that
• After that, Hatari expects both dimensions to have integer scaling before allowing nearest neighbor scaling. This is done because otherwise Hatari window contents resize results would look bad

Therefore, for my 1680x1050 monitor, I would need to use this (which leaves just insignificant amount of top/bottom, so I won't bother):

Code: Select all

--borders on --statusbar off --zoom 2 --max-width 336 --max-height 210 

For your FullHD monitor, you probably need to use something like:

Code: Select all

--borders on --statusbar off --zoom 2 --max-width 384 --max-height 216 

(Only 1/5th of monitor resolution divides evenly while still being in correct value range, but it leaves fairly small amount of borders.)

You can debug this by setting "DEBUG" define in src/screen.c to "1", re-compiling Hatari and seeing what it outputs when running with above options.

You should be seeing something like this:

Code: Select all

resolution limit:
resolution limit:
	384 x 216
limited resolution:
	1 * (32 + 320 + 32) x (8 + 200 + 8)
	= 384 x 216 (+ statusbar)
SDL screen request: 384 x 216 @ 32 (fullscreen) -> window: 768 x 432
768x432 / 384x216 -> scale = 2, Render Scale Quality = 0
SDL screen granted: 384 x 216 @ 32
resolution limit:
	384 x 216
limited resolution:
	1 * (32 + 320 + 32) x (8 + 200 + 8)
	= 384 x 216 (+ statusbar)
1920x1080 / 384x216 -> scale = 5, Render Scale Quality = 0

In above "window" size is limited to your desktop size, and render scale quality of zero means nearest pixel: https://wiki.libsdl.org/SDL_HINT_RENDER_SCALE_QUALITY

And last line is what happens when Hatari gets info of the actual fullscreen resolution.

PS. In fullscreen (where SDL support letterboxing the other dimension), it should be enough if only the dimension closer to screen size would be evenly divisible (while that's not problem for FullHD, it's for resolutions that run afoul of second rule with rule three, like the resolution of my monitor).

Attached patch should fix do that:

Fix-SDL2-filtering-selection.patch.txt

[Chacs]

Thank you for taking the time to answer me.

I'm not very good in git and coding, so the attached patch means that in a next release of Hatari, this issue will be fixed ?

[Eero Tamminen]

Thank you for taking the time to answer me.

I'm not very good in git and coding, so the attached patch means that in a next release of Hatari, this issue will be fixed ?

Your monitor resolution shouldn't need the patch, just using the options I indicated. Can you verify that you get non-blurry fullscreen by using them?

The improvement in the patch is needed only with monitors (like mine) which resolution is not evenly divisible by Atari resolution in *both* dimension (when taking into account Atari resolution limits I listed). After the improvement, it's enough that only one of the dimensions (closest one to monitor size) is evenly divisible.

I've pushed that improvement to Hatari source repository. To test it, one doesn't need to use Git, as code corresponding to latest Hatari commit can be downloaded as ZIP from GitHub Hatari mirror, one just needs to build it: https://github.com/hatari/hatari/archiv ... master.zip

That improvement will be in next Hatari release unless it's reported to be buggy.

However, there seems also to be another problem, at least in my case. While patch helps with fullscreen mode, according to debug output Hatari may to get slightly confused about the specified max size when switching between fullscreen and windowed mode, so that one loses the non-blurry fullscreen mode after doing the switching few times. Does that happen also with your monitor resolution, when you specify options I indicated?

(It might not happen with your monitor because your fullscreen resolution is evenly divisible in both dimensions.)

[Chacs]

Thank you for taking the time to answer me.

I'm not very good in git and coding, so the attached patch means that in a next release of Hatari, this issue will be fixed ?

Your monitor resolution shouldn't need the patch, just using the options I indicated. Can you verify that you get non-blurry fullscreen by using them?

Hi Eero Tamminen

i tried with these parameters

Code: Select all

--borders on --statusbar off --zoom 2 --max-width 384 --max-height 216 

i got the following screenshot, it still blurry