Sprite handling judgement code is getting wacky. The judgement logic was sucking down too much RAM to compile ... so now I have an abbreviated version of the drawing list being used to set up sprites, which takes longer, and then expand it into the drawable version at the last moment, after doing judgements, and reusing the same RAM.

Need to hack on this a bit more for it to generate a valid drawing list, and then implement the RESPx stuff.

Just for fun, I frelled up something in the playfield logic and introduced one of those off-by-one errors that take forever to trace down, which means each playfield tile is being drawn out of phase by one lineset ... a macro run wild probably.

EDIT/PS:

OK, it's 3:30 AM in Florida, and I hate maths.

So.

Sprites either do, or don't, draw. None of this partial drawing stuff. I think Thomas's suggestion feels right about constant flicker, and in this case, all or nothing drawing is probably psychologically better.

The "score" is no longer a score, since we just claim the slot or don't -- so I'm (ab)using cur_score to mean post-drawing repositioning lines. Sorta.

Much optimisation will likely happen here shortly, in the mean time, here's the pig sty:

I'll have to rethink the judgement code further, I almost posted it before realizing that it totally disregards realigning the temporary drawing list workspace properly and basically clobbers itself as it runs :-(

It will probably be rewritten tomorrow morning while Chris is in class. For now, bed time.