row of sprites?

[BenMcLean]

I know that the atari can draw more than just two sprites because Space Invaders has a whole row of them. So I thought of a game idea that would involve four or so enemy sprites all in a row moving together. If one dies, quit drawing that one. Is this doable with Batari Basic? From what I read, space invaders type stuff was being done by using the playfield to blank out sprites, and that wouldn't work here because the whole row, though they'd move together, would need to be free to move anywhere. How would you approach this problem?

Edited July 11, 2014 by BenMcLean

[Rybags]

Space Invaders actually uses the Players replicated 3x with double spacing, ie what you see left to right is P1 copy 1, P2 copy 1, P1 copy 2, P2 copy 2 etc.

 

The kernal stuffs the graphics registers in time such that the correct display occurs, which is either blank, part of an invader or part of the explosion sequence.

 

I guess in theory you could use PF to blank out unwanted copies but then that means it becomes unavailable for background graphics, as well as the problem that PF pixels equate to 4 Player pixels which might hinder masking.

 

No idea if BBasic allows kernal operations as Space Invaders performs them. It's a very tight timing situation where the CPU is doing what's needed just in time for the display. Of course an alternative is to just do flicker type display like so many other games do.

Of course also note that SI is able to do it the way it does because the horizontal spacing between the enemies is always constant.

[BenMcLean]

1. I'm not super concerned about flicker as long as it doesn't get too bad.

 

2. I'm not building Space Invaders. That's been done to death.

 

3. I want these to be normal sized sprites, not 4x like Space Invaders. Does that make it easier?

 

4. I would like to have a horizontal row of baddies that moves. Shoot one bad guy and he should disappear but the rest of his buddies in the row should move together to chase you.

[Rybags]

SI are normal sized, ie not expanded pixels. They're just replicated so you get 6 objects instead of 2.

 

If you use the Player replicate mode in that same way, there's only option for close or far spacing - with an enemy shot then moving the rest closer you'd not have the option for fine movement using the replicate mode.

 

If using both players to represent 4 objects but not in replicated mode then you'd have flicker as the players are representing 2 objects so only visible every 2nd frame. This is generally acceptable since the flicker is minimal when doing this.

[BenMcLean]

I didn't mention that I want both my good guy and my rows of enemies to be in color.

 

It looks like to get both player0 and player1 to be in color, you need to set the kernel option "set kernel_options player1colors playercolors pfcolors" Please tell me if that is not correct. The cost for doing this is that I lose both missile0 and missile1, and that's horrible. Well, I thought of a clever way to get around that. Please tell me if this is a valid/good idea:

 

You can only hit one bad guy per row. (this is not ideal but OK, it works with my game concept and design) So I use the ball for bullet, then when it hits a bad guy, use the playfield to cover him up by changing the color of the playfield to the same as the color of the background while the guy is dead. Then you can't shoot again until his patrol is offscreen. I then change the playfield color back to the bullet color the next time you shoot so that the ball will be the bullet color.

 

This means I have to give up using any playfield obstacles, which is a bummer but an acceptable loss.

Edited July 11, 2014 by BenMcLean

[BenMcLean]

If you use the Player replicate mode in that same way, there's only option for close or far spacing - with an enemy shot then moving the rest closer you'd not have the option for fine movement using the replicate mode.

 

If using both players to represent 4 objects but not in replicated mode then you'd have flicker as the players are representing 2 objects so only visible every 2nd frame. This is generally acceptable since the flicker is minimal when doing this.

None of the bad guys need to move relative to each other -- they just need to all move together, and sometimes at least one of them needs to be killable. If the guy in the middle gets killed then they all keep moving together with a blank spot in the middle where that guy used to be.

 

What I really want is five sprites on screen at a time -- the human player's avatar and one row of enemies, all these guys in color ... and a bullet. Preferably four enemies in the row if I can do it. Can I do this?

Edited July 11, 2014 by BenMcLean

