Screen sizes issues

[Vweber73]

Hi,
All but Borderless screen modes don't have the correct ratio, they are too compressed vertically.
"Narrow" comes close, but the top is cut (status line in Workbench, title in Interceptor for instance).
"Borderless" is nice, but the screen zoom is not fixed, varies with what is on screen, disturbing for demos and even for the welcome "hand disk".
I think zooming should not be at the expense of screen ratio... My 2 cents.

Cheers

[Vweber73]

Hi,
So, maybe this could be the next issue, screen look and size is important :) narrow mode looks ok but the top is cut, like title line in Interceptor and workbench...
Cheers

[mithrendal]

yes lets do it ... I draw with dpaint a big circle and measure the pixels on the rendered screen output ... narrow is nearly perfect ... the others are way off

[Vweber73]

Nearly perfect, but beheaded ;)

[mithrendal]

True. I meant the aspect ratio 😬. We will have to adapt them all 🙈

[Vweber73]

Good luck ! ;) And thanks...

[mithrendal]

the current calculation of display area is completely wrong 😬... not only the cut out of screen buffer ... but also the later scaling of the output canvas ... I found that it still has fixed values 🙈brought over from the vc64web ... embarassing 😱... expect this to be corrected very soon !! 😎

[Vweber73]

Excellent, thanks ! Yes I always thought something was wrong... :)
Also, I don't want to be picky, but there is a very light flickering during the vertical scrolling of Gravity Force (another of my all times favourites - simple but unique and addictive game), which does not appear in RetroArch/PUAE. Maybe your resolution fixes will also fix this ?
Cheers

[mithrendal]

new version with corrected aspect ratios is pushed out...

what was curios while correcting this is that the aspect ratio was not 4:3 as some sites claim said but for PAL it is 5/4 when having quadratic pixels as this site said http://coppershade.org/articles/More!/Topics/Correct_Amiga_Aspect_Ratio/

I think 4:3 for NTSC ... I worked around this by dividing the width and height of the cut out from the amiga screen buffer dynamically ... so even with borderless it should (in theory) correct the aspect ... hope that is true ... of course not if you intentionally use "cinematic wide screen" option from the settings

[Vweber73]

The result is excellent, congrats and thanks ! The Workbench is now crisp and clear, Interceptor now with this + overclocking has nothing to envy to NTSC mode, no more need to do it :) really catching up with PUAE, great ! Only a very small bit of flickering in Gravity Force vertical scrolling, not sure if this could be improved, but that's very light anyway...
Cheers

[mithrendal]

there was a bug ... on some of my machines it reported wrong canvas height (doubled !) and that resulted in complete wrong aspect ratios ... I just pushed out a new version ... should run on all plattforms now ...

[Vweber73]

It was on my Z3, but I updated the version anyway.

Maybe some slight pixel distorsion... See attached the kickstart 3.1 boot screen for both vAmigaWeb and PUAE, the 5 of "1985" is thiner in PUAE...

[Vweber73]

Funny, changing the rendered from GPU to software makes it perfectly crisp ! Normal ?

[mithrendal]

yes I know now why ... in the scaling algorithm I ask for the real pixels of the canvas output ... in software renderer this is the current cut out size of amigas screen buffer ... but in gpu shader rendering javascript reports always the shader buffer which I set to a maximum of 724 x 568 ... for this reason it scales so ugly because the aspect ratio is slightly wrong... i try to fix it

[Vweber73]

Great, thanks !

[Vweber73]

It seems there are still some bugs... When moving from portrait to landscape, moving from software to GPU etc... I got different sizes for borderless for Interceptor (see 2 pictured attached). I also got the bad ratios of previous versions coming back ?!

[mithrendal]

yes borderless switches to a propriety cut out which is often not exactly 4:3 ratio (or PAL 5/4) and GPU shader has currently the problem that it can not adapt to it due to the wrongly reported width which is not the width choosen by borderless algrithm but the witdth of the GPU shade texture ...

I bet you see it only when borderless and GPU shader, right? borderless and software rendering works ok?

[Vweber73]

No, I have problems with software as well, it is driving me nuts...
Example: I load my snapshot on Interceptor menu, without virtual keyboards it looks like this, quite full screen :

Then I selected the virtual keyboard, it shrinks like this:

Then I off the keyboard, but it doesn't go back to the first state...:

