pouët.net

ah yeah...this is whut i am talking about..it's the bomb..one of my all time fav demo. The raytracin and the vector parts are the best ever done on the C64. The music is also very good, right now the Vector tune by Boogaloo is pumping out of my Cambridge speakers..thankz to Sidplay.
I have found some intresting facts about this demo on comp.sys.cbm, is a bit long but it's worth it..

Here's the story about the demo:

I and Exilon had a great demo idea for the Amiga. We spent a
whole year coding on that demo - not only because the demo
was THAT complicated, but we did not know all that much about
coding on the Amiga. The demo is called 'Virtual Intelligence',
and contains some nice 3D vector objects with 8-color bitmaps
on the surfaces. As we developed the demo, I promised a stupid
thing:

I will not return any Coca-Cola cans for recycling until I win
another demo-competition!

Oooops! When we released the 'Virtual Intelligence' demo at
The Party'91 we only reached 4:th place (out of 25, so it was
not _that_ bad, for a first-time demo)!!!
- Shit! I thought. We will probably never have such a good demo
again for the Amiga. When will I be able to return my Coke-cans?

A few weeks after The Party, we sat at my place, calculating the
possibility of making a good filled vector routine on the C64,
based on the vector routine we have made on the Amiga. We dis-
covered that it really was possible. Our idea was that all
routines in the demo must be fully optimized, from the multi-
plications to the line drawing to the filling and the double-
buffering.

The fundamental principles:
Optimizing by squeezing machine cycles would not gain enough.
The optimization must be on the algorithms themselves. Code
optimizing is easy when the algorithm is simple.

We discovered that the EOR filling in columns is the best. We
decided to sacrifice memory for a complete 16*16 char fill as
an unrolled loop. The fill algorithm could not be more simple
than that, so we considered it fully optimized. Thanks to
the fill being an unrolled loop, we could take advantage of
the fact that a rotating object cannot reach any of the
corners of the 128*128 pixel area without clipping at the
sides of the square area. We then filled only the circle
that the objects could occupy, gaining even more time.

The line routine was a little harder. It had to be lightning
fast, but also 100% accurate. It had to produce exactly the
same line when we drawed it from X1,Y1 to X2,Y2 as when we
drawed it from X2,Y2 to X1,Y1. We already knew how we made
the Amiga blitter do this, so we tried to emulate the
blitter algorithm in another unrolled loop. When we then
drawed lines, we jumped into the unrolled loop at the right
position depending on where the line should start, and put
an 'RTS' where the line should end, restoring the code when
the line was finished. Even this we considered fully opti-
mized.

Then there were the vector calculations. We used most of the
ideas from the Amiga demo. We use a 3*3 matrix multiplication
routine. We took the matrix creation routine and converted it
to 6502 assembler, but used 8-bit arithmetics instead. The big
problem was to multiply the vectors fast enough. We had to
invent a really fast multiplication routine. We discovered the
square-sum method, and implemented the matrix multiplication
in an unrolled loop as well, using 6-bit (I think) precision
to avoid overflow and rounding problems. Some rounding was
built-in into the square-sum tables, as far as I can remember.
As the square-sum multiplication only takes about 30 cycles
per element, we considered this fully optimized as well.


What have we got?

- A fully optimized unrolled fill routine
- A fully optimized unrolled line routine
- A fully optimized matrix multiplication routine
- A fully optimized unrolled clear routine, based on
the fill routine

No compromises. It took us almost half a year to create
all these things. Nearly half of the time we sat at my
kitchen table calculating and discussing. We did not code
anything until we knew that we had the best algorithm.

During the process, we came up with new ideas: the glenz,
the pixel transform, and the ray tracing part. The 2D
transform took us only about 1 week to develop. The glenz
was hard to do, because it had both transparent and non-
transparent surfaces (which no glenz I've seen after that
have had, only transparent surfaces). We used sprites for
the non-transparent surfaces, thus having two unrolled line
routines and two unrolled fill routines filling up the
memory completely.


Well, Exilon could not come to the party, so I and Pernod
had to finish the demo ourselves. I optimized the 2D
transform analyzer a lot, and had LOTS of trouble crunching
the vector part. I delivered it several hours too late to
the party staff, but they allowed us to compete anyway.
Well, you all know the rest. We won by 1 vote (I think)
over Censor Design. Psycho/Censor was not all that happy,
since he was the one who helped me to crunch the demo.
Thanks a lot, Psycho!!!

We won 6000 Danish crowns, but they were not able to pay
us because the party was a big financial catastrophy.
But when I got home, I could at last return all my Coke
cans. There were 639 of them, giving me 319:50 SEK. I
kept my promise...:-)


What did I want to say with this? Well, I want to say that
I think this demo is the best I and Exilon ever made and
ever will make. I also think that it still has some of the
fastest 3D filled vector routines on the C64. I am mighty
proud of it!!!

If any of you want to see the Traktor demo, I'll be glad
to mail it to you. Also, I am willing to release the
source. I am not worried that people will rip the routines
without credits, because I know that we made it first.

I will work on the source with Paul and then post it on
the net or directly to the interested ones by e-mail.

If any of you has any questions, email me at:

[email protected]

That's all folks!!!

Linus Nielsen/Boogaloo of Horizon