Date   : Fri, 02 Apr 2004 22:19:57 GMT 
From   : "Thomas Harte " <thomasharte@...>
Subject: Re: Aspect ratio question

> > Total time over which pixels are output = 59 chars
> > left border: 10 characters (output chars - position of sync)
> > pixels: 40 chars
> > right border: 9 characters (position of sync - number of chars)
>
> Not quite.  The right border is indeed the interval after the displayed
> character cells (position of sync - number of chars).  The left border
> is however (output chars - position of sync - sync width) -- which I
> think is what you meant, because 63 - 49 - 4 = 10.

Indeed that is what I meant. I typed output chars meaning it to refer to
the value on the line immediately 
above.

[...]
> I don't understand what you mean by the rest, at all.  I can't see why
> you're trying to take some fraction of 312 lines -- sure there are 312
> (and a half, with interlace) lines in a field, but what's that got to
> do with the price of bread?  I'm not being sarcastic or anything, I
> really don't understand what you're trying to calculate.

I started with the assumption that the entire region for which the CRTC outputted
pixels appeared on screen. 
Even though we know that isn't true. I then worked out how many scanlines
would need to be displayed in order 
to generate square pixels if that were the case.

> 59 character cells (as you calculated) or 53 (according to me) is 4/3
> of the maximum possible image height, but that height is 288 scan
> lines.  Also, I don't understand why you're multiplying anything by
> 4/3.  Are you trying to match pixels?  You need a factor of 5/4 for
> that (image resolution 320 x 256).

I seem to have been calculating how many scanlines would need to be displayed
if we were to get a square 
output with a square number of pixels. Which was very silly of me. What I
was thinking was: a square which 
takes up m/nths of the horizontal area of the screen needs to occupy m*4/n*3ths
of the vertical area to be 
genuinely square.

Which is very interesting, but as you point out, beside the point. 

> > so what we genuinely want 40/56*4/3 of 312 - 20/21*312 - 297
> > active display scanlines.
>
> No, we want 40µs out of a possible 52µs, not 40/56.

Well, clearly I've simply made a mistake here also. Indeed my entire earlier
post should clearly be disregarded.

> > The defined PAL visible area in scanlines is 288, so if we had a TV
> > screen that displayed all 288 scanlines, we'd
> > then want it to display just over 55.23µs of active display to get
> > square pixels.
> 
> Sorry, but I don't follow.  I can't see where 55.23 came from, using
> any of the numbers on those lines.  Is there a typo in there somewhere?

No, it was assuming an even scaling of the whole image to make 288 scanlines
visible.

As you point out though, the correct number to be playing with is 52, not
56. I knew that result of 55.23 was 
far too neat to be right!

So, I'll try again. From the top:

BBCs use 40µs of 52 to produce an image n pixels wide. We want to know: how
many scanlines must the entire 
display have if, in our imaginary world, all 52µs were visible and we want
square pixels? 

We want to produce an image 4/5s as high as wide. And we need to scale that
further by 4/3 to undo the fact 
that the PAL region is defined over a 4:3 region rather than a 1:1 - as we're
really only thinking about 
proportions of the total available signal for now.

40/52 * 4/5 * 4/3 = 32/39

i.e. our image would need to fill 32/39ths of the total vertical area if
it fills 40/52 of the horizontal. If we 
consider that we have 312 scanlines then look at that: we need to fill 256
scanlines! [*]

But, alas, even in our ideal world we have only a TV displaying the defined
PAL visible scanline count of 288. 
Then to keep square pixels we need assume that the visible portion of the
image has been scaled by 288/312.

Which means we only keep square pixels if your PAL TV displays 48µs of visible
data per line compared to a 
perfect 288 scanlines.

Therefore pixels are only 12/13ths as wide as they should be. Now, recall
that earlier I asserted that you'd 
want to use 45/52ths of the displayed width of a 4:3 screen to display BBC
graphics at the correct aspect ratio 
if you had scaled the image so that the entire height of the output was occupied
by BBC graphics? Whereas you 
maintain that 30/32nds is the way to go? i.e. I end up with around 886 pixels
across in a 1024x768 mode where 
the x768 is just the 256 scanlines of BBC display, whilst you end up with
960 pixels.

Well: (45/52) / (30/32) = 45*32 / 52*30 = 1440 / 1560 = 12/13.

Spooky, no? And could [*] not be the reason that many have been fooled into
thinking pixels are genuinely 
square? As you have pointed out - overscan is easy to forget.

-Thomas

Lycos Email has 10 MB of FREE storage space. http://mail.lycos.co.uk