NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/amiga/programm/17840

Text File | 1992-12-27 | 3.9 KB | 78 lines

Newsgroups: comp.sys.amiga.programmer
Path: sparky!uunet!wupost!spool.mu.edu!yale.edu!ira.uka.de!fauern!Germany.EU.net!mpifr-bonn.mpg.de!specklec.mpifr-bonn.mpg.de!mlelstv
From: [e-mail] (Michael van Elst)
Subject: Re: Chunky Pixel Mode for Low End Chip Set?
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: specklec
Organization: Max-Planck-Institut f"ur Radioastronomie
References: <[e-mail]> <[e-mail]>       <[e-mail]> <[e-mail]>     <[e-mail]>   <[e-mail]><[e-mail]  > <[e-mail]><[e-mail]> <[e-mail]>
Date: Mon, 28 Dec 1992 00:05:31 GMT
Lines: 65

In <[e-mail]> [e-mail] (John Bickers) writes:
>    You're kidding, right? Sure it's _possible_ to do it with planes,
>    but don't you think it is easier (and it is definitely faster) to
>    do it with chunky pixels?

No kidding. You are right that it is _easier_ with chunky pixels, but it
isn't necessarily slower. At some point memory bandwidth determines
execution speed and as long as an image needs the same memory it will
be processed (about) equally fast. My point is that quite often you
can live with a lower _depth_ of an image. A chunky pixel display
will still require processing of the full depth while a planar display
lets you strip extra bits.

>    Well, it should be. Bypassing WritePixel() with chunky pixels will
>    be quicker than bypassing WritePixel() with planes. There is only
>    one address calculation, and only one write to memory.

Well, I'm not really talking about bypassing a routine and killing
RTG compatibility.

>> Yep, drawing thin lines is a plus on chunky pixel architectures. Floodfills

>    Any kind of lines.

Nope. When you start to make lines thicker than 1 pixel you have to
fill polygons which has some advantages on bitplanes.

>> on the other hand can be faster with bitplanes. Not sure about curve drawing

>    I don't see how flood filling can be faster with planes. The
>    classic method is mostly ReadPixel() and WritePixel() operations,
>    which chunky pixels excel at.

:) Hmm, the classic method is using Flood(). There's nothing that forbids
the graphics.library to access the hardware and use every optimization.

>> but most curve drawing routines I know need several multiplications per point.
>    So? There are incremental algorithms for drawing some sorts of
>    curves (like circles), and having chunky pixels isn't going to
>    make the calculation of the curve faster, but it WILL speed up the
>    WritePixel() part of the routine significantly.

True. But the WritePixel() (noone will use WritePixel !) part is only a
small part of the rendering operation.

>    Anyway, I'm all for a chunky pixel chipset. Even better if it can
>    be mixed with other modes on-screen. Not being a hardware person,
>    it's easy for me to think that the best way to handle graphics
>    boards (with RTG) would have been to have the Copper be able to
>    switch to an external graphics source, so external boards could be
>    "screens" in the system, scrollable and all. Being able to do this
>    without an external graphics board at all would be great.

One problem with simply switching video sources is that you have to adjust
where the screen appears. This requires at least some support on the
exernal card. It is also quite impossible to mix different scan frequencies.
If your high-end graphics board does 1280x1024 you can't mix that with
native Amiga screens.

Regards,
--
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: [e-mail]
                                "A potential Snark may lurk in every tree."