Screen sizes issues about vamigaweb

[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...

[Vweber73]

Oh, and I forgot: I suspect restoring my snapshot didn't update the overclocking indicator. The snapshot was fast but the indicator said "7mhz"...

[mithrendal]

Oh, and I forgot: I suspect restoring my snapshot didn't update the overclocking indicator. The snapshot was fast but the indicator said "7mhz"...

yes known issue ... clock speed is saved in snapshot but upon restoring it will not be reflected in the settings ... I would like to solve this by adding overlay indicators for clock speed, floppy and power LEDs

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

no ... not yet

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

cannot reproduce ... can you ? does it come always ?

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...

that is a good thing ... in borderless it cuts off the unused PAL blank area at the bottom and rescales it with a different aspect ratio so that the height of cockpit stays the same ... which was intended .. because we want to see the objects in the picture with the same height/width ... this makes it adapt automatically to NTSC/PAL

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

that is easy to fix I think ... lets do it tomorrow

[Vweber73]

No, I can't reproduce either, happened once, but I'm pretty sure it happened... Strange !

Re PAL/NTSC, I'm confused, I thought that what we wanted was the cockpit look taller, as it is supposed to look on a NTSC Amiga (same screen height but less lines => each line is taller). On PUAE, you can dynamically select PAL/NTSC pixel aspect ratio (without going into anything about properly emulating NTSC), and here are the results, quite different from one another:

[mithrendal]

No, I can't reproduce either, happened once, but I'm pretty sure it happened... Strange !

That may happen when you are in pause in conjunction with software renderer and you turning from landscape/portrait then the texture is not in the gpu and there is nothing new to draw ... hence gray .. press play and the screen comes back

PAL/NTSC, I'm confused, I thought that what we wanted was the cockpit look taller, as it is supposed to look on a NTSC Amiga (same screen height but less lines => each line is taller)

hm confused too ... the rendered "cockpit window" in your first retroarch/PUA pic (Pal?) is 269 pixel height and in the second it is 318 pixel height (NTSC?) i.e. taller ... that would on the other hand mean that the retroarch/PUA when switched between these modes does render a circle in at least one mode incorrectly i.e. with wrong ratios, right?

I bet I have to re read the theory http://coppershade.org/articles/More!/Topics/Correct_Amiga_Aspect_Ratio/

(What vAmigaWeb does currently is that it tries regardless of which screen dimension you choose to rescale a circle always as a perfect circle ... )

[Vweber73]

Hi,

Thanks ! I will try for the black screen...

Re PAL/NTSC, Retroarch call this "pixel aspect" + PAL or NTSC. Which makes me think that on a NTSC machine the 240 lines fill all the height of the screen, whereas on a PAL the same screen is filled by 256 lines, which makes me think that on a NTSC machine, the lines are taller (the pixel height is higher). I don't have a NTSC machine to verify it, but it seems to me than on a PAL machine Interceptor (which is NTSC, i.e. 240 lines only) is "compressed" vertically (hence the black bar below), which is not as intended (it is supposed to fill the screen), that's why the reviewers said Interceptor was best to play on a NTSC machine (this screen ratio + the increased frame rate). But I may be wrong, I have never used a NTSC Amiga in my life, I lived in France, everything was PAL and even SECAM.... :) What do you think ?

Cheers

[mithrendal]

in short when I understand the article about PAL/NTSC aspect ratios right then NTSC originally had really big bezels at the top !! and bottom...the americans in the US (annoyed by that top/bottom margins) just stretched their screens to get the bezels off (who likes bezels anyway...) and then they developed graphics and games with these "stretched" screens 🙄 and when the NTSC monitor screen was set/calibrated correctly again, the graphics were actually too compressed in height ... on PAL too...

the question is ... did Bob Dinnerman also stretched his monitor screen back then in 1988 before developing interceptor?

I have to think and study the article a bit more...

[Vweber73]

Very interesting read, many thanks ! Indeed if would be great to have the author's perspective on how Interceptor is supposed to by played...

[mithrendal]

Indeed it would be great to have the author's perspective on how Interceptor is supposed to be played...

ok lets do some retro archeology 🤓 then to find the answer to this question...

we have to look for circles in the game which are presumably "real" circles i.e. with a constant radius...

I spotted a circle on your pictures of the Z3 Fold which you posted above

RetroArch/PUAE PAL scaling

4x magnified

r-vertical = 209 pixel
r-horizontal=231 pixel

ratio = 0,9

scaling error=0,1

RetroArch/PUAE NTSC scaling

