Limiting Flicker using bB Multisprite Kernel with Sprite in same vertical

[Fort Apocalypse]

I know this is mentioned as a problem, but is there any trick I can use in bB to limit flicker when I have 5 sprites (using multisprite) in the same vertical scanline?

[SeaGtGruff]

I know this is mentioned as a problem, but is there any trick I can use in bB to limit flicker when I have 5 sprites (using multisprite) in the same vertical scanline?

You can't have 5 independent sprites on the same line without a lot of flicker. But you *can* have up to 6 non-independent sprites on the same line without any flicker, if you display 3 copies of player0 (with NUSIZ0), along with 3 copies of one of the other players. Of course, that means the copies will have the same colors and shapes as each other, and will move together as if they're in formation.

 

Michael

[Fort Apocalypse]

You can't have 5 independent sprites on the same line without a lot of flicker. But you *can* have up to 6 non-independent sprites on the same line without any flicker, if you display 3 copies of player0 (with NUSIZ0), along with 3 copies of one of the other players. Of course, that means the copies will have the same colors and shapes as each other, and will move together as if they're in formation.

 

Michael

 

Thanks, Michael. I was hoping there was some cool trick to limit the flicker, but that's just me wishful thinking!

 

It's not a big deal, really. I just wanted to be able to start all of the cars off on a vertical line (actually 4 cars, a flag, and the pitstop are all on the same scanline, but the pitstop (player 1) does not flicker and the rest flicker badly). I'll start use imaginary horizontal start/finish lines instead of vertical ones.

[CurtisP]

It's not a big deal, really. I just wanted to be able to start all of the cars off on a vertical line (actually 4 cars, a flag, and the pitstop are all on the same scanline, but the pitstop (player 1) does not flicker and the rest flicker badly). I'll start use imaginary horizontal start/finish lines instead of vertical ones.

 

Are you sure you mean vertical? There should be no flicker in a verticle line:

 

X

|

X

|

X

|

X

 

But in a horizontal line you would have lots

 

X-X-X-X

 

Just checking...

[Fort Apocalypse]

It's not a big deal, really. I just wanted to be able to start all of the cars off on a vertical line (actually 4 cars, a flag, and the pitstop are all on the same scanline, but the pitstop (player 1) does not flicker and the rest flicker badly). I'll start use imaginary horizontal start/finish lines instead of vertical ones.

 

Are you sure you mean vertical? There should be no flicker in a verticle line:

 

X

|

X

|

X

|

X

 

But in a horizontal line you would have lots

 

X-X-X-X

 

Just checking...

 

 

I'm not really sure why it is flickering so much actually. I changed the sprites to not be on the same vertical or horizontal (at least as far as I can tell - maybe there is some overlap - don't know. Posted the code and bin here

 

Edit: Actually Michael figured it out in the other topic!

Edited September 8, 2007 by Fort Apocalypse

[SeaGtGruff]

Edit: Actually Michael figured it out in the other topic!

Here's a summary of what you need to keep in mind regarding player positioning when using the multisprite kernel:

 

You can place player0 on the same line as any of the other players (player1 through player5) without getting flicker, because player0 is the only player drawn with GRP0, whereas player1 through player5 are all drawn with GRP1.

 

When positioning two of the GRP1 sprites vertically, you need to leave at least 2 blank lines between them, otherwise they will flicker.

 

Note that blank lines within the player data are counted as non-blank lines, because those blank lines will still have to be drawn with GRP1, just as though they were non-blank.

 

For example, if all of the players were defined as 8 lines of data, the GRP1 players' positions would need to differ from each other by at least 10 lines.

 

In this particular case, each GRP1 sprite was defined as 8 lines of data, but only the 4 middle lines had any shape on them-- the top 2 and bottom 2 lines were blank. Those blank lines within the player data were unnecessary, and were making it so the GRP1 sprites couldn't get as close together vertically as one might have expected by just looking at them on the game screen. Removing those blank lines will let the GRP1 sprites be positioned within 6 lines of each other as measured by the differences between their y values; otherwise they'd have had to be positioned at least 10 lines apart to avoid flickering.

 

