Many moving objects!!

[Brian's Man Cave]

Not sure if this is obvious or not... but how did games like Frogger have so many moving objects? Since you can only have 8 sprites on the screen... 

 

[carlsson]

Most probably software sprites, which is using the BACKTAB with symbols that you either redefine on every frame, or have predefined in many states so you change which GRAM to display for each frame. I'm unsure if there are examples here in the forum, in the compiler distribution or either of Oscar's books on software sprites but many of us have developed more or less working routines that we probably could clean up and share as examples of how you (not) should do it.

 

On other systems that completely lack hardware sprites, your options are either movements in steps of 8 pixels or software sprites where you need to keep track of which pixels to enable and mix with any background objects in a somewhat complex manner, but for a game like Frogger where everything moves in straight horizontals without any other conflicting background objects and only regular hardware sprites (MOB) on top, it gets much easier.

[+nanochess]

Basically you draw a 16-pixel wide truck with 0px offset. (2 GRAM cards)

 

Then you draw the same truck at 2px offset (now you use 3 cards)

 

Then you draw the same truck at 4px offset (another 3 cards)

 

And finally you draw the same truck at 6px offset (another 3 cards)

 

Then you can animate the truck smoothly on screen simply by changing the card number on screen (not requiring to redefine anything)

 

This approach of course uses rapidly the available cards. 11 cards for 16px wide objects, or 7 cards for 8px wide objects.

 

For the bottom part probably is using 11+7+7+7 cards (32 GRAM cards total)

 

The upper part uses (1+3+3+3)×2 GRAM cards = 20 cards total (notice repeated tiles)

 

52 GRAM cards in total leaving enough for the other graphics (frog, crocodile, fly) and the redefined score indicator.

[Brian's Man Cave]

not sure what you mean by the offset?  are you meaning you draw the bitmap with a offset..

[+nanochess]

26 minutes ago, Brian's Man Cave said:

not sure what you mean by the offset?  are you meaning you draw the bitmap with a offset..

I mean drawing the truck on squared paper.

 

Every block of 8x8 pixels is a card. By offset I mean moving it inside the card. You can see easily how a 16 px. wide truck requires three cards once displaced by 2 pixels to right.

 

For example, this is an arrow bitmap:

 

BITMAP "11000000"

BITMAP "11110000"

BITMAP "11111100"

BITMAP "11111111"

BITMAP "11111111"

BITMAP "11111100"

BITMAP "11110000"

BITMAP "11000000"

 

Now if we want to displace it smoothly by two pixels *without* using sprites, we need TWO GRAM cards:

 

BITMAP "00110000"

BITMAP "00111100"

BITMAP "00111111"

BITMAP "00111111"

BITMAP "00111111"

BITMAP "00111111"

BITMAP "00111100"

BITMAP "00110000"

 

BITMAP "00000000"

BITMAP "00000000"

BITMAP "00000000"

BITMAP "11000000"

BITMAP "11000000"

BITMAP "00000000"

BITMAP "00000000"

BITMAP "00000000"

 

And we would need to add further displacement (another two frames each using two GRAM cards) to complete the cycle until we use again the first arrow bitmap.

 

[Brian's Man Cave]

ahh! that was what I was thinking you meant but I wasn't sure.  So its basically like cartoon animation...  

 

I was thinking of trying that with my keystone game... seeing as I use up all the sprites.

[carlsson]

Here is an example I put together, using constantly redefined GRAM. As you know, ROM space is cheap today (unlike 40 years ago) but GRAM is expensive so this method uses 3 GRAM cards per 16x8 sprite. I don't know if you need objects that swap sides from left to right, but it was cheap to implement.

 

I tried to use as self explanatory variable names as possible plus a liberal amount of REM statements but ask if there is something that seems tricky. Also if other people have alternative solutions, I'd be eager to see those in code.

 

softsprite.bas

[SpicedUp!]

This is really interesting. If you had enough cart space you could create some very cool effects just using those background blocks

[Zendocon]

On 7/15/2021 at 5:51 PM, Brian's Man Cave said:

I was thinking of trying that with my keystone game... seeing as I use up all the sprites.

Unfortunately, this is where the Intellivision has a disadvantage from the Atari.  The Intellivision STIC ship maintains some control that the Atari graphics chip doesn't have.  You can't multiplex sprites by moving them lower on the screen after they've been drawn somewhere higher.  Activision took full advantage of that capability in many of their games, as well as the "palette swapping" trick to draw those pretty sunsets you often see.

 

If you look at Deep Pockets: Super Pro Pool & Billiards, you'll see the 16 balls are drawn by maintaining "virtual sprites" and drawing each of the 8 existing sprites in every other position each video frame, resulting in flickering.  That's about your only choice here.

[SpicedUp!]

23 hours ago, Zendocon said:

Unfortunately, this is where the Intellivision has a disadvantage from the Atari.  The Intellivision STIC ship maintains some control that the Atari graphics chip doesn't have.  You can't multiplex sprites by moving them lower on the screen after they've been drawn somewhere higher.  Activision took full advantage of that capability in many of their games, as well as the "palette swapping" trick to draw those pretty sunsets you often see.

 

If you look at Deep Pockets: Super Pro Pool & Billiards, you'll see the 16 balls are drawn by maintaining "virtual sprites" and drawing each of the 8 existing sprites in every other position each video frame, resulting in flickering.  That's about your only choice here.

I've been learning about Intellivsion recently because I used to own one as a kid and want to try to make a (very) simple game. And that does seem very strange the way you can't multiplex sprites. If you could - it would be a *much* better system. I was thinking about doing a game with a swinging rope. I assume on Atari you can do this with one sprite - repeated vertically. But on Intellvision I think you would have to use background tiles. Also a game like a vertical space shooter. It would be much easier to get more objects on screen if you could multiplex.

 

Does that flicker you talk about look ok on a CRT? Because I know you have more persistence on that

 

[Zendocon]

2 minutes ago, SpicedUp! said:

I've been learning about Intellivsion recently because I used to own one as a kid and want to try to make a (very) simple game. And that does seem very strange the way you can't multiplex sprites. If you could - it would be a *much* better system. I was thinking about doing a game with a swinging rope. I assume on Atari you can do this with one sprite - repeated vertically. But on Intellvision I think you would have to use background tiles. Also a game like a vertical space shooter. It would be much easier to get more objects on screen if you could multiplex.

The best example of a swinging rope is in Pitfall!  Because its width can only go to 2 tiles (8 pixels, doubled in width), the top of the vine on the Intellivision port appears to be higher up in the trees, whereas on the Atari port the top of the vine is visible.

2 minutes ago, SpicedUp! said:

Does that flicker you talk about look ok on a CRT? Because I know you have more persistence on that

It should look the same.  I've played Deep Pockets both on emulators and on original hardware.

[carlsson]

I'm not sure if you can reduce flicker in any way, since you have to wait for vertical blank before a change of sprite locations takes effect.

 

Something like this is the shortest program I can think of to showcase the effect:

  MODE 1
  DEFINE 0,1,gfx:WAIT
  x = 80 :  y = 20

loop:
  SPRITE 0,x + $0200,y + $100,$0807:WAIT
  y = 70-y
  GOTO loop

gfx:
  BITMAP "........"
  BITMAP "...oo..."
  BITMAP "..oooo.."
  BITMAP ".oooooo."
  BITMAP ".oooooo."
  BITMAP "..oooo.."
  BITMAP "...oo..."
  BITMAP "........"

 

It can be an interesting effect in itself, but not very nice to look at plus that you anyway would want to context switch what each sprite refers to on every second frame.

[SpicedUp!]

On 11/23/2021 at 8:20 PM, carlsson said:

I'm not sure if you can reduce flicker in any way, since you have to wait for vertical blank before a change of sprite locations takes effect.

 

Something like this is the shortest program I can think of to showcase the effect:

 

  MODE 1
  DEFINE 0,1,gfx:WAIT
  x = 80 :  y = 20

loop:
  SPRITE 0,x + $0200,y + $100,$0807:WAIT
  y = 70-y
  GOTO loop

gfx:
  BITMAP "........"
  BITMAP "...oo..."
  BITMAP "..oooo.."
  BITMAP ".oooooo."
  BITMAP ".oooooo."
  BITMAP "..oooo.."
  BITMAP "...oo..."
  BITMAP "........"

 

 

It can be an interesting effect in itself, but not very nice to look at plus that you anyway would want to context switch what each sprite refers to on every second frame.

Thank you. I haven't actually done any programming yet but will try that out when I do. I've read both the INTY BASIC books but haven't had time to start anything.

 

Slightly off topic since it's not the Intellivsion but I read the guy who wrote R-Type 2 on Gameboy got twice as many sprites on screen by drawing on alternate frames - just because that screen has so much persistance they don't flicker. I thought that was an interesting trick!

Edited December 7, 2021 by SpicedUp!

[Zendocon]

2 minutes ago, SpicedUp! said:

Slightly off topic since it's not the Intellivsion but I read the guy who wrote R-Type 2 on Gameboy got twice as many sprites on screen by drawing on alternate frames - just because that screen has so much persistance they don't flicker. I thought that was an interesting trick!

Right.  The original Game Boy, before the Game Boy Pocket, had a "passive scan" screen, which is why games like Super Mario Land looked blurry when panning.  I saw a similar trick on a Sega Dreamcast VMU programming demo, which exploits the "passive scan" to create the apparency of shades of gray on what is otherwise a monochrome display.

[SpicedUp!]

6 minutes ago, Zendocon said:

Right.  The original Game Boy, before the Game Boy Pocket, had a "passive scan" screen, which is why games like Super Mario Land looked blurry when panning.  I saw a similar trick on a Sega Dreamcast VMU programming demo, which exploits the "passive scan" to create the apparency of shades of gray on what is otherwise a monochrome display.

Yes that was the downside sadly - games look blurry when they scrolled. Have to say when I read about R-Type 2 that was the first time I had ever heard of someone doing that. So maybe not many games took advantage of that persistance

 

That's cool about the VMU. I love the tricks people come up with. I've never really played a game on one apart from Virtua Tennis when I blew my friend's mind by playing facing away from the TV. (it shows the game in mini form on the VMU)

Edited December 7, 2021 by SpicedUp!

[carlsson]

So out of curiosity, I dug into the generated ASM code to see if there is anything to speed it up even for the most trivial case. Clearly waiting for vertical blank causes the flicker, and even hand coded in assembler it makes no visual difference. Of course this variant has zero flexibility and practical use anyway.

 

  MODE 1
  DEFINE 0,1,gfx:WAIT

  ASM MVII #592,R0
  ASM MVO R0,_mobs
  ASM MVII #2055,R0
  ASM MVO R0,_mobs+16

loop:
  ASM MVII #276,R0
  ASM MVO R0,_mobs+8
  WAIT

  ASM MVII #326,R0
  ASM MVO R0,_mobs+8
  WAIT

  GOTO loop

gfx:
  BITMAP "........"
  BITMAP "...oo..."
  BITMAP "..oooo.."
  BITMAP ".oooooo."
  BITMAP ".oooooo."
  BITMAP "..oooo.."
  BITMAP "...oo..."
  BITMAP "........"

 

I think various combinations of soft sprites and MOBs are the way to go if you want to animate more than 8 things at a time. Depending on your colour choices, the flicker may be more or less annoying but it will always be there.

[Zendocon]

1 hour ago, SpicedUp! said:

That's cool about the VMU. I love the tricks people come up with. I've never really played a game on one apart from Virtua Tennis when I blew my friend's mind by playing facing away from the TV. (it shows the game in mini form on the VMU)

VMU was a very neat idea that was greatly underutilized.  It worked very well with games likes Sonic Shuffle.

[SpicedUp!]

23 hours ago, Zendocon said:

VMU was a very neat idea that was greatly underutilized.  It worked very well with games likes Sonic Shuffle.

I didn't have that one. I liked it in Resident Evil : CV where it showed your health. Normally you had to visit the menu to see it. I'm sure the main reason SEGA made it (the VMU) was they hoped to get some kind of game on the level of Pokemon going on the system. The way you could link them together too pointed towards that