Re: [stella] Generating a health bar without ruining your health...

Subject: Re: [stella] Generating a health bar without ruining your health...
From: Glenn Saunders <cybpunks2@xxxxxxxxxxxxx>
Date: Thu, 27 Sep 2001 22:53:45 -0700
At 07:56 PM 9/27/2001 -0700, you wrote:
Glenn gave one good suggestion, probably the *best* in fact,
but one that would make my knees knock a bit as a beginning
Stella programmer.  Mixing playfield and sprite graphics and
lining everything up creates whole minefields in which bugs can

You can set up your sprites above the playfield and they will just keep drawing unattended during your asymmetrical playfield.

Another tactic I'd suggest would be defining a "bar character set"
for the 6-digit score routine to use (it would only have to have 8

But if you did that you'd only have one health bar available per scanline.

Of course, Glenn's method is superior because you could make
the bar the width of the screen if you wanted and get 160 pixel
resolution for its length -- if you can get everything to line up

Put all your heavy calculation during VBLANK. Coming out of VBLANK you'd have, let's say, 4 RAM variables representing the bits to write to PF1, PF2, PF0b, and PF1b and horizontal position values for the sprites (assuming you used a mirrored playfield.

During the VSYNC WSYNC area you can execute your horizontal motion routine and your initial HMOVE commands, and then you can draw $FF to GRP0 and GRP1 ahead of time, maybe during the border area.

and fine-end sprite code yourself.  It is also a PITA to deal
with the reversed middle PF register (what were they thinking?)

As was previously discussed, the playfield registers are clocked out in some kind of ping-pong like fashion for economy in the circuitry. That's why the bit order reverses like that.

Archives (includes files) at
Unsub & more at

Current Thread