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. http://www.boutell.com/ Sync my card with your PDA or address book: http://tocard.biz/a7oiljb6
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [stella] New game - Fall Down, Aaron | Thread | RE: [stella] Ms. Pac Man, Mr. Do, s, Dennis Debro |
Re: [stella] New game - Fall Down, Aaron | Date | RE: [stella] Ms. Pac Man, Mr. Do, s, Dennis Debro |
Month |