3D rasterisation

Right — if you're ray casting then doing conventional perspective is actually a little more expensive, at one extra multiply per column. If a pet peeve stemming from all raycasters that I have ever seen isn't too off-topic: the thing people usually get wrong there is thinking that if you want to cover an x degree field of view in u pixels then angles should be picked through a linear scaling of x to u. When people have made that mistake you usually see them pick a small field of view, because the error is smaller, and still have things be slightly sickeningly-distorted towards the edges. The correct thing to do is to think about the right-angled triangle each cast ray makes from viewer to screen, and get the angle from that. So it's an arctan thing. And then just a lookup table. No extra processing cost for getting it right.

My more helpful reason for returning is that I realised my previous comment about an odd-shaped lookup table for polygon edge scanning (or line rasterisation for an MSX1, I guess) is hokum because you've two values to store and each table is triangle-shaped. So you can just flip one and push them together.

Suppose you're limited to a 192x192 drawing area. Then the lookup table is 36kb, and when |x| > |y| the algorithm looks something like:

    address = (|x| * 192) + |y|    // with shifting rather than an actual multiplication, obviously
    quotient = table[address]
    remainder = table[address ^ table.size]

    x1 += (quotient >> 1)
    error = y
    while(y1 != y2) {
        output(x1, y1)

        error -= remainder
        if(error < 0) {
            error += y
            x1++
        } 
        x1 += quotient 

        y1++
    }

Typed extemporaneously. Check before use. You'd probably have four variations for the four arrangements of incrementing and decrementing x and y, and have ended up with |x| and |y| in picking one.

The |y| > |x| version instead outputs either quotient or quotient+1 locations downward from (x1, y1) before incrementing x1 (and have four arrangements of that).

If you're on an MSX1 or any other machine without hardware line drawing then to draw a line, don't seed x1 to halfway across a span, and draw all the spans. Make sure you handle x = y, x = 0 and y = 0 as special cases.

Very impressive. Doesn't look like it uses more than 4 colors, though. I imagine it uses page-flipping to avoid flickering and tearing. Maybe it uses the extra available pages in SCREEN 6 to store the background graphics?

The first one looks a lot smoother… Does anybody know why?

wireframe FMV? As in, for each frame there's a list of start and end coordinates to draw lines between?

Metalion posted an interesting optimisation approach here: