[cc65] TGI aspect ratio values in the drivers

Hi,

Another aspect of TGI we discussed then was the handling of aspect
ratios. Uz introduced an aspect ratio field in the TGI driver header
but up to now this field was simply set to an aspect ratio of 1:1 for
all drivers (apart from some Atari drivers which set it to 2:1 or 4:1
to indicate half or quarter of the normal x resolution).

I wanted to set the aspect ratio field in the drivers to some
resonable values and discussed with Uz the options for determining the
values. He proposed to approximate them by just presuming a classic
CRT with an aspect ration of 4:3.

I still remember that there were quite some misunderstandings in our
discsion so I'll try to be as exact as possible this time sticking to
the terminology used i.e. here:
http://en.wikipedia.org/wiki/Pixel_aspect_ratio :
- pixel aspect ratio (PAR)
- display aspect ratio (DAR)
- storage aspect ratio (SAR)

The three values are related by the identity SAR × PAR = DAR.

DAR is presumed as 4:3.
SAR is defined as the x resolution divided by y resolution of the TGI driver.
PAR is what we want in the TGI driver header field.

So I changed the PAR in all TGI driver headers to the (rounded) result
derived from the the above DAR and SAR.

Two remarks:

1. I'm well aware that especially the C64 community has more accurate
ways to determine the PAR (dependent on PAL or NTSC display). However
I felt that using the formula above for all TGI drivers in a
homogenous way is preferable. If someone else nevertheless feels that
it is necessary to finetune the C64 value I'd ask to change the C128
and GEOS values in the same way for consistency reasons.

2. According to my research the Lynx LCD display has in fact square
pixels so I left the PAR in the Lynx driver header to 1:1.

Some words on the usage of the PAR in the TGI driver headers:

The TGI kernel does *not* use the PAR to justify graphics primitives
(especially circles). The two primary reasons are:
- The TGI Kernel doesn't know if it should shrink graphics primitives
one dimension or rather expand them in the other dimension.
- If a TGI application i.e. draws an (imperfect) square from four
individual lines with equal length and then a circle in the center it
is entitled to presume that the circle touches the square on all four
sides - even if that means the circle is imperfect too.

The one exception from the statement above might be in the future the
text output using vector fonts - because there the application can't
make presumptions on the actual pixel size anyway.

So the PAR in the TGI driver headers is rather to be used by the TGI
application. Two new functions have been introduced by Uz for access:

unsigned __fastcall__ tgi_getaspectratio (void);
/* Returns the aspect ratio for the loaded driver. The aspect ratio is an
 * 8.8 fixed point value.
 */

void __fastcall__ tgi_setaspectratio (unsigned aspectratio);
/* Set a new aspect ratio for the loaded driver. The aspect ratio is an
 * 8.8 fixed point value.
 */

The final helper functions to simplify working with the 8.8 fix point
values are still to come. However Uz already provided a preliminary
one. I used it in the DoCircle routine in the TGI demo program in
order to facilitate some first visual experience of the changed PAR in
the TGI driver headers.

Regards,
Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.