Once it is messed up, I have bad ratios coming back for narrow, standard... It seems that switching to landscape and back to portrait also messes it up !

[Vweber73]

One thing that may play a role, correct me if I am wrong: Interceptor is a NTSC game. So on a PAL machine, some lines (16) are wasted at the bottom (black). On a NTSC machine, pixels are taller, so the 240 lines can fill the screen entirely. That's why I wanted NTSC, for full-screen Interceptor (+speed increase from 50 to 60khz). Is borderless able to match NTSC pixel ratio (320/240 = 4/3) rather than PAL ratio (320/256 = 1.25) ? I would be very good to have the NTSC aspect without emulating NTSC :)
And could this PAL/NTSC stuff be messing up your screen resolutions ?

[mithrendal]

thanks ... I can reproduce the problem ... wait I have to debug ...

[Vweber73]

Great ! A reproduced bug is a half-fixed one :)

[mithrendal]

Ok got it ... it goes like this...

-- you are in borderless mode --

first you started the vAmigaWeb -> it scales the ratio according to the kickstart disk hand picture

then you loaded a snap shot borderless calculates new screen buffer cut out, but !! -> no rescaling of aspect ratio takes place

(this is the bug I think)

then later always when you kick in the keyboard or resize landscape / portrait -> it rescales the ratio

so ... the first picture of you (the one which never came back) had the wrong ratio from the kickstart hand disk logo screen

ok what we should do I think is ... everytime the borderless changes dimensions of the cut out then it must also rescale to the correct ratio ... no ?

PS: I veryfied this hypothesis by launching dpaint from snapshot with a circle ... the circle was wrongly scaled ... then on keyboard in .. it was correct

[Vweber73]

Ok, but:
-If you keep the ratio, how to adjust for NTSC games (like Interceptor) to be full-screen with no waste (see my previous post) ?
-If also saw some wrong ratios coming back for other settings than borderless (narrow, standard...). Could you reproduce this ?

[mithrendal]

borderless
right after kickstart had disk... loaded this snapshot

the circles height is too great...

now kick the keyboard in ... which does the rescale

[mithrendal]

Ok, but:
-If you keep the ratio, how to adjust for NTSC games (like Interceptor) to be full-screen with no waste (see my previous post) ?

hm ... when we always do the rescale with a "variable" aspect ratio according to the borderless width / height then it adapts to NTSC/PAL automatically no?

lets try it out...

[mithrendal]

the current version has the bug that it does not rescale aspect ratio when borderless changes dimensions... you can manually force rescale of correct aspect ratio by switching keyboard off/on

[Vweber73]

Ok, but:
-If you keep the ratio, how to adjust for NTSC games (like Interceptor) to be full-screen with no waste (see my previous post) ?

hm ... when we always do the rescale with a "variable" aspect ratio according to the borderless width / height then it adapts to NTSC/PAL automatically no?

lets try it out...

If that's the case that would be fine ! :)

[mithrendal]

-If also saw some wrong ratios coming back for other settings than borderless (narrow, standard...). Could you reproduce this ?

yes now I see it too... they also do no rescale when switched to 🙄 ... you are a brilliant alpha😂 tester

[mithrendal]

pushed out a new version ... should be hitting the server in a minute or so

UPDATE: new version which corrects the scaling in borderless and when switching between the different display sizes is on the server

[Vweber73]

I'm proud to be an alpha-tester ! :)
Well, this one has problems...
First, when switching to narrow in Interceptor I suddenly got a blank screen, that wouldn't go away by changing display mode, only a reset would :

Then, I no longer have the taller cockpit ("NTSC mode") that i use to have sometimes. Both narrow and borderless has the same height, even if they are not positionned at the same place... Here they are:

It is as if the pixel ratio was always the same (PAL) ?

