Re: [cc65] TGI pixel aspect ratio

Hi Groepaz,

>> See what I mean ? ;-))
>
> yes, see my other post. what you mean is NOT pixel aspect ratio :) pixel
> aspect ratio refers to a SINGLE pixel, it is completely unrelated to the
> resolution, size, or aspect ratio of the display.

If you check my postings carefully you'll notice that I never said
that 'pixel aspect ratio' refers to the resolution, size or aspect
ratio of the display!

However I disagree with your statement that the 'pixel aspect ratio'
is unrelated (not even talking about 'completely unrelated') to the
resolution, size or aspect ratio of the display.

> both the c64 (hires mode)
> and the VDC have a pixel aspect ratio of ~ 1. (not quite obvious for the VDC,
> indeed - but "pixel" doesnt include the black space between actual pixels).

Maybe the VDC is a special case, I surely don't have enough knowledge
to argue about that. But anyway I don't see where this differentiation
should lead us to. If you want to display a circle not as an elipsis
(picking up your example) then the appropriate model is to have
adjacent pixels, because these are the enitites you can control.
Dividing those entities into pixels and space between pixels doesn't
bring you anywhere. So with the term 'pixel' I from here refer to the
whole area up to the next pixel.

Although theoretically the display aspect ratio and the pixel aspect
ratio are of course different values they are in fact _directly_
related to each other as soon as you have a fixed screen aspect ratio,
which is the case for all cc65 targets meant to display on (classic)
TV screens or monitors with identical display aspect ratio. The Apple2
and C128 are examples for this - sorry for not mentioning this fact
;-)

In general a CRT display is generated by some pixel clock. And that
pixel clock typically has a "normal" rate. That rate is typically
adjusted to yield a pixel aspect ratio of ~1. Because of the fixed
screen aspect ratio this directly results in a resolution aspect ratio
similiar to a (classic) TV screen.

For the Apple2 this resolution is 280x192 and for the C128 it is
320x200. Now that I showed why these display resolution directly
relate to an pixel aspect ratio of ~1 it is quite easy to see that the
resolutions mentioned by me (560x192 and 640x200) directly relate to a
different pixel aspect ratio.

Not surprisingly resolutions like 560x192 and 640x200 are produced by
running the pixel clock at double rate. The ability to do so tends to
be related to the support of 80 col text displays.

On the other hand there are sometimes graphics modes with higher bit
depth and because of memory access bandwith (or other) limitations
these modes require the pixel clock to run at half rate.

Result: There seem to be quite some interpretations what this thread
is about. However my understanding of this thread is that the driver
could/should basically provide the information if it runs the pixel
clock at a rate resulting the usual ~1 pixel aspect ratio or if it
runs at double/half speed.

> to achive what you are talking about, it makes more sence to me to define the
> aspect ratio of the DISPLAY (that can be done in a macro, i dont think any of
> the targets can change it). then what you need can be calculated from the
> display resolution:

I don't see any point in defining the aspect ratio of the display. The
TGI API already has tgi_getxres() and tgi_getyres() which allow to do
whatever necessary in that area.

Howevery when trying to draw a circle (as in your example) or a 45
degree diagonal line (as in 3dmaze) the program is not interested in
understanding the display aspect ratio but in understanding the pixel
aspect ratio.

> sorry to be pedantic about this.... but after extensivly reading up on the
> subject years ago (because i was doing image processing/converting) all the
> confusion and half-accurate things "out there" make me protest :)

BTW: I've been doing the same to make a living for some time.

So why did I mention those two resolutions in the first place at all?
Because I didn't want to talk about pixel aspect ratios of 0,93 or
1,07. The reasons:
- Trying to adjust for those seems overengineering to me for a 6502 program.
- The missing float support in cc65 doesn't make it exactly fun to
deal with those values.
- Most cc65 programs run today in emulators just ignoring those
deviation altogether.

Rather I wanted to talk about those double/half pixel clock rate modes, because:
- They can be easily descibed by a single integer value.
- They are so obviously visible that is urgent to adjust for them.
- Emulators implement them so there's a need to adjust for them when
running in emulators.

But I thought talking about double/half pixel clock rate modes might
divert attention from the proposal I wanted to make, therefore I
started out with two popular resolutions. But somehow this doesn't
seem to have worked out that well ;-)

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