Aspect ratio not correct in fullscreen

[ggoedert]

The aspect ratio not working correctly on fullscreen, this was working correctly on version AppleWin1.29.16.0. This seems unrelated to whether VidHD is enabled or not.

[tomcw]

Hmm, I've not changed anything here: full-screen (eg. F6) should just keep the same aspect ratio is windowed-mode. I guess if you are using the command line switch -fs-height, then you could get a change in behaviour.

Are you using this switch?

For reference, from History.txt (after 1.29.16.0): 1.30.2.0:

• Command line: change -fs-height so only applied during full-screen (Windows mode unaffected).

1.30.7.0: (VidHD / SHR support added)

• Command line: Allow user to specify width & height (for full-screen); and allow separate x,y scaling in full-screen mode.

[ggoedert]

Not using any command-line options, just press F6 to bring up fullscreen when I start the emulator. In window mode the aspect is correct.

Here are versions 1.29.16.0 and 1.30.11.0 screenshots:

[ggoedert]

I used the command line switch: -fs-height=best And that does fix the aspect ratio in fullscreen, I guess it is a workaround, though, the scaling and refresh ratio look better omitting that. Doing -fs-height=2160, which is my native resolution, does show the problem again.

Anyhow, no big deal, just wanted to document the behaviour, regardless your work is one of the best things that happened to the apple2 community in years, thanks!

[tomcw]

Great, thanks for the compliment! :-)

Presumably the native resolution is 4K, 3840 x 2160 ?

If you get a chance, can you run with logging (-log) and then attach the AppleWin.log file here:

AppleWin.exe -log -fs-height=best

(I'm curious about what AppleWin is picking as the "best" resolution)

[ggoedert]

Here it is: AppleWin.log

[tomcw]

Thanks. From the log:

Best resolution for -fs-height/height=x switch(es): Width=1366, Height=768

Which is an ratio of: 1.778645833333333 (And 3840 x 2160 is a ratio of: 1.777...)

From the log, resolutions where height is an integer multiple of (192*2):

1. 1366 x 768
   • SF = Scale Factor = 768 / 384 = 2
   • this resolution is a candidate as 1366 >= (560*SF)
2. 2048 x 1536
   • SF = Scale Factor = 1536 / 384 = 4
   • this resolution is rejected as 2048 < (560*SF)

---

NB. When using -s3 vidhd, then {width,height} for matching are {640,400}, instead of {560,384}.

Also on my monitor, native resolution 1920x1200, -fs-height=best gives:

• w/o vidhd: 1280 x 768 ; height multiple of 384
• w/ vidhd: 1920 x 1200 ; height multiple of 400

---

I need to try with a 4K monitor.

[fabricecaruso]

The fullscreen ratio problem comes with commit id 443545b0f6d31349eb365956ab948561e889cc15 with these lines :

When you restore the old code with :

    int g_win_fullscreen_scale = (scalex <= scaley) ? scalex : scaley;
    g_win_fullscreen_offsetx = ((int)width - (int)(g_win_fullscreen_scale * GetVideo().GetFrameBufferBorderlessWidth())) / 2;
    g_win_fullscreen_offsety = ((int)height - (int)(g_win_fullscreen_scale * GetVideo().GetFrameBufferBorderlessHeight())) / 2;
    SetViewportScale(g_win_fullscreen_scale, true);

Screen ratio is fine again.

Maybe you should add a new commandline -stretch -> When it's set, you use the new SetFullScreenViewportScale, when it's not set, you use the old SetViewportScale.

[tomcw]

I think I understand - it's because I now allow separate x & y (integer) scaling:

For 4K, 3840 x 2160:

• w/o VidHD: {560,384} => xscale=6, yscale=5
  • ie. {6x560, 5x384} = {3360, 1920}
• w/ VIDHD: {640,400} => xscale=6, yscale=5
  • ie. {6x640, 5x400} = {3840, 2000}

For a 4K panel, then xscale != yscale, so full-screen is stretched.

For 2K, 2560 x 1440

• w/o VidHD: {560,384} => xscale=4, yscale=3
  • ie. {4x560, 3x384} = {2240, 1152}
• w/ VIDHD: {640,400} => xscale=4, yscale=3
  • ie. {4x640, 3x400} = {2560, 1200}

For a 2K panel, then xscale != yscale, so full-screen is stretched.

For my old 1920x1200:

• w/o VidHD: {560,384} => xscale=3, yscale=3
  • ie. {3x560, 3x384} = {1680, 1152}
• w/ VIDHD: {640,400} => xscale=3, yscale=3
  • ie. {3x640, 3x400} = {1920, 1200}

Since xscale == yscale (for with or without VidHD) then I didn't notice, since it's the same behaviour as before.

Perhaps if the user doesn't specify a command line for -fs-width or -fs-height, then just use the old method (ie. lowest integer scale factor) ?

[fabricecaruso]

I personnaly do agree. Thus, it can be interesting to manage it with an argument like "-strech" instead Some emulators do that ( supermodel has -stretch argument, daphne has -ignore_aspect_ratio )

[tomcw]

@ggoedert, @fabricecaruso - can you try this new AppleWin 1.30.12.0 ?

NB. not using any (-fs-height/width) command line options will now only scale by the same amount for x and y.

[fabricecaruso]

It's working well without any argument, but it may not be a good idea. Resolution & ratios are different problems.

Anyway there are resolutions things...

If you don't start with -fs-height/width and switch to fullscreen with -f or manually : If you have a desktop 16:9 resolution of 1280x720 the main window size is 621x423. ( 384 + captions & borders ) If you have a desktop 16:9 resolution of 1920x1080 the main window size is 1181x807. ( 768 + captions & borders ) When set to fullscreen with integers & 1920x1080 you should resolve to 5 ( 5x192 = 960 ). When switching to fullscreen, you still use the same initial computed size, but final proportions look very different.
As they both are 16:9 resolutions, they should look about the same, but it's not. It's related to the fact that the scaling is based on integers & that switching to fullscreen does not recompute that factor.

Perfect vertical scale for 1080p fullscreen should be 5.625. It's actually 4, so you loose about 156 pixels @ top & 156 pixels @ bottom -> You loose 28,8 % of the total screen height (calculations based on heights).

Perfect vertical scale for 720p fullscreen should be 3.75. It's actually 2, so you loose about 168 pixels @ top & 168 pixels @ bottom -> You loose 46% of the height !!!!!

When you use -fs-height & -fs-width : If you set a resolution with these arguments, you still have the same problems, but it's just worse because you loose the original aspect ratio, so the Apple2 screen is always deformed & stretched...

So :

• I keep my suggestion for a -strech command line argument, which is probably the best solution ( or as an option ).
• Recompute the best scaling before switching to fullscreen ( or you stay with ratio x4 with 1080p - I should at least be 5 )
• Maybe propose a scaling option based on double or float calculations ( it's no more pixel perfect, but it will be far better looking with 1080p anyway ).