[Rybags]

The problem you'd have using ball for missile and playfield for masking is that they're the same colour.

Obviously to mask an enemy, you'd need the playfield colour to be same as the screen background.

That makes using the ball as a missile somewhat pointless because it won't be visible.

 

I see your other problem too - if you want different colours for the enemies and are using the missiles as missiles then they'll not necessarily be the colour you want them to be.

 

You're probably best off using the flicker technique. So long as the player's ship isn't on the same horizontal line as the enemies is shouldn't be too much work.

 

As for the programming side - I know the hardware reasonably well but next to nothing about B-Basic. But there's plenty around that know it well.

Edited July 11, 2014 by Rybags

[tokumaru]

The Atari 2600 is able to show the same player once, twice or 3 times, with a few options of spacing between them. They will always move together, because the space between them can't be fine tuned. This is a feature that takes no processing time whatsoever, so it should be available in bB.

 

So if Player 0 is used for the hero character, Player 1 and its copies can be used to represent up to 3 enemies in a row. You can make any of them disappear as you wish, you just have to switch from 3 copies to 2 and adjust their spacing and/or position to make one specific enemy vanish. For example, say you have Player 1 set up to show 3 copies with a small distance between them. If the middle one dies, you can switch to 2 copies with medium distance and the middle enemy will appear to have vanished (when in reality you just pushed the second copy backwards and stopped drawing the third).

 

The catch is that the patterns and colors are shared between all the copies of an object, so all the enemies will look the same. Some games get around this by doing carefully timed pattern/color changes between the copies. This gets harder and harder to do when the objects have more horizontal freedom of movement, so I wouldn't suggest you try this if the enemies are able walk all around the screen.

 

If you need more than 3 enemies, things get a little harder, because the other player is being used for the hero character. You can either use flicker (each frame Player 1 alternates between 2 different sets of 3 enemies, for a total of 6) or you draw a simplified main character using the ball object, freeing up both players for enemies. You could maybe use Missile 1 to draw simplified enemies too, but since missiles use the same number of copies and spacing as their respective player, you're not free to make any individual enemy vanish (i.e. if the leftmost Player 1 copy vanishes, so will the leftmost Missile 1 copy).

[Andromeda Stardust]

I believe it is also possible to update the TIA during mid scanline. For instance, your row of invaders is triplicated on the left side of the screen, then a command is issued to the TIA to change the sprite location. Assuming you use a triple set of enemies at close range to the left of the screen for Player 0, then a triple set of Player 1 enemies in the center of the screen. During the time period while the Player 1 enemies are being rendered, the game writes to the TIA register to change the sprite location of Player 0, increasing the X value so that the row of Player 0 enemies is rerendered on the right side of Player 1. A second write could edit the appearance of Player 0 sprites in order to reflect whether an enemy has been destroyed or not. In this way destroying a Player 0 enemy on the left would not effect the appearance of Player 0 enemies on the right and visa-versa. The shields and the ship at the bottom would use separate subroutines to render independently of the enemies. All this has been done before and is achievable without flicker.

 

See also: Space Investigators...

Edited July 11, 2014 by stardust4ever

[Omegamatrix]

What I really want is five sprites on screen at a time -- the human player's avatar and one row of enemies, all these guys in color ... and a bullet. Preferably four enemies in the row if I can do it. Can I do this?

You will have to use flicker in BB to get more than 3 sprites (plus the hero and bullet). If you stick to only three enemies you could do a flickerless display in any combination as shown below. What I'm doing here is just keeping the position of the leftmost sprite on the screen in ram, and adjusting the position if I need to:

001  one copy, offset 32 pixels to the right
010  one copy, offset 16 pixels to the right
011  two copies close, offset 16 pixels to the right
100  one copy
101  two copies medium
110  two copies close
111  three copies close