4x magnified

r-vertical = 249 pixel
r-horizontal=229 pixel

ratio= 1.087

scaling error=0,087

vAmigaWeb scaling

4x magnified

r-vertical = 208 pixel
r-horizontal= 227 pixel

ratio=0,9162

scaling error=0,0838

I would say neither looks completely as the monitor of Bob Dinnerman but

1. vAmigaWeb has the smallest visible difference and is the winner 😎
2. RetroArch NTSC scaling looks too tall on interceptor and has a bit more difference to the perfect ratio of 1.0 compared to vAmigaWeb 😌
3. RetroArch PAL scaling looks too wide on interceptor and has a biggest difference of 0.1 to the perfect ratio of 1.0 😱

[Vweber73]

Very interesting, many thanks !
Of course, the assumption is that this was intended as a circle and not an ellipse in the first place. But this sounds like a reasonable assumption ;)

[mithrendal]

Of course, the assumption is that this was intended as a circle and not an ellipse in the first place

that is true ... 🤓 But when I would be on a 1084s monitor I would turn the v-scaling knob to match a perfect circle ... looks so much cooler for me than the tall RetroArch/NTSC image... in the end this matter is so far away from being exact ... because they turned the knob in the 90ties as they liked ... maybe we should add a v-scaling knob in vAmigaWeb 😂 too

[Vweber73]

Haha why not ! :)

[mithrendal]

I found pictures of an old original cover box 😍

https://retro.ramonddevrede.nl/f-a-18-interceptor-amiga/

lets measure the rectangle on the cover pic

and compare it to vAmigaWeb

and RetroArch/NTSC

interceptor cover 195/135 = 1,44
vAmigaWeb 374 /270 = 1,38
retro arch ntsc 375/ 320 = 1,17

RetroArch/NTSC does not give you the thing on the boxed version ... vAmigaWeb comes closer 😍

I found something else ... the artificial horizont is according to this manual indeed a circle ... not an ellipse ... https://openretro.org/amiga/fa-18-interceptor/docs

[Vweber73]

Awesome info and investigations, many thanks !
Just one thing, the box has "made in England" on it... And England is NTSC... so maybe what we see is the software running on a PAL machine... Are we sure it runs with the same ratio on a NTSC machine ? ;)

[mithrendal]

We must ask someone with a NTSC machine to boot up interceptor for us on a 1084s …🙈

Until then I believe in the artificial horizont which is a circle not an ellipse 🤓

[Vweber73]

Well... Have a look at that... In addition to your English box scan, there is the US release box scan... Hum... looks a bit like an ellipse ! ;)

https://hol.abime.net/469/boxscan

[mithrendal]

ok 😬 now you made me believe in an ellipse ... 😍 ... then we must add this NTSC pixel aspect ratio switch ?

[Vweber73]

Well, why not ! :)
Here is what PUAE doc says about these issues, what do you think ?

Pixel Aspect Ratio [puae_video_aspect] (auto|PAL|NTSC)

Hotkey toggling disables this option until core restart.

'PAL': 1/1 = 1.000
'NTSC': 44/52 = 0.846

Geometry and timing

The PUAE core's core provided FPS is dynamic, but initially 49.9201277955271580 for PAL and 59.8250950570342180 for NTSC
The PUAE core's core provided sample rate is 44100 Hz
The PUAE core's base width is 360 in LoRes, 720 in HiRes 1440 in SuperHires
The PUAE core's base height is 288 for PAL single line, 576 for PAL double line, 240 for NTSC single line, 480 for NTSC double line
The PUAE core's max width is 1440
The PUAE core's max height is 576
The PUAE core's core provided aspect ratio is automatically set based on core options

https://docs.libretro.com/library/puae/

[Vweber73]

Also, not sure on how 60 hz vs 50hz frame rate affects the speed and smoothness. I know you have overclocking of the processor... But does this bring everything the increases frame rate brings ?

[mithrendal]

pushed out a version with ntsc pixel ratio switch 😎... I used the value which you told me i.e. 44/52 ... many thanks again for bringing this issue up to attention !!!

maybe rework this again ?

maybe better instead of two switches ... we combine all the scaling stuff in one selection ?

pixel_aspect_ratio = NTSC | PAL | cinematic wide screen

[Vweber73]

That's wonderful, thank you very much !
Not sure about combining, why not, anyway I like that the option is there !
What do you think about the faster NTSC frame rate (60hz instead of 50Hz) ? Is the benefit already covered by processor overclocking, or would this be interesting ?

[mithrendal]