Also, the GRP1 sprites have different ranges in their x and y values than player0 does. That is, if you set player0 and player1 to identical shapes, set player0x and player1x to the same values as each other, and also set player0y and player1y to the same values as each other, player0 and player1 will be drawn at different locations on the screen. In particular, player1 will be drawn 8 pixels to the left of player0, and 2 lines above it. To make them overlap exactly, player1x would need to be 8 more than player0x (i.e., player1x = player0x + 8, or player0x = player1x - 8), and player1y would need to be 2 less than player0y (i.e., player1y = player0y - 2, or player0y = player1y + 2).

 

Furthermore, the GRP1 sprites cannot go as high on the screen as player0 can. In particular, player0y can go up to 90, and anything higher than that will cause 1 or more of its lines to start disappearing off the top of the screen (e.g., 91 would cause 1 of its lines to go offscreen, 92 would cause 2 of its lines to go offscreen, etc.). But player1y can go up to only 84, and anything higher that that will cause the entire player1 sprite to disappear.

 

Also, the behavior at the bottom of the screen is a little different as well. In particular, player0y can go as low as 3+A, where A is the number of lines in player0 (e.g., if player0 were 8 lines tall, then this would give us 11 as the lowest "safe" value for player0y). Anything below that will cause 1 or more of its lines to go offscreen, and the last line that does *not* go offscreen will be drawn twice as tall as normal (e.g., if player0 were only 1 line tall, and player0y were set to 3-- which would be 1 less than the lowest safe value of 4-- then that 1 line of player0 would still be onscreen, but would be twice as tall as it should be). On the other hand, player1y can go as low as 1+A, where A is the number of lines in player1 (e.g., if player1 were 8 lines tall, then this would give us 9 as the lowest "safe" value for player1y). Anything below that will cause the same behavior as with player0, but with the addition that the entire player1 sprite will flicker.

 

Michael

Edited September 8, 2007 by SeaGtGruff

[CurtisP]

Good writeup, Michael. Some of those points will have to make it into my tutorial when get to multiple sprites.

[SeaGtGruff]

Good writeup, Michael. Some of those points will have to make it into my tutorial when get to multiple sprites.

Keep in mind that this relates to v1.0, so it's possible that some of that info might need to be changed for future versions of bB.

 

Michael

[supercat]

Keep in mind that this relates to v1.0, so it's possible that some of that info might need to be changed for future versions of bB.

 

One thing that may be useful to have as an option would be to specify one of several coordinate systems using compiler directives, and then have bB do whatever is necessary to make them work (subject to limitations of what sprites can actually do). For example, have an option in any kernel to set 0,0 be the upper-left corner. Then bB could, if necessary, do something like:

  lda #84
 clc
 sbc player0y
 sta player0y

before and after the drawscreen code. Even if a particular kernel favors some particular method of storing coordinates, changing them before and after invoking the kernel would cost comparatively little, and would make it easier to port games from one kernel to another.

[CurtisP]

One thing that may be useful to have as an option would be to specify one of several coordinate systems using compiler directives, and then have bB do whatever is necessary to make them work (subject to limitations of what sprites can actually do). For example, have an option in any kernel to set 0,0 be the upper-left corner. Then bB could, if necessary, do something like:

  lda #84
 clc
 sbc player0y
 sta player0y

before and after the drawscreen code. Even if a particular kernel favors some particular method of storing coordinates, changing them before and after invoking the kernel would cost comparatively little, and would make it easier to port games from one kernel to another.

 

But then the variable's value would be different after the drawscreen than before, which would be bad in so many ways.

[supercat]

But then the variable's value would be different after the drawscreen than before, which would be bad in so many ways.

 

The particular transform I illustrated is self-inverting, so if it's done before and after drawscreen, the net effect will be to leave the variable unchanged. Other coordinate transforms (e.g. adding 1 or subtracting 1) would require different code to do and undo, but that shouldn't be a problem.

[+batari]

But then the variable's value would be different after the drawscreen than before, which would be bad in so many ways.

 

The particular transform I illustrated is self-inverting, so if it's done before and after drawscreen, the net effect will be to leave the variable unchanged. Other coordinate transforms (e.g. adding 1 or subtracting 1) would require different code to do and undo, but that shouldn't be a problem.

This is something I should do, as it will allow people to reuse most of their code should they decide one kernel doesn't quite meet their needs.

[CurtisP]

This is something I should do, as it will allow people to reuse most of their code should they decide one kernel doesn't quite meet their needs.

 

As long as you have a compatibility option to turn it off.