I have to say it... in an assembly kernel you can draw more sprites. Circus Atariage scrolls 18 sprites per row all the way across the screen. They are flickering at 30Hz to allow a jumper also to be drawn on the same row as the balloons. The kernel(s) required to do this are quite complex compared to BB. They are designed all with the end goal that the jumper never gets covered up or flickered, and any combination of balloons can be shown/hidden. I'm not bashing BB here, but the point I'm trying to make here is that the Atari can achieve a lot more then one would think.

 

 

I also did a demo of a flicker free 18 sprites being scrolled. The problem is that both P0 an P1 are used up by this, so the jumper couldn't be drawn, and the playfield can't be updated to hide the balloon sprites. But if you are just drawing a row of sprites then it is really easy.

[Andromeda Stardust]

So something as simple as space investigators is impossible to program in Batari Basic?

 

Also huge fan of Circus AtariAge. I didn't mention that one though as I believe it uses DSP+ as some sort of bus stuffing algorithm to display all the sprites?

 

Batari Basic uses multiple sprite tricks to display the six digit score correct? Vanilla Player 0 / Player 1 can in theory only do xyxyxy yet Batari pulls off abcxyz on the score reel. Batari also modifies the playfield mid-scanline for asymmetrical playfields. If you don't need asymmetrical playfields, these instructions can be freed up to manipulate enemies. Use Player 0 and Player 1 to create additional enemies in areas using scanlines above or below the main character. Games back in the day used these techniques. Why not add such features to Batari Basic if the default kernel is too limiting???

[Omegamatrix]

So something as simple as space investigators is impossible to program in Batari Basic?

 

Also huge fan of Circus AtariAge. I didn't mention that one though as I believe it uses DSP+ as some sort of bus stuffing algorithm to display all the sprites?

 

Batari Basic uses multiple sprite tricks to display the six digit score correct? Vanilla Player 0 / Player 1 can in theory only do xyxyxy yet Batari pulls off abcxyz on the score reel. Batari also modifies the playfield mid-scanline for asymmetrical playfields. If you don't need asymmetrical playfields, these instructions can be freed up to manipulate enemies. Use Player 0 and Player 1 to create additional enemies in areas using scanlines above or below the main character. Games back in the day used these techniques. Why not add such features to Batari Basic if the default kernel is too limiting???

So... don't confuse flickering with non-flicker techniques. If you're drawing a hero, bullet, and enemies (multiple copies) all on the same line then you have to limit the enemies to 3 or less (in BB, to have NO flicker). With flickering you can of course do more, but flickering at less then 30Hz quickly becomes unbearable to most people. Using an enhanced DPC+ kernel would still have to flicker the multiple copies of the enemies when you have a hero and bullet on the same line.

 

 

Circus AtariAge does not use DPC+ or bus stuffing to do what it does. It will probably just be a stock 32K rom when realised, with no SuperChip ram. I haven't worked on Circus AtariAge in a long time, so a release is not in the immediate future at all.

[Andromeda Stardust]

It should be possible to use Player 0 and Player 1 on the same line (max 6 sprites) then use player 0 and player 1 elsewhere for completely different objects on another line, without using any sort of flicker or "racing the beam" type sprite manipulation.

[+Random Terrain]

So something as simple as space investigators is impossible to program in Batari Basic?

batari made this many years ago:

 

atariage.com/forums/topic/76213-space-invaders/?p=1516782

 

He "cheated" and used some asm, though.

[BenMcLean]

You guys assume I'm building Space Invaders. No, actually I'm building a stealthy action game. All my characters are people and there are no spaceships in this game. My rows of enemies are patrols of soldiers. ^_^

It sounds like I need to switch to three enemies at a time, which is OK.

 

My idea involved switching the playfield color at runtime ... not sure you guys grasped what I was saying. It would go like this:

 

1. Playfield is bullet colored

2. Fire at bad guy, bad guy dies

3. To show dead badguy, playfield color changes to same as background color, and covers up bad guy. You can't shoot while the dead guy's place is still onscreen.