Have you done something with the GPU pixel scaling ? (Haven't compared with software yet).

Cheers

[Vweber73]

Also, the borderless mode is a bit cut at the bottom...

[mithrendal]

pushed new version where we have now
reduced display height on narrow, standard, wide, overscan by 48 pixel when NTSC pixel ratio is on

do you think this is good now?

EDIT: first I thought hand disk logo is a bit positioned too far at the bottom but then I saw this video where a NTSC amiga 1000 boots https://www.youtube.com/watch?v=-dyxKJx9N5E

but look when I directly compare it with this way ...

the picture from the youtube video got more pixel on the top and a little more on the bottom too

another guy talks about PAL vs NTSC and how WinUAE is wrong and how to configure it right here at 18:09
https://www.youtube.com/watch?v=D5hiwB7lzk8

the claimed correct NTSC WinUAE picture from that video see here at the very right

[Vweber73]

Wow, thanks for the research, this is giving me headache now... I really don't know...
Anyway good for NTSC, for PAL I really like what you said: navbar height + keyboard height + Amiga screen height <= heigth of your device e.g. Z3 Fold. Yes indeed why not doing it this way... But I also like the current way on second thoughts, since vAmigaWeb allows to remove temporarily the menu bar, doing it this way when you want real full screen is good and makes use of 100% of the real estate, so it could be kept that way.
I like borderless for games, for demos like Burning Spear which keep changing the resolution it is a bit of a mess with a change of scale...

Thanks and cheers

[mithrendal]

I think it is fine now. 😎The reduced height on ntsc is also good too because it will be used on ntsc games only which do not have overscan pixel at the bottom right? We should try some ntsc games and see whether the fixed sizes cut off their bottom graphics or not 😬 in which case we simple would lower the 48 to lets say 42 or so…

[Vweber73]

Well, problem, in borderless with keyboard, moving to NTSC cuts the cockpit completely, and moving back does not restore it completely... See attached

[mithrendal]

in borderless with keyboard, moving to NTSC cuts the cockpit completely, and moving back does not restore it completely...

confirmed ...
the -48pixel is applied to borderless too 🙈…there are now with ntsc so much ifs in the code ... did not test all code paths...😬

just pushed new version out which should correct this and do not introduce new bugs 🙄hopefully

EDIT: for testing purposes I created an actionbutton which toggles NTSC
document.getElementById("ntsc_pixel_ratio_switch").click();

[Vweber73]

Confirmed working, thanks,
In borderless PAL the bottom of the cockpit is touching the edge of the app controls, so the color of the last line is the same as the app one, blending into it and giving the impression of a cut... Oh well, never mind.

[Vweber73]

With picture

[mras0]

FWIW Interceptor isn't really running in NTSC mode it just uses the same screen dimensions, so on a real PAL amiga the bottom of the screen is also empty and the aspect ratio is (probably) off compared to a NTSC machine.

This is what it looks like on my PAL A1200:

WB (Standard hi-res PAL, notice the mouse cursor where the screen ends):

Interceptor:

[mithrendal]

In borderless PAL the bottom of the cockpit is touching the edge of the app controls, so the color of the last line is the same as the app one, blending into it and giving the impression of a cut... Oh well, never mind.

we could give the keyboard a darker top border ... to make that effect vanish

[Vweber73]

@mras0 Thanks ! Yes indeed it is cut on PAL Amiga, that was the same on my 500.
@mithrendal Good idea, thanks !

[mithrendal]

In borderless PAL the bottom of the cockpit is touching the edge of the app controls, so the color of the last line is the same as the app one, blending into it and giving the impression of a cut... Oh well, never mind.

try this javascript command in an action button via the + icon in the navbar ...

$("#virtual_keyboard").css("box-shadow", "inset 0 0 0.2em black");

it will give the keyboard a black borderline on the top

or this

$("#virtual_keyboard").css("background-color", "black");

it will make the keyboard background black...

[Vweber73]

Sweet, thanks !

[dirkwhoffmann]

I've merged the current NTSC code (main functionality is working) into the main branch. Before doing more "NTSC" stuff in the web version, I recommend to merge the latest code and do all further experiments with real NTSC mode enabled. Use the following calls to switch between both modes:

amiga.configure(OPT_MACHINE_TYPE, MACHINE_PAL);
amiga.configure(OPT_MACHINE_TYPE, MACHINE_NTSC);

vAmiga supports "hot switching" which means it's safe to switch between PAL and NTSC any time. However, keep in mind that Kickstart runs a PAL / NTSC check during startup. Hence, Kickstart won't recognise any "hot switch". The same applies to games or demos that either run a similar check or rely on the value provided by the OS.

[Vweber73]

Sorry to come back to this, but something is still wrong, the screen is cut left and right for some games.

See attached settlers intro screen for vAmiga (narrow, but all modes show the problem - overscan is shifted to the right, strangely) and RetroArch/PUAE (the left and right circled are not cut)

[Vweber73]

I understand the game uses overscan (720 pixel wide) and that therefore overscan mode should be used (but anyway to trigger it automatically, like PUE does ?). But see attached, the image is shifted to the right and therefore cut, not centered correctly...

[mithrendal]

good find 🤗 ... if you set viewport tracking or borderless it will be good for the left side but not for the right side ...

when I take a snapshot and look in the snapshot browser I can see that the core does not give us more than this image data ... right side circle is cut

I will upgrade to latest core as it seems that the overcsan implementation was wrong but has been fixed in the meantime see here dirkwhoffmann/vAmiga#698

[Vweber73]

Excellent, thanks, let me know when it is available :)
What about automatic triggering, like PUAE does, i.e. when overscan resolution is detected, overscan mode is enforced ?

