Jump to content
IGNORED

Background color table with the bB multisprite kernel?


jrok

Recommended Posts

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...