Background color table with the bB multisprite kernel?

[jrok]

Does anyone have any ideas about what could potentially be sacrificed in the current bB multisprite kernel in exchange for a static (defined once) background color table? Is it possible to define this table in ROM?

[+Random Terrain]

Maybe SeaGtGruff will see this and have an idea.

[+batari]

I recovered a few cycles scattered around the multisprite kernel that I found when working on Gingerbread Man. I'm not sure if I posted the changes.

 

It may be a little difficult to implement as there are 2 alternate kernel paths and the code. One has some scattered free cycles every other line which might be enough for something. However, the other has just 2 cycles in the most critical path. The alternate path with 2 cycles handles repositioning of sprites, so what you're proposing could work if your sprites are limited in their vertical range. Player 0 would have no issues, but if sprites 1-5 were allowed to move across a background color boundary than glitching would be noticeable.

[jrok]

I recovered a few cycles scattered around the multisprite kernel that I found when working on Gingerbread Man. I'm not sure if I posted the changes.

 

It may be a little difficult to implement as there are 2 alternate kernel paths and the code. One has some scattered free cycles every other line which might be enough for something. However, the other has just 2 cycles in the most critical path. The alternate path with 2 cycles handles repositioning of sprites, so what you're proposing could work if your sprites are limited in their vertical range. Player 0 would have no issues, but if sprites 1-5 were allowed to move across a background color boundary than glitching would be noticeable.

 

Thanks batari. Do you mean that there are enough free cycles in the existing kernel, or in the changes you mention? The virtual sprites I am working on would not cross background color boundaries, but at least one would start its path rendered over a playfield block and end on a background color row. Would that cause the same glitch?

[+batari]

I recovered a few cycles scattered around the multisprite kernel that I found when working on Gingerbread Man. I'm not sure if I posted the changes.

 

It may be a little difficult to implement as there are 2 alternate kernel paths and the code. One has some scattered free cycles every other line which might be enough for something. However, the other has just 2 cycles in the most critical path. The alternate path with 2 cycles handles repositioning of sprites, so what you're proposing could work if your sprites are limited in their vertical range. Player 0 would have no issues, but if sprites 1-5 were allowed to move across a background color boundary than glitching would be noticeable.

 

Thanks batari. Do you mean that there are enough free cycles in the existing kernel, or in the changes you mention? The virtual sprites I am working on would not cross background color boundaries, but at least one would start its path rendered over a playfield block and end on a background color row. Would that cause the same glitch?

Here is what I was talking about. The background colors are aligned with the playfield, so you need as many entries as you have playfield rows in your background color table. To define the table, use " data msk_bgcolor" in the last bank, and place the colors you want.

 

There is a 3 pixel-high area around each color boundary where if you place a sprite, the next background row will fail to update. Provided you position your sprites a certain way and/or use multiple rows of the same color, you might be able to work around this limitation. There does not seem to be an easy way to fix this.

msk_bgcolor.zip

[jrok]

I recovered a few cycles scattered around the multisprite kernel that I found when working on Gingerbread Man. I'm not sure if I posted the changes.

 

It may be a little difficult to implement as there are 2 alternate kernel paths and the code. One has some scattered free cycles every other line which might be enough for something. However, the other has just 2 cycles in the most critical path. The alternate path with 2 cycles handles repositioning of sprites, so what you're proposing could work if your sprites are limited in their vertical range. Player 0 would have no issues, but if sprites 1-5 were allowed to move across a background color boundary than glitching would be noticeable.

 

Thanks batari. Do you mean that there are enough free cycles in the existing kernel, or in the changes you mention? The virtual sprites I am working on would not cross background color boundaries, but at least one would start its path rendered over a playfield block and end on a background color row. Would that cause the same glitch?

Here is what I was talking about. The background colors are aligned with the playfield, so you need as many entries as you have playfield rows in your background color table. To define the table, use " data msk_bgcolor" in the last bank, and place the colors you want.

 

There is a 3 pixel-high area around each color boundary where if you place a sprite, the next background row will fail to update. Provided you position your sprites a certain way and/or use multiple rows of the same color, you might be able to work around this limitation. There does not seem to be an easy way to fix this.

 

Thanks, batari! This is great!