[mithrendal]

What about automatic triggering, like PUAE does, i.e. when overscan resolution is detected, overscan mode is enforced ?

you get this automatic when choosing viewport tracking or borderless ... or what does PUAE different than that?

[Vweber73]

Oh ok, you mean that with the new core version things will be fine in borderless and viewport modes then. I thought it would not be the case, since for now both ends are cut, not just the right one...

[Vweber73]

Hi,
Any progress on the new core (NTSC + Overscan fix + ?) into vAmigaWeb ?
Many thanks and best regards

[mithrendal]

yes the new core runs very fine 😎 ...

there is still a small minor pixel problem on the right side ... between software renderer and GPU renderer there is a difference in 4 pixels on the right side only in this extreme overscan of settler ... before pushing this I like to understand and solve this

the picture above shows software renderer which is missing 2 pixels to the right...

has to do with viewtracking reports hstop_max 4 pixels greater than the screenbuffer really is ... needs to be further analysed before we push out this version no? ... we want it to be perfect 😎

next is the NTSC capability of the new core which is fairly easy to connect to ...

[Vweber73]

Excellent, thanks !
I was just thinking: could vAmigaWeb detect before hand the screen resolution and adapt to it ? Like if it is overscan, trigger overscan mode ? That's not what borderless / viewport do, they rather dynamically detect the border based on colors, not on screen resolution, right ?
Cheers

[mithrendal]

that is because the screen resolutions and viewports are altered dynamically by the amiga software e.g. games ... in Amiga there is not such a thing that the resolution is initially set in boot block and then stays static until the next reset...

[Vweber73]

That's right, but why not detecting those resolution changes rather than the colors borders ?

[mithrendal]

viewport tracking = permanently tracks the resolution changes set by amiga software
borderless = takes the viewport values of viewport tracking and additionally tries to eliminate same colored borders

what you describe is already 😎 at your choice

[Vweber73]

I see, thanks ! I got fooled by the Burning Spear demo, it changes resolutions so many times...and that causes vAmigaWeb extreme zoom changes. PUAE ones are not that extreme, maybe different scaling ?, so I thought that viewport was different...

[Vweber73]

A bit of problems still with viewport tracking, cut on the left... Same issue that the one you mentionned ?

[mithrendal]

@Vweber73

first

I felt the need for an environment to evaluate and test vAmigaWeb before releasing to the masses ...

therefore there is now a UAT environment (UAT stands for user acceptance test)

at https://vamigaweb.github.io/uat

second

into the uat goes:

• a brand new version with the cores brand new NTSC capabilities so it is not just the screensize and pixelratio which will be NTSC like but also clockspeed of chipset is raised to 60Hz and more

• I did reset all settings to support overscan screen sizes

when vAmigaWeb at uat proves to be stable then we will publish it to its regular address at
https://vamigaweb.github.io which is currently still the stable version

[Vweber73]

Hi,

Many thanks for creating this test app ! I could replace the current stable one with this one and test it, after a few tries.

My experience so far:

1. My snapshots don't work anymore (the Amiga resets) but I guess this is normal. Saving new snapshots and restoring them seems to work.
2. Settlers now seems to work fine, but while viewport uses all the width of the screen, overscan mode keeps a small margin left and right. Normal ?
3. Settlers has no intro music in NTSC mode when hot-swapping. Hot-swapping back to PAL restores the sound...
4. Most importantly, Interceptor is screwed up because super slow in 7mhz mode, be it in PAL or NTSC mode. I first thought it was a sound problem like Settlers since I didn't hear the music, but then I realize how slow the text was, and the music started... during the flight demo mode ! Complete desynch...

Cheers