Okay, first off this isn't some wimpy code example or something. This is more aimed at specific, but more complex, part for NES code. This one I'm working on now is metasprites. This is a over view of very fine details of the engine:
The game will have an object system with X objects, assigned at compile time. Basically, a program goes through each object, pulls it's metasprite (When this gets done and written, then I'll add animation frames), and then basically says "Process this" to another program, the decoder+OAM rotation program.
The decoder program first looks at the number of tiles, the first byte in a header that contains the tiles used. The second and third bytes in the header are the x pixels used, Y pixels used for flipping. But the OAM routine has two sets of pointers. One that points to $00 and $40 at the beginning. What it does is takes the object number EOR'd with the frame number and the first bit is then used to select the $00 or $40 index. If the object gets the $00, the first (least index) is copied to the index variable to use. The X is then put to another variable to know the origin later. If the object gets the first index, which decreases to put the OAM in the screen, it checks to see if we have enough tiles. If so, we take the 2nd index, subtract the "requested tiles" and then put that OAM index to the variable to use later. If there's not enough tiles requested, then we use the first index value but then use and tell the program the 2nd one is still the origin. We can do this because there's also a count that counts down each time a tile is put on the screen, so we KNOW we will never over run another tile.
Okay, now that that is said, we have a problem. I disable sprites who's coords overflow and are not on the right side of the screen. In the engine, if the Object YX flip bits are set, I add the X/Y offsets in the header. If they go to the wrong side of the screen, I set a bit in a variable called TestShowing. Those bits go "00YX.0000" so far, which are the disable bits for the bases of the sprite. But after each tile movement, I am going to set the two high bits to test if it's BACK on a good side of the screen. So we have "YXYX.0000". Basically I am going to load the value, ASL twice, EOR with the original, and then and #%11000000. If it's not zero, the tile does not get written. We have a problem with this if the backwards buffer is going because it starts in the middle of OAM data, it can't subtract down like would be easy because we have to keep sprite priority in order.
Would your solution just be keep the empty spaces in OAM regardless? My solution is looking like I will take how many tiles are not used, and move the OAM objects down, and then when setting the new location, just make sure the tiles used get subtract, which isn't too bad, but might not be worth the CPU. Just wondering what you guys think on this one, as it's trick, complex, and might have places for optimization just from my way of attacking it.
Disclaimer: don't expect working code today, hopefully in the next few days. I have about...175 lines of code so far, not even close to done with this program, and have not tested any part once. So it'll probably take a little bit to debug after I get the way I want it to work down. But, every line of code is very well commented so it shouldn't be hard at all to debug.
The game will have an object system with X objects, assigned at compile time. Basically, a program goes through each object, pulls it's metasprite (When this gets done and written, then I'll add animation frames), and then basically says "Process this" to another program, the decoder+OAM rotation program.
The decoder program first looks at the number of tiles, the first byte in a header that contains the tiles used. The second and third bytes in the header are the x pixels used, Y pixels used for flipping. But the OAM routine has two sets of pointers. One that points to $00 and $40 at the beginning. What it does is takes the object number EOR'd with the frame number and the first bit is then used to select the $00 or $40 index. If the object gets the $00, the first (least index) is copied to the index variable to use. The X is then put to another variable to know the origin later. If the object gets the first index, which decreases to put the OAM in the screen, it checks to see if we have enough tiles. If so, we take the 2nd index, subtract the "requested tiles" and then put that OAM index to the variable to use later. If there's not enough tiles requested, then we use the first index value but then use and tell the program the 2nd one is still the origin. We can do this because there's also a count that counts down each time a tile is put on the screen, so we KNOW we will never over run another tile.
Okay, now that that is said, we have a problem. I disable sprites who's coords overflow and are not on the right side of the screen. In the engine, if the Object YX flip bits are set, I add the X/Y offsets in the header. If they go to the wrong side of the screen, I set a bit in a variable called TestShowing. Those bits go "00YX.0000" so far, which are the disable bits for the bases of the sprite. But after each tile movement, I am going to set the two high bits to test if it's BACK on a good side of the screen. So we have "YXYX.0000". Basically I am going to load the value, ASL twice, EOR with the original, and then and #%11000000. If it's not zero, the tile does not get written. We have a problem with this if the backwards buffer is going because it starts in the middle of OAM data, it can't subtract down like would be easy because we have to keep sprite priority in order.
Would your solution just be keep the empty spaces in OAM regardless? My solution is looking like I will take how many tiles are not used, and move the OAM objects down, and then when setting the new location, just make sure the tiles used get subtract, which isn't too bad, but might not be worth the CPU. Just wondering what you guys think on this one, as it's trick, complex, and might have places for optimization just from my way of attacking it.
Disclaimer: don't expect working code today, hopefully in the next few days. I have about...175 lines of code so far, not even close to done with this program, and have not tested any part once. So it'll probably take a little bit to debug after I get the way I want it to work down. But, every line of code is very well commented so it shouldn't be hard at all to debug.