After an unsuccessful first attempt at a CPC Megademo I started to create the parts for a second try in 1995. I intended to create a demo that uses mostly unprecedented software effects paired with a few good hardware effects as necessary.

The first part for this Megademo was the "Heat Demo", which was the first fire effect on the CPC at that time. For the second part I intended to create a fountain effect with balls instead of pixles as was seen before in some demos. Additional to that the effect was supposed to be in 3D and not just 2D!

First the balls fall out of the sky on the ground one by one and then they would be sucked up by an invisible vacuum cleaner and fall back down to the ground again. Additional to that I was planning to include some different vector objects consisting of the balls that would float in the air.

The special effect for this demo was the fact that the camera was rotating around this ball fountain all the time, so that the 3D effect would become more obviously. So the whole screen would be in an endless twisting motion.

The ground has different hues from yellow to brown and to make the rotating of the ground visible there were some filles circles of different sizes on the floor. Since the CPC had a very small memory I couldn’t include this many animation phases for the rotation. Since the circle pattern on the floor was symmetrical it sufficed to create the animations for ¼ of the whole circle and then just restart the animation again to create the impression of a full rotation.

This ¼ of the circle consisted of 6 different animation phases yielding a full 360 degrees rotation in 24 steps. That was enough to create a more or less fluid rotation of the balls.

The ground was pre-calculated and crunched in the memory and was copied into two 16 kb blocks of memory before the demo started. Then using a hardware split I just had to change the screen basis address and the new animation phase of the ground would show up on the screen. This method saved a lot of calculation time for the animation of the balls.

Thus the graphics for the ground already took up half of the regular main memory and I couldn’t afford to loose any more memory for double buffering so that the sprite routine of the balls was able to recreate the background once a ball moves to a different position on the screen. I came up with an solution for this problem. Like it was used in some games (Wonderboy, Ghosts’n’Goblins, ...) I made the background use ½ of the available palette and had the balls use the remaining 8 colors. All of the 8 colors for the balls was set to blue and then the balls were painted on the screen with OR-Sprites. That is the bytes of the ball and the bytes from the background would be merged with the OR command.

Since the background used the first 4 bits of each byte for its color information and the ball bytes used the second 4 bits of each byte for its blue color these different types of bytes could just be merged without suffering any damage to the original color information. Also the data of the balls could be removed from the background byte by using an positive AND mask for the first 4 bits (the background), thus removing all the information of the balls.

I didn’t intend to use much more colors on the screen anyway. I thought about adding some stars in the background, but I never got this far. Even though the routine was working nicely I didn’t finish this demo, becuase first of all studying started to take up more and more time and secondly I was too lazy to create all the different objects and animations for the balls.

It would have been a nice demo...