4. When that patrol goes offscreen, the playfield color switches back to bullet color and you can shoot one from the next patrol.

 

However, if I can have a space inbeteen baddies then that makes things different and I wouldn't need this idea.

Edited July 11, 2014 by BenMcLean

[+Gemintronic]

It's just a matter of setting the NUSIZ for whatever player you want more than one of:

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#nusiz

 

You can have up to three side-by-side copies of your player sprite by adjusting the NUSIZ before every drawscreen.

 

Since you can make sprites really high you can "stack" drawings of multiple characters vertically. Just to show you what I mean here is a screenshot where I stack three character drawings vertically on player0 and player1. I then use NUSIZx = $03 to copy the sprites horizontally three times. It looks like there are many men on screen!

 

[+SpiceWare]

You guys assume I'm building Space Invaders. No, actually I'm building a stealthy action game. All my characters are people and there are no spaceships in this game. My rows of enemies are patrols of soldiers. ^_^

I don't think they've assumed that at all, it's just that all those Space Invaders type games are a good example of how the technique is done - such as Rainbow Invaders which shows the technique with line-by-line coloration:

 

 

Hell, you even acknowledge that in your original post:

 

OK, so I know that the atari can draw more than just two sprites because Space Invaders has a whole row of them.

 

 

One thing that greatly helps is if you make a mockup of what you're trying to accomplish. I've been blogging about Collect, an example of writing a game from scratch, and the very first thing I posted was the mockup:

 

[BenMcLean]

OK. I'll post a mock-up soon

[BenMcLean]

Here is the mockup for my game so far.

 

The game is set in Massachusetts on the afternoon of April 19, 1775 during the aftermath of the Battle of Lexington. The British are marching/retreating back to Boston and you play as a colonial trying to get some of them on the road. YOLO in this game, because if they catch you then they hang you as a traitor.

 

I may want to add some playfield obstacles as well if I can and maybe also some rare enemy types (British officers ... and maybe George III) that might spawn sometimes if development time permits, but this is the basic concept.

 

(later edit) Oh, uh, the score counter keeps track of how many redcoats you've taken out.

Edited July 11, 2014 by BenMcLean

[Omegamatrix]

The mockup looks good! I made a short demo of using NUSIZx to adjust the number of enemies. I've written this demo for clarity, so the IF statements are executed one after the other instead of being double up on each line. I've also used lots of constants and renamed my variables (instead of using a, b, c, etc...). Doing these things helps you and other people read your code, and makes it more manageable in the long run. It also reduces errors.

 

 

NUSIZxDemo.bas

 

NUSIZxDemo.bas.bin

 

 

In the demo the H is my graphic for 'Hero', and E for my graphic for 'Enemy'.

 

[+Gemintronic]

Just a heads up: if both player0 and player1 are multi-color then you lose both missiles in batari BASIC

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#kernelopchart

 

So, your player would have to share the ball with the enemy for bullets

[ZylonBane]

See also: Space Investigators...

So something as simple as space investigators is impossible to program in Batari Basic?

INSTIGATORS.

[BenMcLean]

Just a heads up: if both player0 and player1 are multi-color then you lose both missiles in batari BASIC

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#kernelopchart

 

So, your player would have to share the ball with the enemy for bullets

The enemy doesn't shoot. They chase you. They catch you if they succeed in getting too close. Only one bullet will ever appear on screen at a time and that's the player's bullet.

Edited July 11, 2014 by BenMcLean

[Andromeda Stardust]

INSTIGATORS.

LOL

[BenMcLean]

Omegamatrix, I've been playing with your code example and it's brilliant stuff. I love it. It shows that what I am trying to do is not only totally possible using Batari Basic but might actually be much easier than I expected. I managed to get them in color with the ball appearing onscreen pretty easily, which is awesome!

 

Can I make these sprites appear closer together? They seem a little too far apart.