Also, not sure on how 60 hz vs 50hz frame rate affects the speed and smoothness. I know you have overclocking of the processor... But does this bring everything the increases frame rate brings ?

it depends on the game I think... I bet the 68k at 14MHz is faster than NTSC clocked 68k CPU speed by far but see when you have some blitter intense stuff and CPU is used not that much in a game then maybe depending on that game the NTSC Amiga would run that faster ... because the blitter would run faster, no? Better we ask @mras0 or @dirkwhoffmann about that matter ... Also I would not have the indepth knowledge to do the patch by myself alone ... probably I would find the place in code but I would need too much time for it and also it has to be done in the AmigaCoreLib anyway... So when the vAmigaCore Lib project supports this in the future then vAmigaWeb will of course support it too... It would be interesting when you could bring up a game which stutters in PAL but runs fine in NTSC and which is not compensable with overclocking the CPU...🤓

@dirkwhoffmann @mras0 could I just call amiga->execute() 60 times a second instead of 50 time ? Is it that simple ? Or maybe not ?😂

[Vweber73]

Makes sense, thanks a lot ! :)

I tried to test Interceptor in both NTSC and PAL modes on PUAE wrt the sound, but I found no obvious difference in music pace. I thought the pace would be 20% higher in NTSC mode...

[mithrendal]

ok ... I try to clock it to 60 Hz instead 50Hz ... we will see what happens ... 💥

[Vweber73]

Great, let me know ! :)
Testing to the limits... Interceptor has some small glitches at high frequency (99khz). When you see the line "HDG KTS FT", some horizonal lines are crossing this text...

[Vweber73]

I got quite funny results with GPU shader :) guess it was not updated yet... :)

[mithrendal]

just updated GPU shader too ... hope it works well

and I made the NTSC target frame rate accessible so you can make an action button ... the javascript command is wasm_set_target_fps(60) ... if you need assistance regarding the actionbutton I help you

[Vweber73]

Thanks, I'm gonna try ! No way to get a setting for frame rate rather than an action button ?

[Vweber73]

GPU shader is not as crisp as software... See the font difference, "A" for instance...

[mithrendal]

time[ms]=1006, audio_samples=58368, frames [executed=60, rendered=59] avg_fps=59 😎

executed 60Hz

with this action button

when this feature works well we can make an regular setting

I made two action buttons one for 50Hz and one for 60Hz

regarding the crispyness ... yeah ... tomorrow

[Vweber73]

Thanks !
Yes I could test the button... On Interceptor, it makes the music way too fast and a bit garbaged... And the game play too fast... I wonder, maybe the floppy we have was patched for PAL machines (50hz), even if they kept the original height (240 lines) ?

[mithrendal]

with the sound the problem is I think that it now produces too much samples ... but the audio host interface consumes to few samples ... maybe have to adjust the sample rate on the host system when going to 60Hz too ? We must ask @dirkwhoffmann

[Vweber73]

I see... There is hope maybe ! :) Cheers

[Vweber73]

Hi,
Not sure how it happened, but i got this exception this morning when I came back to the app. Although it continues to run fine...

[mras0]

RE: NTSC/PAL (I haven't read every post). I'm quite sure vAmiga is currently hard-coded to emulate a PAL Amiga driving a PAL display only. Proper NTSC support is more than just changing the number of scanlines and display frequency as it also alternates between long and short lines (which have a different number of color clocks from Agnus's perspective).

A NTSC Amiga will run everything slightly faster (~7.14 vs ~7.09 MHZ), and in general games on a NTSC system will probably look smoother due to the higher display update frequency (and fewer number of pixels per frame), but it really depends on a lot of stuff.

Interceptor seems to run in 320x200 regardless of whether it's a PAL or NTSC Amiga (on a PAL it just leaves off the bottom part of the screen) so it'll probably run faster on a PAL amiga but maybe it looks slightly off (due to the aspect ratio being different). It's really slow on an unexpanded Amiga though, so an overclocked CPU with fast ram helps a lot more.

[Vweber73]

@mithrendal Just got something that surprised me. I was in a place with no network. VAmigaWeb refused to launch, wanting to access a URL. So, the PWA is not completely offline ?
@mras0 Many thanks, very enlightening as usual :)

[mithrendal]

@mras0 thanks … then it needs more then simply do the ntsc pixel aspect ratio and the higher display frequency… interesting … but when I call amiga->execute() 60 times instead 50 times in a second does this not also affects emulated timing?

@Vweber73 Here on iPhone… flight mode … cold start the app … it complains no network on start but when I dismiss the message then it start up vAmigaWeb as regulary … I think it tries to lookup for a new service worker on the net as this is the only ressource which I do not cache … I am supposed to cache it too?🤔as for the JavaScript error of your screenshot. I need the JavaScript error from the console…

I am currently in the depths of opengl 3 shaders for the pixel precision which is not as clean as when rendered with the software renderer

[Vweber73]

Re NTSC, yes, I guess that with the NTSC pixel ratio and overclocking you can get close to reproduce NTSC games as intended...

Re offline mode, the first time I got the fix Amiga logo only on the page then a complaint that a URL could not be opened; second time I got this, see attached... I guess everything should be cached, yes !

Good luck with the GPU renderer !

Thanks and cheers

[mras0]

@mras0 thanks … then it needs more then simply do the ntsc pixel aspect ratio and the higher display frequency… interesting … but when I call amiga->execute() 60 times instead 50 times in a second does this not also affects emulated timing?

Amiga::execute runs until certain flags are set. Usually that'll be RL::SYNC_THREAD set by Agnus::vsyncHandler() giving you the expected one-to-one correspondence between calls to execute and frames. If you call it 60 times per second everything will be running at 120% speed including audio, but the relative timing will stay fixed.

At least that's my prediction. Give it a shot and see what actually happens :)

[mithrendal]

Give it a shot and see what actually happens :)

