Although I am not precious about the source code, it would appear contrary to the spirit of the course to release it. The reason I started this thread was to discuss how these effects are achieved, and give others an incentive to experiment.
The
Boing Ball demo was actually the easiest of the lot to do. While looking for inspiration in low-end computer hardware demos, I came across this one for the Sinclair ZX81. (Note the bouncing ball effect at 1:30) :
http://www.youtube.com/watch?v=sKj6TaADFWoThe change in direction of the ball's rotation on rebounding was the give away on how to achieve this effect cheaply. The original Amiga Boing Ball demo (Seek to 0:30 here:
http://www.youtube.com/watch?v=-ga41edXw3A) used palette cycling to give the impression of rotation, we don't have that option on the Hack machine. I had already done significant experimentation with bitmap animations on Hack (I should round up the looping clips I have and post them to youtube sometime). The solution was to blit a sequence of pre-shifted bitmaps to screen giving the illusion of rotation AND horizontal movement. On rebounding, the sequence is simply reversed, changing the direction of rotation and horizontal motion.
Pre-calculation of expensive arithmetic is key to high performance animation. Copying a 16-bit word (16 consecutive pixels) to screen memory is cheap, calculating a bit shift for the next animation frame would be very expensive. I started with eight frames of the Boing Ball rotating, rendered with Blender:
The frames were scaled, cropped, quantised to two colours, shifted by two pixels, and padded to an image that was a multiple of 16 pixels in width (using Gimp). This GIF shows the eight frames played back in sequence. Note that each frame is the same size, overlaid on the previous, in the same location! Only the contents of each frame gives the illusion of motion:
Each frame was saved out, and converted into a Jack object via a Python script.
When playing back, the eight frames are blitted to the same location in screen memory. On completion of the eighth frame, the memory location is incremented by one word, and the sequence is repeated. The sequence was designed with enough background coloured border to ensure that the consecutive blitted frame would erase the trail of the previous, so no flickering occurs from blanking (at least for horizontal motion).
The vertical motion of the ball is from a pre-calculated sine table. There is also some blanking required to erase the remainder of the previous frame above (or below) the current one.
Separately I was working on the Sinus Scroller, and later combined the two when I found that they both had enough CPU headroom. I can cover the Sinus Scroller another time if people are interested.
Cheers.
Locked
