jrok Posted June 22, 2009 Share Posted June 22, 2009 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? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted June 24, 2009 Share Posted June 24, 2009 Maybe SeaGtGruff will see this and have an idea. Quote Link to comment Share on other sites More sharing options...
+batari Posted June 24, 2009 Share Posted June 24, 2009 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. Quote Link to comment Share on other sites More sharing options...
jrok Posted June 24, 2009 Author Share Posted June 24, 2009 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? Quote Link to comment Share on other sites More sharing options...
+batari Posted June 27, 2009 Share Posted June 27, 2009 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 Quote Link to comment Share on other sites More sharing options...
jrok Posted June 29, 2009 Author Share Posted June 29, 2009 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! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.