Re: [hatari-devel] Pixel aspekt ratio

Alright, since we've now shown Closure at STNICCC it's time to revisit this thread.

We had two high color pictures shown in fullscreeen in Closure - one logo for our musician 7an (Amplitude Problem) and one aquarelle painted by our graphic artist BlueSTar. That is, we knew very well what these pictures were supposed to look like :)

Converting them to display format (using Doug's excellent PhotoChrome 6.2 suite) and writing a display routine was no problem - and it looked just right in Hatari. However, when displayed on target hardware (no matter if we used monitors or TVs or projectors) the pictures were stretched vertically - and quite visibly so.

After having done the research (Atari pixels have 0.9/1 aspect ratio) we stretched the source images with a factor 1.11 horizontally and then re-did the conversion. Now it looked perfect on target hardware - and "squished" in Hatari.

tl;dr: There should be an option to perform correction for aspect ratio in Hatari. It might not be used by everyone (since it would not be pixel-perfect and cause aliasing) - but when creating demos that should look ok when displayed on target hardware (with monitors, TVs and projectors .. ) it's needed to understand how to create graphics that don't look stretched.

This holds true for all displays we've tested on. And no, people don't usually go and modify the aspect ratios of their TVs and projectors. And likely not at demo competitions :P

/Troed

On Sat, Nov 14, 2015 at 12:42 AM, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:

Hi,

On 12.11.2015 17:14, Troed Sångberg wrote:

Of course there is. NTSC 525 lines, PAL 625 lines, from top to bottom
evenly spaced. The reason why Atari decided to "start" the NTSC screen at a
specific line, the PAL screen at another line etc to make sure the full
usable screen was visible on any screen the user might connect to.

Number of lines != pixel size.

_Some_ monitors included the possibility to "zoom" in on the picture since
the decisions were made with TV sets in mind, but that doesn't change what
the designed - "correct" - pixel aspect ratio of the platform was..

Which Atari monitors don't include knobs for the picture size?

(My Atari SM124 at least had them.)

(0.9/1 apparently)

In Atari RGB or VGA monitor, or both?
In Atari ST or TT monochrome monitor, or both?

As to "correcting" pixel aspect ratio:

* While some of the modern monitors may have square pixels, you cannot assume that, as there's no reliable way to get that information from the host OS. AFAIK most of the systems just give bogus DPI values for the monitors.

* IMHO scale ratios close to one, like 1.1 & 0.9, produce pretty ugly results, at least when I've last tried them. Antialiasing can help, but then the result is blurry. Personally, I much prefer exact pixels.

I think your best option is to get CRT monitor and adjust the image aspect ratio to match ST. :-)

- Eero

A discussion of the same on the Amiga (which apparently was very close to
1/1 in PAL): http://eab.abime.net/showthread.php?t=50015

An emulator doing this for the Atari 800:
http://www.emulation64.com/view/2067/Atari800-v220-/

And here on how you need to compensate when viewing Atari ST images on a
modern screen: http://matsp888.no-ip.org/~mats/Images/Atari%20ST/

I would very much like to have the option (using SDL2) to scale the
vertical resolution by 1.11 in Hatari. I can't have been the only one to
have been caught a bit of guard making something on a modern computer which
looks good in the emulator but didn't when I ran it on target hardware. As
Nicolas points out this will not be pixel perfect so it's not something to
enable by default.

(As to what the exact value should be I can't offer more input than the
previous quote by an Atari ST pixel artist which seems to have perfectly
matched what I saw myself)

/Troed

On Thu, Nov 12, 2015 at 3:41 PM, Adam Klobukowski <adamklobukowski@xxxxxxxxx

wrote:

I do not know about TVs, but with ST monitors, user could stretch screen
width and/or height with a toggle, so there is no way so specify correct
aspect ratio, as there is none.

Adam Klobukowski

2015-11-12 12:54 GMT+01:00 Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

Le 12/11/2015 09:58, Troed Sångberg a écrit :

Recently I realized that graphics I made on my Mac and displayed in
Hatari did not look the same as when I viewed it on my ST. On the ST
everything was stretched out vertically.

I couldn't really understand why, so I started looking for discussions
on Atari ST pixel sizes, and found the following:

"and later on the 16-bit Atari ST (low-resolution 320×200 pixels) each
pixel was roughly .9×1"

https://mmolyneaux.wordpress.com/category/atari-st/

Going by the above I stretched the graphics by a factor 1.11
horizontally and all of a sudden a photo taken from the graphics as
displayed on the ST matched perfectly what was displayed in Hatari.

Is this a general thing with modern monitors having square pixels so
that an emulator with 1:1 mapping will always display things "compress"
vertically compared to what was originally designed for target?

If so, should Hatari offer the option to not do 1:1 mapping but stretch
vertically to try to display content as close to what it would look like
natively?

Sorry if this is a topic that has been debated to death before, it was
new to me when I stumbled upon it.

Hi

that's something I already read about, but I don't think it was debated
here.

Problem is : how do you stretch horizontally for example (or vertically
in the other direction, that's the same) to not get visible artefacts ?

If we consider a 320x200 ST image should be displayed on a 352x200 area
on modern display, this means that at one point 32 pixels will need to be
duplicated. Which ones do we chose ? Going from 320 to 352 will sure look
ugly.

So, to get proper 1.11 ratio we need a much bigger zoom before, maybe x4
or more. A 320x200 ST image would become a 1420x800 area ; with such an
increase you can apply some more effective filters for non integer zooming.

In the end, I think it comes down to another request already made here :
being able to zoom the ST image to any non-integer value. Today, we only
have x2 zooming, with SDL2 and some additional code, we could have for
example x3.3 zooming using HW accelerated opengl and some filters.

Nicolas

--
Semper Fidelis

Adam Klobukowski
adamklobukowski@xxxxxxxxx