Date : Wed, 31 Mar 2004 12:29:48 GMT
From : "Thomas Harte " <thomasharte@...>
Subject: Re: Aspect ratio question
--=_NextPart_Lycos_0218721080736188_ID
> BTW, how come your posts have such short lines? It makes it incredibly
> difficult to read...
Its the disadvantage of using one of the web's most rapidly deteriorating
free email services! They used to
offer pop3 access, but then they decided to charge for that, and I'm not
really sure why the web interface
keeps wrapping at ~20 characters. I think it might be a Mozilla thing, and
am posting this from IE in earnest.
If I didn't need a stable email address then I'd probably swap in an instant.
> Well, OK, but the real answer is found in the dimensions, measured in
> pixels or OS units (so long as you know that they're square, or
> whatever). And the ratio is 5:4.
> > The fact is that a Beeb displays pixels,
> > and an emulator must display matching pixels if
> > it's to be accurate.
[...]
> > Something that turns two pixels into three can't display that
> > correctly.
>
> Yes it can. Check the comp.graphics.algorithms FAQ for various ways
> of reinterpretting sampled signals that amount to image
> scaling with a much greater display quality than you imply is
> possible.
> I've done my share of graphics manipulation, and whilst I'm not an
> expert to the extent that some of the FAQ writers are, I know that
> there's a big difference between doing that for an ordinary image and
> doing it for fine line graphics. It simply doesn't work for fine line
> stuff, in any implementation I've ever seen. You always get aliasing
> or some degree of incorrect line spacing, unless the scale factor is an
> integer.
>
> > See http://electrem.emuunlim.com/images/AcornUserMode7.gif
> > for an example of such a scheme in action, displaying a
> > Mode 7 display at the correct width - i.e. the same width
> > as the normal display, not significantly thinner as many of
> > the older emulators are forced to.
>
> I don't quite understand what you're getting at here. That image is
> 640x512 pixels, which is 5:4 (as I've said) and it looks about right
> when I compare it on my 1280 x 1024 correctly-adjusted (so circles are
> circles) to the BBC Micro screen beside it.
The teletext chip produces a 480 pixel output (individual charaters are 12
pixels across, the display is 40
column). What you are looking at is a non-integer width stretch of a fine
line image. Of course you may not
have realised this because you have your monitor set to some gigantic resolution
and so the web browser
display of a 640x512 image wasn't large enough for you to make out the difference,
but I think it demonstrates
that stretches of fine line images can be perfectly presentable.
> I don't use MS Windows so I can't see it. However, your description of
> an overlay surface isn't what I understood that to mean. I thought you
> were talking about DirectDraw (or whatever it's called) overlay
> surfaces, where the image is interpolated by the hardware -- no clock
> changes.
I am talking about what DirectX, and the equivalent interfaces on other platforms
refer to as an overlay
surface. But many years ago when I asked a friend who worked at the time
for S3 why overlay surfaces had
such strict rules about the sizes they may be scaled to, he said that on
the whole they were produced by a
second pixel generator and overlaid as a signal switching thing at the last
minute. He contended that to do a
simple hardware interpolation made less sense because you needed a fair amount
of difference circuitry in the
first place to handle the different colour space. Which always confused me
because the vintage S3 cards are
the only ones I've ever seen which support RGB overlays in addition to the
commonplace YUV.
> Well, many TVs are slightly out of adjustment, unfortunately. If both
> are properly adjusted, it shouldn't be any different on a TV or a
> monitor, since we're talking about PAL-standard (or mono equivalent,
> with the same timing) monitors. The reason so many people used
> monitors on Beebs was simply that the higher resolution screens look
> awful on colour TVs -- the TV bandwidth is too low and text in Mode 0
> or Mode 3 looks crap (and hard to read).
Oh, yeah, I can imagine that. Not that modes 0 or 3 were ever very useful
to us Electron owners - what with
the clock rate dropping to an equivalent of something like half a megahertz
in those modes.
> > I invite an explanation of how my calculations are incorrect.
>
> OK. You describe taking 40 microseconds out of 52, which is 10/13.
> But then you take that fraction of 1024 pixels in a 1024 pixel screen.
> That's not right; the 52 microseconds on a PAL-compatible display
> extends beyond the viewable area within the outer bezel of the screen,
> but the 1024 pixels doesn't, in fact on a normal CRT there's a
> considerable margin on each side of that 1024 pixel wide area.
> Similarly, you take 256 scan lines out of 288 displayable, which is
> about 9/10 (0.88888...) but again fail to note that some of those
> "displayable" scan lines are off the top and bottom of the viewable
> area. This is called overscan. Therefore your ratios are wrong.
What I actually did was calculate what proportion of the entire defined PAL
visible area that the Acorns use,
then scale that so that the 1024x768 screen covered only the used region,
but without distorting the image
during scaling. So I allowed for overscan and then some. I'm not interested
in making your monitor display
exactly the same image as an equivalently sized TV, just in making sure that
the image it does display is the
same proportion of width to height.
My original question was "am I right in thinking that the display modes 0,1,2,4
and 5 (3 and 6 being a small
amount shorter, of course) should produce a display approximately 1.14 times
as wide as tall?", the stuff about
what this means with a 1024x768 display was merely incidental. And I don't
think it is 1.14 anymore, I now
believe that the display should be 45/38ths as wide as tall (as a natural
result of the calculations already
posted). Which is somewhere a little over 1.18.
Anyway, when I'm near a real machine in a week or so, I will go to a joined
up graphics mode, type "draw
1280,0:draw 0,1024" (or draw 1280,1024 if draw commands aren't relative,
and I can't really remember right
now), get out a ruler and measure the two lines. A shatterproof ruler, obviously,
because my TV screen isn't
flat. Then we'll have a definitive answer!
> You're measuring the wrong things, I think. I'm just saying that the
> size is a function of the displayed pixels, which are square
I'm just saying: I don't see how they can be square from the clock rates,
and they never looked square to me.
-Thomas
Lycos Email has 10 MB of FREE storage space. http://mail.lycos.co.uk
--=_NextPart_Lycos_0218721080736188_ID--