|
 |
I'm sure we've all seen a demo like this on some old 8-bit home computer
of some description somewhere... The original uses special video RAM
trickery to create the illusion that your little 2MHz machine can
actually animate billions upon billions of balls around the screen
effortlessly... Actually it's all just blit tricks ;-)
Of course, *this* version does it, like, _for real_, in true
tripposcopic 3D baby! A metallic version is rendering as I type. ;-)
Post a reply to this message
Attachments:
Download 'trail-02-low.m1v.mpg' (646 KB)
|
|
|
|
Orchid XP v2 <voi### [at] dev null> wrote:
> I'm sure we've all seen a demo like this on some old 8-bit home computer
> of some description somewhere... The original uses special video RAM
> trickery to create the illusion that your little 2MHz machine can
> actually animate billions upon billions of balls around the screen
> effortlessly... Actually it's all just blit tricks ;-)
>
> Of course, *this* version does it, like, _for real_, in true
> tripposcopic 3D baby! A metallic version is rendering as I type. ;-)
Nice and pleasing to the eye. I would like to see the spheres start to
Stephen
Post a reply to this message
|
|
|
|
Stephen wrote:
> Orchid XP v2 <voi### [at] devnull> wrote:
>
>>I'm sure we've all seen a demo like this on some old 8-bit home computer
>>of some description somewhere... The original uses special video RAM
>>trickery to create the illusion that your little 2MHz machine can
>>actually animate billions upon billions of balls around the screen
>>effortlessly... Actually it's all just blit tricks ;-)
>>
>>Of course, *this* version does it, like, _for real_, in true
>>tripposcopic 3D baby! A metallic version is rendering as I type. ;-)
>
>
> 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.
Post a reply to this message
|
|
|
|
andrel <a_l### [at] hotmailcom> wrote:
> 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.
How informative, thank you Andrel. I vaguely remember something like that.
Still its simplicity is enchanting and I like pretty screensavers, not that
I use them:-)
pyramids, did it not?
Stephen
Post a reply to this message
|
|
|
|
>> 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
|
|
