I wasn't really sure where this should go...
I'm writing a multidirectional scrolling platforming game with collision detection for any angle of slope line you can give it. (Well... with a few restrictions.)
Now that it has gotten to a playable state the worries that I'm not a good enough programmer to make everything planned run fast enough for NES are beginning to take form.
So I am looking for an emulator that might do that following, or an emulator author that might add the following. None of it's NEEDED, but I'd sure like to see them.
The ability to see an average of how many cycles a subroutine/block of code (given a starting, and ending address for the subroutine/block of code) takes, and how many times the starting address is executed to see how many iterations went into the average. It could keep track of the least number of cycles, and the most number of cycles the block of code took overall as well. It'd also be nice to see the number of times the routine was run in the last frame, and the number of cycles it collectively took in the last frame. (Maybe an average for the last frame, but it's much less important)
You might say I could just add breakpoints to any current emu debugger and use the PPU cycles to figure it out. That could work but it's very tedious and doesn't help me figure out a good average anyway. Take my routine for storing metatiles from screens in ROM into RAM. I have 42 screens that could possibly be decoded, and some of them certainly appear more than others. This routine is run at least twice every time the scroll passes a screen boundary to write the two new screens to RAM. Some (single) screens take 2.5% of the frame time. Some take maybe 5-7.5%. Planning for the worst case scenario would be a great idea normally, but the worst case scenario set of two screens takes up 25% percent of the frame time. But that will NEVER ever happen unless I create some truly stupid level data. And finding a possible worst case scenario involves me going through each screen that's created. Though that routine is called so rarely that I don't care if it's slow. I'm not going to lose any sleep if the game loses a frame when the game needs to update these tiles.
My routine that checks for collisions is the real culprit, because it's run quite a few times in each frame, and its worse case scenario is pretty terrifying, but it's impossible for it to come up EVERY time the routine is called. And the routine's BEST case scenario is fast enough, and occurs more often, I think. This routine is especially hard to test every case for, because it depends on the collision line, and how many pixels away the user is for both X and Y. This routine is the real reason I want this, since it basically runs the whole game, and I'm running out of clever ideas to make it faster.
Honestly, I want this feature to know if I should give up or not on the game, since it's becoming very difficult for me to tell if it can really work quickly as planned, but I'd use it a lot if I don't give up as well. I may just have to change the style of game to something more like N+ (with little or no enemies) with this information. The game will certainly be fast enough with just a character and a scrolling map. I'm just worried that with the massive amount of CPU cycles just the main character's routine takes up, that even very few enemies might make the game slow down. So am I a baby for wanting such a thing? Are there any other strange features you would like to see in an emulator? Discuss!
I'm writing a multidirectional scrolling platforming game with collision detection for any angle of slope line you can give it. (Well... with a few restrictions.)
Now that it has gotten to a playable state the worries that I'm not a good enough programmer to make everything planned run fast enough for NES are beginning to take form.
So I am looking for an emulator that might do that following, or an emulator author that might add the following. None of it's NEEDED, but I'd sure like to see them.
The ability to see an average of how many cycles a subroutine/block of code (given a starting, and ending address for the subroutine/block of code) takes, and how many times the starting address is executed to see how many iterations went into the average. It could keep track of the least number of cycles, and the most number of cycles the block of code took overall as well. It'd also be nice to see the number of times the routine was run in the last frame, and the number of cycles it collectively took in the last frame. (Maybe an average for the last frame, but it's much less important)
You might say I could just add breakpoints to any current emu debugger and use the PPU cycles to figure it out. That could work but it's very tedious and doesn't help me figure out a good average anyway. Take my routine for storing metatiles from screens in ROM into RAM. I have 42 screens that could possibly be decoded, and some of them certainly appear more than others. This routine is run at least twice every time the scroll passes a screen boundary to write the two new screens to RAM. Some (single) screens take 2.5% of the frame time. Some take maybe 5-7.5%. Planning for the worst case scenario would be a great idea normally, but the worst case scenario set of two screens takes up 25% percent of the frame time. But that will NEVER ever happen unless I create some truly stupid level data. And finding a possible worst case scenario involves me going through each screen that's created. Though that routine is called so rarely that I don't care if it's slow. I'm not going to lose any sleep if the game loses a frame when the game needs to update these tiles.
My routine that checks for collisions is the real culprit, because it's run quite a few times in each frame, and its worse case scenario is pretty terrifying, but it's impossible for it to come up EVERY time the routine is called. And the routine's BEST case scenario is fast enough, and occurs more often, I think. This routine is especially hard to test every case for, because it depends on the collision line, and how many pixels away the user is for both X and Y. This routine is the real reason I want this, since it basically runs the whole game, and I'm running out of clever ideas to make it faster.
Honestly, I want this feature to know if I should give up or not on the game, since it's becoming very difficult for me to tell if it can really work quickly as planned, but I'd use it a lot if I don't give up as well. I may just have to change the style of game to something more like N+ (with little or no enemies) with this information. The game will certainly be fast enough with just a character and a scrolling map. I'm just worried that with the massive amount of CPU cycles just the main character's routine takes up, that even very few enemies might make the game slow down. So am I a baby for wanting such a thing? Are there any other strange features you would like to see in an emulator? Discuss!