Asymmetrical playfields and sprite flicker

[boutell]

OK, here's the situation:

 

1. I'm coding a game which uses an asymmetrical playfield. I've succeeded in writing a two-line kernel which can cope with the asymmetrical playfield and the two player sprites... just barely.

 

2. Because of the nature of the game, the asymmetrical playfield is present on every line of the main gameplay area.

 

3. I need more than two "player" sized sprites.

 

Now I know what the classic solution to #3 is:

 

Rotate them on alternating frames, every third frame, etc. This flickers, of course... a lot. This is the Adventure solution. Also the original 2600 PacMan solution. But the game calls for too many objects; the flicker would be unbearable.

 

I am aware of a workaround to minimize flicker, at least when you don't have too many things *vertically overlapping* at the same time: reuse the sprites within a single frame. As long as you have a scanline in between sprites in which to breathe, you can reset the horizontal location...

 

Except for the dratted asymmetrical playfield! That requires CONSTANT tending. Every single scanline or you see obvious gaps.

 

Now I've been staring at Ms. Pac Man and Jr. Pac Man. Both of these do a really good job of minimizing flicker whenever possible. But they use symmetrical playfields, so they don't have to tend the playfield registers on every scanline, and therefore they have an opportunity to move sprites around...

 

Hey wait a minute, look at those dots Ms. Pac-Man is gobbling! They're not dots, they're stripes -- they're playfield pixels! Which means the playfield is asymmetrical. Which means... what? How the heck is this trick accomplished?

 

I have a horrible, sneaky suspicion I know the answer:

 

1. The "dashes" are not on every scanline.

 

2. The scanlines containing the "dashes" are done with asymmetrical playfield settings.

 

3. The scanlines NOT containing the dashes are done with plain old symmetrical playfield, and sometimes they stay the same for several scanlines, so...

 

4. The horizontal repositioning of sprites is happening only on the repeated symmetrical playfield scanlines!

 

Am I right? And more importantly, does this mean I have to choose between a truly asymmetrical playfield for my jump-scrolling map, and any hope of minimizing flicker?

 

It looks like I'm going to have to give in and have each "room" of my larger map be symmetrical, with no jump-scrolling halfway between rooms (or even playfield-pixel-at-a-time scrolling, yes I did manage to implement a demo of that) or other effects that would force asymmetrical playfield use on every scanline. If there really isn't another way, I can stand it, but I'd hate to think I wimped out and missed something clever. And I can already see that I'd be forced to use asymmetrical playfield at least when a horizontal hallway is present on the left but not on the right, or vice versa.

 

Thanks for any insight.

[Cybergoth]

Hi there!

 

I think you're right on your assumptions regarding Ms. Pac.

 

I started a similar discussion on [stella] not too long ago and there are a few possible loopholes, but, like your question already, they're way too advanced for the newbie forum.

 

Best you subscribe to [stella] and repost your message there.

 

Greetings,

Manuel

[DEBRO]

How the heck is this trick accomplished?  

 

I have a horrible, sneaky suspicion I know the answer:

 

1. The "dashes" are not on every scanline.  

 

2. The scanlines containing the "dashes" are done with asymmetrical playfield settings.

 

3. The scanlines NOT containing the dashes are done with plain old symmetrical playfield, and sometimes they stay the same for several scanlines, so...

 

4. The horizontal repositioning of sprites is happening only on the repeated symmetrical playfield scanlines!

 

Am I right?

I haven't totally disassembled Ms. Pac-man but from what I've seen you're right. The dots are an asymmetrical PF and the maze is symmetrical. I haven't gone as far as seeing where and how the positioning is done but looking at the maze resolution you seem to be right on.

 

Remember you can position the sprites without a positioning loop. You would have to have a kernel that would hit RESPx at the right time. This could make you kernel rather large but it is doable.

 

I started a similar discussion on [stella] not too long ago and there are a few possible loopholes, but, like your question already, they're way too advanced for the newbie forum.  

 

Best you subscribe to [stella] and repost your message there.

I agree. There are some [stella] members that don't come here often.

[Thomas Jentzsch]

Striped playfield graphics like in Mr. Do or Thrust may be an option. And a very efficient repositioning code which leaves some time for other operations.

 

You should really join [stella], because you already sound like you understand quite a lot.

[Thomas Jentzsch]

Striped playfield graphics like in Dig Dug, Mr. Do or Thrust may be an option for you. And then some very efficient repositioning code which leaves some time for other operations.

 

You should really join [stella], because you already sound like you understand quite a lot.

[boutell]

> Striped playfield graphics

 

[smacks forehead like a stunned monkey]

 

Of course! Thank you. I don't know if I'll choose to go that route or not, but I wish I'd thought of it as soon as I figured out what Ms. Pac Man was doing.

 

The best part is that it may actually fit in with the graphic design of the game.