Multiple sprites question

[OldAtAtari]

Hello. I'm working on my first homebrew game, from scratch. I have some programming experience, including some assembly way back in college. But for now, I'm starting with Batari Basic and the Visual Bb tool.

 

I've done well so far.

 

I've got my background and my good guy who can move around the screen pretty well. And I've got one bad guy. And the bad guy doesn't need any missiles, so maybe a sprite isn't even the right thing to use anyway. Basically, I want several bad guys moving around the screen, and if the good guy touches one, it's game over.

 

I know there are limitations regarding having 2 players, etc. But then I look at Asteroids, and that's what I want. One little good guy with a bunch of bad guys moving randomly around the screen. And I notice that in Asteroids, there are three types of bad guys "Big", "Medium", and "Small."

 

So I'm curious: how does Asteroids do it? How does it have one player versus many?

 

Thanks.

Steven

[OldAtAtari]

Ok, so here's what I've figured out since my last post:

 

1) Asteroids probably uses the flickering technique, which I understand to mean that a single player is flashed around the screen so quickly that it appears to exist in too places at once. But then I think about how there can be so many asteroids on the screen at one time, once they get broken up into small bits, I'm surprised the flickering isn't terribly distracting at that point.

 

2) There are things called non-player characters. This might be something like a stack of gold in PitFall. It's an object that just sits there. I assume it can be redrawn repeatedly in such a way that it moves in a given direction. I think this is what I want to do, if possible. I want my bad guys to be non-player characters, and then move them around the screen. If my good guy comes in contact with one, then game over. But I haven't found an explanation yet of how non-player characters are created. Are they part of the playfield?

 

Thanks.

[bluswimmer]

You're correct that Asteroids does use flicker. The game alternates between drawing the ship and drawing the Asteroids on each frame. As for how it displays each one of the Asteroids on a single frame, it actually moves each sprite's x position before drawing each line. However, even when using this method you should keep in mind that you're essentially limited to two sprites per line. Asteroids on the 2600 has one set of asteroids moving upward all at the same speed, and another set all moving downward at the same speed, thus ensuring that no more than two asteroids are on the same line.

 

You may want to design your game so that no more than two characters can be on any given line, or employ flicker if there's more than two characters on a line.

[OldAtAtari]

Wow, bluswimmer. Thanks. That description of Asteroids blows my mind. I need to load up that game and really pay attention to what it's doing. It all seems so seamless and looks like tons of players moving around the screen all at once.

 

I guess I ended up using flicker in my game. I have a single bad guy that I display in two locations, alternating between frames. And that bad guy really does flicker. I don't like that, but it seems to be unavoidable.

 

I've started a new thread with what I have so far, so people can critique it and give advice. It's my first Atari programming experience, so I've got a lot to learn.

 

Here is the link to the new thread:

 

http://atariage.com/forums/topic/279327-stranded-my-first-ever-attempt-at-writing-an-an-atari-2600-game/

 

Thank you!

[+SpiceWare]

I need to load up that game and really pay attention to what it's doing. It all seems so seamless and looks like tons of players moving around the screen all at once.

 

Load it into Stella and turn on Fixed Debug Colors by hitting COMMAND-<COMMA> on a Mac or ALT-<COMMA> on Linux/Windows. On alternating frames you either see the player's ship (and UFO if it's onscreen):

 

or all the asteroids:

 

Player 0 (red) is used to draw all upward moving asteroids while player 1(yellow) draws all downward moving asteroids.

 

If you hit ` (the key with ~ to the left of the 1 and above TAB) you'll enter the debugger and can frame step the game. The default debug colors can be seen on the TIA tab in the debugger. Click Frame +1 on the upper right to advance a frame.

[OldAtAtari]

SpiceWare, thank you. That was a terrific Stella debugging tutorial. I learned so much just through skipping through Asteroids frame by frame.

 

So it's very clear when doing that, that they alternate frames between the ship and the asteroids. The ship is player 1, and the asteroids are player 0 and player 1.

 

What's not clear to me is how they get multiple player1 and player0 asteroids on the screen at the same time. In fact, they go one step farther and have each sprite represented in three different shapes and sizes in the same frame. That blows my mind.

 

I'm sure this will all be more clear once I learn to read assembly, but for now, I just don't see how they do it given the rules as I understand them (You can two sprites on the screen at a time, and never two on the same horizontal line.)

 

[+SpiceWare]

The "never two on the same horizontal line" is your misunderstanding. Both Players can appear on the same scanline.

 

After you're done displaying a player you can change its X location, then reuse it to draw another image. They figured this out at the very beginning, see Air-Sea-Battle (one of the first 9 games) were they reused Player 0 for all the enemy targets.

 

 

The little black lines on the left are HMOVE bars, they're a side effect of repositioning the objects (players, missiles, and ball). In the debugger they are shown in white, so you can see in Asteroids that they're set up to reposition the players on every scanline.

 

Be aware that you can have TIA display duplicate or triplicate copies of a Player, which is how Space Invaders was done

 

Normally all the copies end up displaying the same 8-pixel image, but with tricky timing you can change them just fast enough that they're all different, resulting in the 48-pixel image as seen in Dragster. This is also used for displaying 6-digit score (vs drawing the score with the playfield as seen above in Space Invaders).

[OldAtAtari]

Hey, SpiceWare, thanks again for another awesome tutorial.

 

Air-Sea-Battle is another great example of p0 being used multiple times with different shapes and sizes. I'm beginning to understand the concept now. You display an object, change the x coordinate, and then display it again. But Asteroids seems to also change the y coordinate, as the asteroids are moving vertically as well as horizontally, as opposed to Air-Sea-Battle.

 

Is this something that can only be done in assembly? I've been looking for a Batari example of this, and I can't find anything. Whenever Batari users talk about displaying copies of a sprite, they are talking about the Space Invaders style of evenly placed, exact copies (the NUSIZ command). There is also a multisprite kernel, but I get the feeling that's not what we're talking about here either.

 

To do this right, am I going to have to learn assembly? I don't mind doing that. I learned it in college eons ago, so maybe some of it would be familiar, though I was hoping to churn out a quick and dirty game in Basic first, just to get my feet wet.

 

Thanks again for all your help and advice.

[OldAtAtari]

To answer my own question (or at least to repeat an answer that I found elsewhere in this forum), to do fancy things like this, we're talking assembly. Batari Basic can get you close with the multisprite kernel, but there is plenty that it can't do. If you want to maximize the abilities of the Atari, assembly is the way to go. More to learn!