Twister

---

A twister is the rotating vertical column that runs through late C64 demos, and it is the same machinery as an x-rotating cube or a waving chessboard carpet. All three are line fragments reassembled per raster line.

Cycles first

The effect exists because of an accounting decision. Full FLI costs almost everything:

With FLI we can force another $d018 value per line. However the forced DMA consumes additional 40 cycles, so not much else can be done when displaying FLI. When doing a FLI only every 2nd line we have another 63 cycles (PAL that is) available for doing a lot of fun things during display.

Half the vertical resolution buys a whole line’s worth of CPU time per pair of lines — enough to change sprite registers, background colours, or the displayed data itself while the frame is being drawn.

What second-line FLI is for

The $d018 writes are not being used for colour, which is FLI’s usual job:

you don’t use $d018 to flip in different screens for different colors for your bitmap, but use the FLI to change not only the screen but also the charset-pointer. That way you are able to display for e.g. 32 char wide chunks of graphics resembled by 8 half-filled charsets and 4 different screens.

The rotation is precomputed

Nothing rotates at runtime. The shape is animated offline, sampled, and stored as fragments:

Imagine the basic shape behind a (untwisted) twister, do 32 animations substeps to make it rotate by one face and save 2 lines of that shape at that very certain step. With those line fragments gained by that process you can now reassemble any twisted form of the original shape.

Per frame, the code chooses which fragment each line shows. The twist is a lookup, not a rotation.

Who wrote it up

Bitbreaker of Oxyron, Arsenic and Nuance.

See also

• FLI — the full-rate version, and its cost
• Speedcode — the other answer to the cycle problem
• Lookup tables