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

Internet Message Format | 1993-01-03 | 6.8 KB

Path: sparky!uunet!spool.mu.edu!olivea!bunker!nuconvex!starpt!doiron
From: [e-mail] (Glenn Doiron)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Chunky Pixels vs. Bitplanes (was: Chunky Chip Set...)
Message-ID: <[e-mail]>
Date: 3 Jan 93 14:59:34 GMT
References: <[e-mail]> <[e-mail]>             <[e-mail]>
Organization: 68K Software Development
Lines: 153
X-NewsSoftware: GRn 1.16f (10.17.92) by Mike Schwartz & Michael B. Smith

In article <[e-mail]> [e-mail] (Michael van Elst) writes:
> In <[e-mail]> [e-mail] (Glenn Doiron) writes:
> >... and you still haven't convinced me that chunky isn't faster.  As was
> >said before, the best you can hope for is break-even, and far more often
> >chunky will be faster - the bigger the blit, the smaller the difference.
>
> The difference vanishes if the bitplanes are well aligned. Otherwise, except
> for tiny bitmaps such as single pixels, the difference is neglible.
>
> Remember, it is a tiny difference since only borders are affected in most
> operations. Bitplanes will win if you can strip whole bits from all pixels
> (i.e. cut down on pixel depth).

I rest my case.

> >As I said, you lose all the performance gains VRAMS were supposed to give
> >you in the first place, since you can't use the serial registers for video
> >fetch in planar setups.
>
> I wouldn't be so sure :)

This was suggested to Commodore over 2.5 years ago.  However, it never made
it into AGA.  It probably has something to do with the planar architecture
of the Amiga :)

> >Chunky has this property too, although only to a power of two.  This
> >however, is not nearly good enough justification for all the penalties you
> >get in planar doing everyday operations.  Why use a lesser number of colors
> >when you can use more for the same, if not better, performance?
> >
>
> Using more colors (more bits per pixel) will always degrade performance.
> But in bitplanes you could f.e. use 1024 colors instead of either 256 or
> 65536.

Yes, but you could use 256-color chunky pixels instead of 1024 color planar
pixels and chunky would be faster.  I still, however, don't understand why
you are using scaling like it's the next best thing since the Amiga, you
are operating under reduced capacity.

> >No.  It is not.  You are doing N time the amount of work in planar, where N
> >is the number of planes.
>
> Sorry, not at all.

Well... not in my line of work.

> >Best of luck to you.  You are talking really expensive hardware now.  Not
> >something you'd tack onto an Amiga, or anything, since chunky is here now,
> >costs less, and doesn't have any of these deficiencies to which your
> >special-purpose hardware would address.
>
> >Nope.  "Special case".  You can't use the same algorithm to stretch that
> >32x32 image into, say, 64x57 or shrink it to 17x13.  You might be able to
> >do 64x32 or 32x64.  But that's still a special case optimization.
>
> Well, it is a bitmap scaling by an integer factor. Anything else needs
> filter operations.
>
> >Shifting is too slow on almost any general purpose processor, not just the
> >68000.  Irregardless, you need to do a lot of shifting/masking, which isn't
> >going to be free on --any-- processor, although custom chips can go a long
> >way towards hiding this via pipelining/superpipelining.
>
> It isn't a long way. There's really no problem to hide shifts behind
> memory accesses if you stay with reasonable word lengths. Maybe a 128bit
> barrel shifter would be too slow.
>
> >Can you use that table to do another transformation, as noted above?  No.
> >It's a special case optimization.
>
> Can you use your chunky bitmap scaling routine for another transformation ?

You can use the same algorithm to scale an (x1 by y1) area to an (x2 by y2)
area.  And adding rotation means a few boundary checks, as well as the
difference between

(inner loop)
 x'=x * (1/xscale)
 y'=y * (1/yscale)    ;which does scaling
 getpixel(x',y'): putpixel(x,y)

 xrot=cos(theta)/xscale
 yrot=sin(theta)/yscale
(inner loop)
 x'=x * xrot
 y'=y * yrot    ;which will do your scaling and rotation in one fell swoop.
 getpixel(x',y'): putpixel(x,y)

The key to why chunky is so much faster lies in the last getpixel/putpixel
pair.

> >few break-even cases.  Sometimes it will even be faster on chunky *even
> >with a reduced scale for planar*, since chunky doesn't need 'bit
> >thrashing'.
>
> "Doesn't need" is wrong unless you operate on a memory that is one
> pixel 'wide'. You hardly do.

I've put up an algorithm that clearly shows why chunky is ridiculously
faster, using a general purpose algorithm that can scale/magnify/rotate any
image to any degree (no sanity checks :).  You're welcome to continue to
argue, but I really think that for all intents and purposes I've proven my
point.

> >In all cases, you've admitted that chunky is faster than planar (w/
> >exception of you special case optimization where it breaks even).  I rest
> >my case.
>
> ...and silently forget depth scaling.

OK, ok, take your depth scaling.  Your welcome.  As I said before, if you
want to cut down to 128 colors, why not just go to 16?  Chunky would be
faster THEN.

> >Would help if you didn't delete too much from the above references.
> >Plotting an alternating color horizontal line will still be (w/ 8-bit
> >color) 8x faster on chunky than planar.  Plotting every other pixel a
> >different color isn't going to make planar faster.
>
> Plotting an alternate color horizontal line is same speed. You simply
> determine the pattern you have to mask through.

Bingo.  Chunky is still faster.

> >:)  Look, if you want a 128-color display, I won't forbid you from using a
> >planar architecture.  However, drawing a line will be far faster on a
> >256-color chunky than a 128-color planar display.  If you need a
> >4,16,256,65536, or true-color display, however, your losses using planar
> >will be even more dramatic as the number of colors goes up, since you are
> >wasting 2x, 4x, 8x, 16x, or 32x the amount of time accessing irrelevant
> >data (still not counting shifting/masking).
>
> No. With single pixel lines the losses are determined by the word length,
> not the number of planes. Wether you write 8bits per pixel or 24bit per
> pixel. The _ratio_ is still the same.

Your correct, the _ratio_ is still the same, but the _amount of time_
wasted goes up incrementally, 2x, 4x, 8x etc.

> 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."

Glenn Doiron
--
Amiga UUCP+
Origin:  uunet.uu.net!starpt.UUCP!doiron (Organization:68K Software Development)
         BIX: gdoiron
** Not enough memory to perform requested operation.  Add 4 megs and retry.