|
![](/i/fill.gif) |
>> Nice and pleasing to the eye. I would like to see the spheres start to
>>
>>
> I think Andrew is referring to the time when there was a sort of
> competition going on on Amiga's who could have the most balls
> moving at the same time. I think at first people used sprites for
> that. That would limit the number to 8 (IIRC) unless you used
> some tricks with the coprocessors. Creative use of the coprocessors
> thus became a sport. Then someone invented a technique with the use
> of extensive double buffering and use of BitBLT only to simulate
> an infinite number of balls in real time. That was very impressive
> when you saw that first and you knew how difficult is was to get
> even 16 balls all moving at the same time. It also spoiled the whole
> bouncing balls thing in one stroke. So to cut a long story short,
> *not* being cyclic was what made it impressive. Usign POV and
> infinite amounts of RAM and precomputing the animation is just
> cheating IMHO.
My step brother had a computer called a "Sam Coupe". It was a curiouse
mix of old and new. It was powered (AFAIK) by a Z80 CPU. The "compute"
was built into the keyboard, and used a TV rather than a computer
monitor. (Although IIRC it *did* have connections for a computer monitor
- and much other hardware besides.) It came with a 3 1/4 inch disk drive
installed. It had video hardware that could display something like 64
colours at once, out of a possible 256 or so. It seems to have been able
to play back digital audio. (Not much fun with a few KB of RAM and only
700 KB disk to store stuff on!)
It was here that I first saw this demo. On one of the many demo disks
that came with the Sam, there was one that played some music, while
animating a little 3D helicopter made out of shiny red balls. Of course,
it was a simple little trick; a couple of different "ball" images of
different sizes, drawn onto the framebuffer using the painter's algorithm.
Later on in the demo, it would play some music, and animate these trails
of balls around the screen. Each "level" had a different colour of
balls, and a different trail pattern. (They all seem to involve simple
combinations of trig functions - probably because those make nice smooth
shapes and are fairly fast to compute.) A little counter in the corner
would tell you how many balls were on the screen. You could just leave
it for arbitrary amounts of time; the counter kept doing up. We were all
utterly amazed that the machine was so powerful that it could animate
all these billions of balls at once...!
Later, I saw a similar demo implemented on an Amiga in Blitz Basic.
(Remember that?!) It wasn't nearly as good - no music, only 1 pattern
(circle with phase-shift). But here I learned the secret of the trick...
The program allocates 16 framebuffers, and initialises them all to pure
black. At any moment it displays framebuffer N, while at the same time
adding an extra ball to framebuffer N+1. (All in mod-16 arithmatic.) So
you're actually watching a 16-frame loop, but the frames get more balls
added each time they're shown. This neatly gives the illusion of an
almost infinite number of balls flying around, yet demands hardly any
CPU power at all. (The Amiga has a special chip *JUST* for copying
blocks of image data around - the "blitter" clip.)
I never saw anybody attempt to implement this with hardware sprites, but
maybe that's because I wasn't around at the time...
Andrel's remarks are indeed correct though. The Amiga's video hardware
(and the C64 FWIW) can display 8 "hardware sprites". The video hardware
itself overlays these as the raster beam draws the display on your CRT.
The Amiga, though, had a graphics co-processor called the "copper". This
could poke numbers into video registers at an exact scanline. This could
be used to change colours on each scanline to create the famous
"rainbow" effects. Its other use was "virtual sprites" - the thing Andel
was just mentioning.
If a sprite is 10 scanlines high, you can poke the sprite coordines into
the sprite control register during the vertical blank period. Then wait
for (say) 15 scan lines to be drawn. Then poke some new coordinates
lower down the screen into the sprite control registers, and BINGO! A
single hardware sprite draws two different images in seperate places on
the screen - all with 0% CPU usage. But you can still only ever have 8
hardware sprites on any one scanline. (But sprites can be WIDE...!) And
so the trickery goes on.
As for "cheating"... Well, the blitter trick uses come cleaver 2D magic
to make what looks like an almost infinite set of balls moving around in
almost-3D. I wanted to see what it would look like in *real* 3D - with
light-sourcing and all the rest. And the answer is: it looks damn good!
This is how those demos of old would have looked if the CPU power had
been available. Who knows, in another 10 years' time, maybe it will be
possible in realtime?
As for infinte amounts of RAM... what PC do *you* run POV-Ray on?! Cos
I'm pretty sure _my_ PC has a very *finite* amount of RAM in it. :-( CPU
power is even more finite - I rendered a version of this with reflective
spheres, and it took about 18 hours to do 60 seconds of animation...!
Post a reply to this message
|
![](/i/fill.gif) |