Planet Bob

It's still not as flickery as Pac-Man.

If you single out a "robot" and try following its path, you'll notice the main problem - regular "worst case clusters". There an "unlucky" sprite may disappear completely for a couple of frames.

 

Now this is just random movement. The real Robotron AI will explicitely boost the building of such clusters, especially with all enemies heading towards the players spot

IMO my two-sprite-multiplex engine offered only marginal improvement, though it could undoubtedly be bettered.

 

24 sprites: http://www.atariage.com/forums/index.php?a...;showentry=1127

 

I also wrote a space shooter using the same engine with 12 sprites (two for the player's ship) plus missiles as bullets. This one has complete collision detection. I don't think I ever shared it, though (except I think at NWCGE a year ago), so I'll post it now: http://www.atariage.com/forums/index.php?a...;showentry=2943

Could you detail your approach a bit? I'd be interested in how many different scanlines your engine needs and what tasks they perform.

 

I think I'm possibly overcomplicating things with mine, as I require switching between 4 different 2 scanline blocks, requiring at least a 4 scanline gap between two displayed sprites IIRC.

 

In fact, I find it a major achievment that you got a 2 sprite multiplexer going: How do you reposition one sprite while you're drawing the other?

Hi Manuel,

Could you detail your approach a bit? I'd be interested in how many different scanlines your engine needs and what tasks they perform.

 

I think I'm possibly overcomplicating things with mine, as I require switching between 4 different 2 scanline blocks, requiring at least a 4 scanline gap between two displayed sprites IIRC.

 

In fact, I find it a major achievment that you got a 2 sprite multiplexer going: How do you reposition one sprite while you're drawing the other?

I don't know if you missed it but Bob posted about this on [stella]. There should be some source there too.

Excellent!

 

I must have completely missed that thread back then.

Could you detail your approach a bit? I'd be interested in how many different scanlines your engine needs and what tasks they perform.

 

I think I'm possibly overcomplicating things with mine, as I require switching between 4 different 2 scanline blocks, requiring at least a 4 scanline gap between two displayed sprites IIRC.

 

In fact, I find it a major achievment that you got a 2 sprite multiplexer going: How do you reposition one sprite while you're drawing the other?

I went into a bunch of detail on my blog when I was working on this. See:

http://www.atariage.com/forums/index.php?a...;showentry=1127

http://www.atariage.com/forums/index.php?a...;showentry=1138

http://www.atariage.com/forums/index.php?a...;showentry=1163

http://www.atariage.com/forums/index.php?a...;showentry=1167

 

If you read the comments in those threads you will see that you helped me think through things!

 

The main problem is that there just isn't enough time to do all the stuff you need to do, both in-kernel and outside the kernel.

 

I think my algorigthm (in the kernel) goes like this (assuming we begin by displaying no sprites):

#1. Check for sprite begin. yes=goto #2, else goto #1

#2. Position player 0.

#3. Draw player 0, check for next sprite beginning (yes=goto #4, else check for end of player 0, yes=goto #1, else goto #3)

#4. Draw player 0, position player 1.

#5. Draw player 0, player 1, check for end of player 0 (goto #6), check for end of player 1 (goto #3)

#6. Draw player 1, check for next sprite beginning (yes=goto #7, else check for end of player 1 (yes=goto #1, else goto #6)

#7. Draw player 1, position player 0. Goto #5

 

A *lot* of mini kernels. And I can't remember exactly but there were some issues with the flicker being screwed up if the sprite list wasn't sorted correctly. It was very complicated. I probably should revisit it at some point, I suppose.

Were I not so dismally lacking in round tuits, I might try a robot-swarm game in 4A50 banking using something a little bit like my ruby runner kernel. Basically that would give an 80x128 bitmap overlaid on a 20x16 color grid (each grid square would be 4x4 double-height pixels). Each grid square could accommodate one background color (black or dark gray) and one of four foreground colors (cyan, orange, magenta, or greenish-yellow). Unlimited stuff on screen all for 30Hz flicker blinds.

A *lot* of mini kernels. And I can't remember exactly but there were some issues with the flicker being screwed up if the sprite list wasn't sorted correctly. It was very complicated. I probably should revisit it at some point, I suppose.

 

Thanks for reposting all the details

I think one of the issues might be that you're rather slow in skipping "too late" sprites?

 

Were I not so dismally lacking in round tuits, I might try a robot-swarm game in 4A50 banking using something a little bit like my ruby runner kernel. Basically that would give an 80x128 bitmap overlaid on a 20x16 color grid (each grid square would be 4x4 double-height pixels). Each grid square could accommodate one background color (black or dark gray) and one of four foreground colors (cyan, orange, magenta, or greenish-yellow). Unlimited stuff on screen all for 30Hz flicker blinds.

 

Do you think you can possibly update this bitmap fast enough to still have it qualify as an action game?

Were I not so dismally lacking in round tuits, I might try a robot-swarm game in 4A50 banking using something a little bit like my ruby runner kernel. Basically that would give an 80x128 bitmap overlaid on a 20x16 color grid (each grid square would be 4x4 double-height pixels). Each grid square could accommodate one background color (black or dark gray) and one of four foreground colors (cyan, orange, magenta, or greenish-yellow). Unlimited stuff on screen all for 30Hz flicker blinds.

 

I'd like to see you try that.

Do you think you can possibly update this bitmap fast enough to still have it qualify as an action game?

 

If you watch the coinop game, or at least the 7800 version, I don't think even it moves every sprite at once. It kind of cycles through them.

I'd like to try this in Stella. What is the banking scheme? Just getting a blank screen right now.

I'd like to try this in Stella. What is the banking scheme? Just getting a blank screen right now.

 

You have to press fire to make it start, since I just quickly hacked this into the Colony 7 source

Do you think you can possibly update this bitmap fast enough to still have it qualify as an action game?

 

I should think so. The tricky part would be deciding what objects should move freely and what objects should be bound to the grid. Overlaying objects would look like a mess, so my inclination would be to have most objects be bound to the grid, but allow a fast-moving object to share a grid square with a slower-moving object. The slower-moving object would be obscured when the faster one was on top of it, but such a condition shouldn't last long. The most practical arrangement would probably be to allow the player to move freely and have everything else confined to the grid. If any part of the player shares a grid square with an object, the player is deemed to have collided.

So, it comes down to how many grid-cells you can update per frame?

 

I'd assume each moving enemy would require clearing of 1-2 cells and writing 1-2 cells.

Also if the player can move freely, it may require clearing 1-4 and writing of (1-4)*2 cells, since you'd have to restore the enemies on those cells and the player.

 

So, the worst case would possibly be:

 

4C+8W + n*(2C+2W)

 

(C= Clears, W= Writes, n=# of Enemies)

 

So what would you think, what would the maximum n be for a single frame?

So, it comes down to how many grid-cells you can update per frame?

 

I'd assume each moving enemy would require clearing of 1-2 cells and writing 1-2 cells.

Also if the player can move freely, it may require clearing 1-4 and writing of (1-4)*2 cells, since you'd have to restore the enemies on those cells and the player.

 

I would figure one cell for the grunts, obstacles, and probably enemy shots. Some larger enemies would be 2x2. Having shots take up a full cell would be ugly, but would make them show up far better than any other reasonable method of handling them.

 

The player would be unable to share a cell with anything else, but updating the player could still require read-modify-write drawing on four double-cell areas of the bitmap (cells are four pixels wide, but bytes are of course eight).

 

Not sure the game would work well enough to be worth $50 or so, and I have too many other things on my plate to want to branch very far in that direction.

After seeing this, I think the flicker is too severe in return for the number of sprites generated. I think you have to somehow use the 2 and 3 copy mode. Either have robots move in squads or have them pass in and out of squad formation like Super Football does when the players run up to the scrimmage line.

After seeing this, I think the flicker is too severe in return for the number of sprites generated.

 

Unfortunately that already is just enough sprites required for the first Robotron level. The 2nd already needs more and in higher levels the Arcade seems to throw 100 or more sprites on the screen

 

I think you have to somehow use the 2 and 3 copy mode. Either have robots move in squads or have them pass in and out of squad formation like Super Football does when the players run up to the scrimmage line.

 

That would definitely be an option. But it seems pretty given that Robotron is way more than what the poor VCS can chew.

That would definitely be an option. But it seems pretty given that Robotron is way more than what the poor VCS can chew.

Yes... but this might work for, oh... the Grid Bugs levels in Tron.

Yes... but this might work for, oh... the Grid Bugs levels in Tron.

 

Definitely!