12 replies to this topic

[Cafeman]

How exactly is this done?

Here is my guess. Even if I'm wrong, I'd like to talk about how best to do this since 4 players is quite limiting.

Anyway, I've read that if you know that 2 objects will be on different horizontal planes, that this is the best time to split the sprite. IS it done via a DLI? IN other words, put a DLI halfway down the screen, and the DLI routine changes the player bitmap to the 2nd object, and changes its location in memory? Then at line 1, the swapping occurs again?

Or perhaps it is done in conjunction with careful timing of the which scanline you are on? (note that I currently have no clue how to implement this kind of coding)? Or is there a whole other (and hopefully, Better) way?

Oh btw, my first game (which is no longer titled "Firefighter") probably won't need to implement this kind of sprite/player swapping, but I'd still like to get an idea of how to do it. Like in Joust, all those birds are just 4 players?! I notice that when they get on the same horizontal plane, swapped/split players start to blink. Perhaps this is why the Pac-Man 2600 ghosts flicker? Every ghost is draw every 4th frame?

Thoughts are welcome!

[DanBoris]

There are two ways to achieve this:

1. The easy, ugly way.
With this method you display 4 sprites in one frame, then before the next frame you move them to represent 4 different sprites. This is quite easy to implement but it results in some flickering.

2. The hard, but clean way
This is sorta what you described. If you have a sprite that is shown at the top of the screen, you can move it once it's drawn to the bottom of the screen so it's displayed twice. Implementing this can be tricky. The re-use obviously can not occur if the two sprite share any horizontal lines. It also won't work if one sprite is slightly below the other since you won't have time to move it.

This technique works especially well when you know certain sprites will only occupy certain parts of the screen. For example a space invaders type game, the ufo that goes across the top of the screen and your base at the bottom could easily be the same sprite.

One other thing to not forget. There is a bit that can be set in one of the GTIA registers the combines the 4 missiles into a 5th player. So if you don't need the missiles, you can get a bonus sprite.

Dan

[Cafeman]

Dan, in many games the flickering only starts when sprites get on the same horizontal lines. Do you think the coder implemented both methods in that case?

In other words, when he detects Player0's 2 uses getting close to one another horizontally, he branches to the every-other-frame routine instead?

Otherwise, wouldn't the birds flicker all the time regardless of their position?

[Cafeman]

Bump. Still thinking about this.  

If you use a DLI to switch the memory pointer for a player, then you probably need to display the highest-on-screen player first, then at the DLI switch to the lower one.

Game code draws Player0A and Player0B in different memory locations. Other variables store each split-player's horizontal and vertical locations. All the collisions and animation is handled in the normal game code, but during the DLI you decide which of the 2 is on top and switch pointers at that line. I imagine it would take some kind of counters set up in the game code that the DLI would check. After all, you don't have much time during DLI.

During DLI you blindly switch to draw the 'lower' player. During normal game code you handle everything else, but during DLI you switch pointers. Hence, if Player0A and Player0B get on the same horizontal lines, you'll miss at least 1 frame and flicker will occur. I think?!

Question: where do you put the DLI, since a DLI is invoked by setting a bit on a certain modeline? Perhaps you have the DLI bit enabled on every modeline in the display list?

[DEBRO]

Cafeman I'm not the best to answer this question because I was studing Bob Colbert's code before moving to looking into the 5200. I believe you have to keep track with what frame is being displayed and which players are in the same zone. For example if PlayerA0 is in the same zone as PlayerB0 then PlayerA0 is shown and PlayerB0 is hidden during frame 1 then PlayerA0 is hidden and PlayerB0 is shown during frame 2. Go to Bob's site explaning his variable flicker for a better explanation.

Moderator Edit: Bob Colberts explanation is located here: http://www.atari2600...com/newgame.htm

If you want to do something like this on the 5200 I think you have to do it in a VBI. That way you can check the player zones on each scan line.

[DanBoris]

Cafeman:

You are correct in your reponse about the flicker, they sometime do combine both methods. If the players are far enough apart you can do re-use, if they are near each other you can do page flipping.

I am not sure exactly how games handle the sprite re-use, but here is an idea. You can probably do most of the work during the vblank. Vertical position can definitly be handled during vblank, the data can be written into both vertical locations it's going to appear at. You would probably then want to have a DLI on every line (or one every few lines depending on the mode). The DLI could check a variable setup during the vblank that indicates on which line the horizontal position of the player can be changed.

Dan

[DanBoris]

I got so interested in this topic that a hacked up a quick demo of how sprite re-use can be done. It's just a modified version of my 52pm demo. You can get it off my web site at http://atarihq.com/danb  in the 5200 section.

[Cafeman]

Interesting! You changed the color and position of the smiley thing, and it is really just one player.

I noticed that both use the same background/foregroudn priority setting, which leads me to another question.

Can the priority register PRIOR be set in such a way that some players are in the background while some are in the foreground at the same time?

[Nukey Shay]

From "Your Atari Computer"...

$01 (bit0) gives all players priority over all playfield colors.
$02 (bit1) gives players 0 & 1 priority over all colors PLUS players 2 & 3.
$04 (bit2) gives priority to the playfield over all players.
$08 (bit3) gives priority to the playfield over all players AND playfield registers 2 & 3.

[mos6507]

A sprite has no defined vertical position on the Atari 8-bit.  A sprite is a strip of memory that runs down the entire height of the screen.  It just seems like it has a vertical position because you move the visible data up and down (or adjust a pointer to where that data is stored).

So to reuse sprites vertically is kinda a misnomer, since a sprite is by definition always available on every scanline.

If all your pseudosprites were to be at the same horizontal position at all times you wouldn't have to do any special coding.

If they have to be independent of eachother horizontally, then you have to write some kind of routine to adjust the horizontal position of the sprite on the fly to break the strip apart.

The same applies to the 2600, by the way, but with more manual labor involved as only one scanline is buffered in memory at a time.

The one thing they dropped between the 2600 and the 8-bit which I wish they hadn't was the sprite cloning feature.  That would have really come in handy for games that need a lot of sprites horizontally (Galaxian/Invaders type games, for instance).

I don't think there is a way to get the 8-bit to clock out more than its maximum 4 players and 4 missiles on one scanline.  You have to start using software sprites in playfield bitmaps or character graphics, or start flickering.

[DanBoris]

Yes, it is a shame they took out the sprite duplication, but I wonder if you could play some tricks with the GRAFP0-GRAFM registers? These work just like the PM graphics registers on the 2600 in that they write the image data directly to the player graphic register, thus bypassing the ANTIC. You would have to write them on every scanline, but you may get a little more flexibility then with the normal way of handling PMs.

[Cafeman]

Dan, are you reffering to using a Kernel, where the program sits inside a DLI to defeat Antic?

[DanBoris]

Yeah, it's a teqnique that wasn't used much (at least not on the 5200), but Activision used it in some of it's ports, like Kaboom. Presumably to make it easier to port from the 2600 version.

Dan