I have opened it to the javascript API so the FPS can be changed by the user with an ActionButton

@mras0 yes the web audio api interface does not consume all of the produced sound samples in 60Hz... running in sound buffer overflows issues

made separate issues for problems mentioned here
#93 #94

closing this issue now ... as the screen sizes seem to be ok now 😎

[Vweber73]

Just one little thing with screen sizes: if you select narrow and bring the virtual keyboard, the top of the screen is a bit cut, unless you remove the menu bar with the button meant for it... reopen ?
Cheers

[mithrendal]

The question is here whether we want

1. the menu bar on top of the emulated amiga screen with a transparency so that amiga screen is shining through (like it is now)

or

2. should the amiga screen height be reduced by the menu bar height, if height of menu bar + amiga screen height + keyboard height exceeds the total device screen height

when doing 2. in your case it would also reduce the amiga screen width and give you very small borders on the sides when correct displaying aspect ratio...

[Vweber73]

Well, you forgot one thing. I've got a Z3. With plenty of space. See attached. Still a waste of real estate ! ;)

[mithrendal]

Ah now I see ... a picture says more than thousand words ;-) ... in that case we have more options

1. reduce the height of narrow a bit
2. make a new narrow NTSC display size reduced by 48 Pixels (cuts the black bottom border)
3. when NTSC pixel aspect ratio is selected reduce the heights of all fixed display sizes (i.e. narrow, standard, wide, overscan) by 48 pixels
   (according to: The PUAE core's base height is 288 for PAL single line, 576 for PAL double line, 240 for NTSC single line, 480 for NTSC double line)

[Vweber73]

Actually it is not only narrow. all resolutions but Borderless has the same small issue...

[mithrendal]

then maybe we should do the option 3, what do you think ?

BTW: did you see dirkwhoffmann/vAmiga#700 ? Real emulated NTSC might maybe happen soon ...

[Vweber73]

But it's not specific to NTSC, it happens in PAL also.
The only thing I would like is to move the Amiga screen a bit below, closer to the keyboard...
Yes, thanks, great about NTSC mode coming !
Cheers

[mithrendal]

But it's not specific to NTSC, it happens in PAL also.

understand ... but NTSC is taller so it happens on even more devices that the AmigaScreen height is bigger than device screen height - menu navbar height

The only thing I would like is to move the Amiga screen a bit below, closer to the keyboard...

I understand .. but see ... the black area on your picture between keyboard and interceptor cockpit belongs to the AmigaScreen ... you want to move the complete screen down a bit ... ok, but what if the AmigaScreen is used completely by some other AmigaSoftware/Games ... in that case the screen would be cut off at the bottom ... you trade bottom cutoff against top cutoff ...

What you want is to make the AmigaScreen height a bit smaller so that

navbar height + keyboard height + Amiga screen height <= heigth of your device e.g. Z3 Fold

you get this by using borderless .. because this strategy reduces amiga screen height to the height which is used by the amiga software. Or we can get it be defining new display area sizes which are not that tall as the current ones... or solution 3 from above

[Vweber73]

Ok I see, sorry I was mistaken ! Let's go for that.
Cheers

[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