Is There a pfpixel Hack for the Multisprite Kernel?

[+Random Terrain]

Since we have pfread, is there a way to make bB handle pfpixel, so no matter which side you're trying to place it, the pixel will automatically appear on both sides? I'm trying to convert sprite coordinates to use with pfread, but I can't get the numbers right unless I have pfpixel to show me what I'm doing right or wrong.

For example, mix it with Superchip RAM so the playfield can be in RAM, then add a special version of pfpixel that will automatically convert any numbers past the side that doesn't exist to the side that does exist. 16 would be converted to 0, 17 would be converted to 1, 18 would be converted to 2 and so on.

The programmer would use the numbers in the first line below with this special Superchip Multisprite version of pfpixel, and bB would convert the numbers to look like the second line:

---

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15

---

[+Random Terrain]

Updated my first post to explain in more detail.

[bogax]

not sure what you want

 

your second line is just the first line mod 16

so if you have a number from the first line the number on the second line is number & 15

[+Random Terrain]

If I read the bB page correctly, the Multisprite Kernel playfield is in ROM, so that's why we can't use pfpixel. If the Multisprite Kernel could be mixed with Superchip RAM, I hope that would mean that the playfield could be in RAM. Now that I think about it, if they could be mixed, would the playfield still have to be mirrored?

 

If we'd still have to use a mirrored playfield, bB would have to convert the pfpixel numbers for the programmer who is using pfpixel since any number past 15 might crash the program. bB would have to convert 16 to 0, 17 to 1, 18 to 2 and so on so the programmer won't crash the program by trying to use a number over 15.

[+Gemintronic]

What would be nice is some way to mix and match playfield data segments at least. Maybe stacking 3 or more playfield: statements to make a complete multi sprite kernel background.

 

I doubt anyone can take up the mantle of improving the multi sprite kernel besides batari.