Ms. Pac Man, Mr. Do, striped playfields, and one-line kernels

Subject: Ms. Pac Man, Mr. Do, striped playfields, and one-line kernels
From: Thomas Boutell <boutell@xxxxxxxxxxx>
Date: Tue, 31 Aug 2004 18:51:19 -0700 (PDT)
Hi, folks. I just joined the list at the suggestion of two subscribers
who found a post of mine on the atariage 2600 newbie programming forum.

My question there had to do with something everybody wants to know:
how to manage an asymmetrical playfield *and* be able to horizontally
reposition and reuse sprites several times in the same screen, allowing
for more than two objects with minimized flicker. 

I figured out that Ms. Pac Man achieves this by using a symmetrical
playfield except on the rows that contain "pellets." Those rows are
actually done with asymmetrical playfield code, but the game still has
time to reposition and reuse sprites on the non-pellet rows when 
the playfield doesn't need so much attention. But I didn't see how I
might apply this to my game, which uses an asymmetrical playfield in
a more general way.

Thomas Jentzsch was kind enough to point out that Mr. Do, Thrust and
some other games achieve this goal using a striped playfield: every
nth row (every third row, in the case of Mr. Do) has playfield graphics,
the other two don't. The result looks reasonable and frees up the CPU
to do the necessary sprite repositioning on the two non-playfield scanlines.

That helped. It may even be sufficient... sort of. But now I've noticed 
something else that has me wanting to know how it's done: both Mr. Do and
Ms. Pac Man have single-pixel vertical resolution to their sprites! 

How the heck did they fit that in? You can't change both GRP0 and GRP1
to the appropriate rows of two arbitrarily positioned and distinct 
sprites between WSYNC and the end of horizontal retrace. No way. 
Uh-uh. You just... can't. 

... Or can you? And how?

Both games I mentioned are 8K cartridges; I don't know enough yet about 
.bin files and the stella emulator to tell whether it also contains extra 
RAM.  My goal is to put my game into a standard 4K ROM cartridge with no
funny business, so if this trick can only be done with gobs of extra RAM 
or something, I am content to go without it. But I'd love to know what's 
going on here. 

Thanks for any insight!

P.S. I have done playtests and verified that with only Mr. Do and
one monster sharing vertical space, all other objects absent,
there is no flickering going on. So the kernel isn't just working 
with only one GRP register; that was my first thought. Mr. Do also
does some other very neat tricks, like drawing numerous cherries
and apples per row, but it looks like the cherries are 
accomplished using the NUSIZ0 and NUSIZ1 registers, so I
understand what's happening there (and should probably borrow it).
Thomas Boutell
Boutell.Com, Inc.                              

Sync my card with your PDA or address book:

Current Thread