SpiceWare's Blog

Liked the animated most.

Flicker usually remind hardware weakness.

Good point.

In thinking on it some more, I'll just make it a menu option and let the player select which to use. I think I could even support 3 flicker rates.

Don't discount table lookups. Skeleton(+) was table lookup driven, including the maze, the 3-D view, the Skeleton, the score digits and the title & end screens. Yes, the table can take up a chunk of ROM, but they are dead simple and typically code efficient.

Line drawing will be very simple as for this I only need to draw it horizontally or vertically. My plan is to make the function like this:

 

DrawLine(x, y, x_length, y_length, pattern)

 

If x_length <> 0 the line will be left or right depending on the sign, otherwise it will draw based on y_length.

 

Pattern will be a bit pattern to draw - so to draw the wall I'd use $FF (%11111111) while the reflective walls would use $AA and $55 (%10101010, %01010101).

 

This will let me shrink the door logic as well as I'll be able to use patterns of %11001100, %01100110, %00110011 and %10011001. Plus I'll be able to easily revise it to work with the Frenzy layout, which has 20 locations for the doors, instead of just 4.

 

I'll be using lookup tables for decipher the X positions. One table of 40 values will contain which playfield register gets updated(PF0left, PF1left, ..., PF2right), and another table of 40 entries for which bit to update.