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

Internet Message Format | 1993-01-03 | 5.4 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: 4 Jan 93 00:23:15 GMT
References: <[e-mail]> <[e-mail]>              <[e-mail]>
Organization: 68K Software Development
Lines: 120
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:
> >Yes, but you could use 256-color chunky pixels instead of 1024 color planar
> >pixels and chunky would be faster.
>
> Simply to get more colors when needed.

However, that is entirely besides the point.  I will say that planar is
more versatile than chunky wrt scaling back colors, however, the point is
moot on everything except the Amiga's chip set.

> >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.
>
> Because often you don't need full capacity. Using screens with different
> resolutions is one solution to the problem. Having layers that simply
> leave bitplanes untouched is another solution.
>
> A very popular example for this is a text window on top of a coloured
> background.
>
> >(inner loop)
> > x'=x * (1/xscale)
> > y'=y * (1/yscale)    ;which does scaling
> > getpixel(x',y'): putpixel(x,y)
>
> Well, this isn't really scaling (which would need to calculate new
> pixel values, f.e. with a linear filter).

It sure acts like scaling.

> However, you wouldn't use
> this algorithm in the form given as you want to avoid multiplications
> and divisions.

This is a *general purpose* scaling algorithm.  It uses no predefined
tables.  All the multiplication is done within the central loop (instead of
beforehand to set up the tables).  Either of these cases require a
double-multiplication for each pixel in the destination image.  You can
scale independently in the X and Y directions, say, in our example we would
have xscale=2 and yscale=2.

> > 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.
>
> Both examples use very expensive operations for each pixel. The rendering
> is only a small fraction and splitting a pixel value into bits is only
> a small part of the rendering operation.

The rendering is a small fraction on the chunky system, however getpixel()
and putpixel() on a planar system may even take *more* time than the
multiplications due to the time needed to ([shift/mask/extract]x8) then
([shift/mask/insert]x8) do those operations in planar.

> >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.
>
> Can't see that. You get to the point where you use single writepixel
> and readpixel operations where you don't need that just because this
> is the optimal case of chunky and the worst case of bitplanes.

It's a general purpose algorithm that will scale/rotate bitmapped images.
It suffers no limitations unlike your precalculated table.

> And you
> simply 'forget' that your calculations take more time than the pixel
> operations.

I can assure you that on a chunky display, that will be the case.  On a
planar display, that is a different story entirely.

> >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.
>
> 16 might be to small, and 16 color chunky is still quite slow as no
> processor used will support nibble operations. Most advantages of chunky
> displays come from the fact that the processor explicitely supports
> operations on a 'chunk' (8 bits in most cases).

Notice how **NO** processors support parallel operations on several
arbitrary bits at different memory locations.  Even if there were there
would still be overhead due to the extra data accessed that wasn't even
considered.

> >Your correct, the _ratio_ is still the same, but the _amount of time_
> >wasted goes up incrementally, 2x, 4x, 8x etc.
>
> Can't follow your argument here.

Suppose you have a blit that takes 20ms on chunky and 30ms on planar
(planar is accessing 1/3 more data than neccessary) on a 256 color display.
Jump up the pixel depth to true-color (32-bit), and you're suddenly wasting
4x as much time, since now it's taking 80ms on chunky and 120ms on planar.
Still in a 2:3 ratio, but your time wasted has jumped from 10ms to 40ms.

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