Explain Sprite Theory please

[Yart]

Hi.

 

I hooked up my 2600 again and had many hours of Berzerk fun, but there's some things that kind of... elude me. Some thing I need some serious explanation on.

 

I noticed that every robot in the maze has their own animation, their own frame, own behavior. No flicker, no glitching out, no nothing. Even when two of the robots were side by side, one could be walking left and one could be turning it's head while shooting.

 

I don't quite get why or how, since I heard the 2600 can only display two player sprites at a time. What confuses me even more is when Evil Otto comes on the map, both the player and Otto flicker. They're both even the same colour.

 

I mean, I don't get it. Why are the robots (who sometimes go up to like 10 on screen at once) so smooth and can maintain their individuality flawlessly, but as soon as Evil Otto comes on the screen both him and the player spaz out?

 

I even tried looking through the disassembled ASM source code for Berzerk (source: http://www.qotile.net/minidig/ ) but I'm not at a level of experience where I can read through all that and know what it all means.

 

So, could someone please explain the theory of how sprites work on the 2600, and how it's possible to achieve the effect the programmers achieved with the robots being flawlessly individual?

 

And one thing I did notice in the code was that the robots were mapped out graphically with "." and "x"es. How is it possible to have a multi-coloured sprite?

 

 

Last, but not least, but could I effectively make a 16x16 sprite by using multiple frames of a sprite and setting them side by side? I would think it's possible if two robots with separate frames can be on the same scanline...

 

 

Also, what restricts the 2600 from displaying more than two shots (a player and a robot's) at a time?

[ScumSoft]

Here I was writing out a long technical post on the inner workings and tricks used when I could have just summarized the entire thing in one word:

 

MAGIC!

 

Yes programmer magic using hardware timing tricks to pull off more than two sprites per scanline, in fact I think the limit achieved so far is 15 per scanline, although this doesn't mean different graphics per sprite. The current limit for different graphics per scanline is 10 I think using just the player graphics and not the missile or ball units.

 

I haven't looked over the Berserk source, so I am not sure what type of tricks they are pulling. Perhaps someone else can explain the intricacies of this game.

[Devin]

Atari graphics are quite unique amongst the consoles. There are only two sprites that can appear on the same horizontal line. Atari programs "chase the beam". They update the screen at the same time it is being drawn.

 

The Atari has some built in features such as drawing sprites double-wide, quad-wide, and in duplicates of 2 or three. There are some timing tricks too. But, Berzerk is a pretty straight forward, expertly programmed, game.

 

When it comes to Berzerk, each robot is the same sprite. The programmer just moves it horizontally depending on the next robot's location. The dead-giveaway is the horizontal blank "bar" on the right. The Atari doesn't draw the first 8 pixels on the right anytime one of the sprites is moved. I've attached a picture with lines showing the sprite's area. Robot's will not cross each other vertically, but horizontally can be lined up.

 

The screen blinks with Otto shows up since the programmer is using the same sprite for the player and Otto - and only drawing one screen at a time. This way, Otto can be given the illusion of running (bouncing) at you horizontally.

Edited June 4, 2011 by Devin

[Zach]

The first thing to understand: let go of the term sprite. When people say there are two sprites, that naturally leads to confusion when there are games like Berzerk with a player and multiple robots. Instead, learn the language of 2600 programming. The "two sprites" are actually the player 0 and player 1 objects, also known as P0 and P1, and their behavior is different from any other video system. There are lots of resources that explain how P0 and P1 work.

 

Sprite is a useful term for design only after you've figured out how the Atari 2600 works.

[Devin]

Well, a sprite one pixel high!

[Zach]

Yeah, funny we were writing our replies at the same time, Devin. What are you doing up so early?

[Devin]

Yeah, funny we were writing our replies at the same time, Devin. What are you doing up so early?

 

Nay, the question is: what am I doing up this late?

Edited June 4, 2011 by Devin

[LS_Dracon]

Sometimes on 2600, a "bad looking" game is more complex than a good looking one.

Berzerk is an exemple. 2 scanlines resolution, few colors but lots of players on a screen.

It's not a simple game to code.

[Yart]

Ah! Thanks for clearing things up for me, guys!

 

Yea I noticed everything you guys said the last time I played Berzerk. I actually used the coding to my advantage in my play where I would set the robots up to not be able to fire at me because I'd use another robot on another side to block the way vertically to make it to safety.

 

The more I play the Atari, and the more I look into it, the more I understand and I have to say this is quite the intriguing system. I'm fascinated by it's limitations, and even moreso by what people can do with the limitations.

 

What a cool system. If only I wasn't too dumb for ASM...

[ScumSoft]

That's why there is always batariBasic.