01-20-2022, 08:35 AM
As I have been working on my platformer engine, I have a few observations:
1. Allowing the game loop to run asynchronous to the vblank can lead to faster speeds. Any time I have my game loop wait for the next vblank, it ends up feeling too slow. However, running the loop with no period of waiting at the end can lead to inconsistent results, such as a period where you're moving (i.e. processing animations and detecting collision) vs standing still. My compromise for optimal performance is to set an hblank counter to 0 at the beginning of the loop and check that it is is greater than a specific value (60 in my current case) before ending the loop. In this way the loop takes the same amount of time regardless of whether or not it has to do much.
2. No emulator I have tried seems to run my rom the same as real hardware. Emulators run too fast when not waiting for the vblank, and real hardware seems to get bogged down in a way the emulators don't reproduce (i.e. when moving in a large level with sprites nearly maxed out). This means I can't rely on emulation as a sole means of testing, and just about all changes have to be tested on real hardware. I am in progress on optimizing my code to run more efficiently in some of the more frequently used functions to get better performance on real hardware. I have it running pretty well on real hardware at this point.
3. As best I can figure it, there are 2 methods for managing enemy sprites.
1 is to have enemies be persistent in a room, so your enemy limit is limited by the number of spare sprites you have compared to the sprites you need for the desired enemies. With this method, all enemies in a room could chase you to the edges of the room and all be rendered on screen at once. I believe Dark Arms uses a method like this. All enemies in a room seem to be persistent and can (if they're mobile) all move to a specific part of the room and be rendered at the same time (i.e. likely total sprites used in a given room is less than or equal to 64 unless some hblank trickery is employed to make it appear that there are more). I think this is more in line with a Castlevania SOTN style game (with a few exceptions of repeating enemies that come in from the edges of the screen like the medusa heads, or the respawning zombies that come up out of the ground).
2 is to dynamically recycle sprites. To do this you have to somehow limit the number of enemies that can be on screen at once (i.e. maybe the enemies won't jump off of a ledge or they have some barrier separating different groups), and manage reassigning sprites to other enemies at other areas of a room. This could get complicated to manage, depending on how it's done. Metal Slug: 1st Mission, for example, seems to make use of a limited number of enemies on screen at a time. The enemies disappear if they move off screen, and can respawn if the player goes back to their spawn point. I think Sonic Pocket Adventures uses a similar method. No enemies are going to chase you from one side of the map to the other. They have a limit of how far they move before they stop and end up off screen and into oblivion.
I am currently opting for method 1. All enemies are persistent in a room, and they are moving even when off screen, their sprites only rendered when they are on screen. In this way an enemy can be placed at the opposite far edge of the room and, if the player enters and just remains in place, the enemy will eventually makes its way to the player. Leaving and re-entering a room resets it, in Castelvania SOTN fashion, and each enemy starts at its original spawn point. While I haven't implemented any enemies that respawn within the same instance of a room, I may do so.
1. Allowing the game loop to run asynchronous to the vblank can lead to faster speeds. Any time I have my game loop wait for the next vblank, it ends up feeling too slow. However, running the loop with no period of waiting at the end can lead to inconsistent results, such as a period where you're moving (i.e. processing animations and detecting collision) vs standing still. My compromise for optimal performance is to set an hblank counter to 0 at the beginning of the loop and check that it is is greater than a specific value (60 in my current case) before ending the loop. In this way the loop takes the same amount of time regardless of whether or not it has to do much.
2. No emulator I have tried seems to run my rom the same as real hardware. Emulators run too fast when not waiting for the vblank, and real hardware seems to get bogged down in a way the emulators don't reproduce (i.e. when moving in a large level with sprites nearly maxed out). This means I can't rely on emulation as a sole means of testing, and just about all changes have to be tested on real hardware. I am in progress on optimizing my code to run more efficiently in some of the more frequently used functions to get better performance on real hardware. I have it running pretty well on real hardware at this point.
3. As best I can figure it, there are 2 methods for managing enemy sprites.
1 is to have enemies be persistent in a room, so your enemy limit is limited by the number of spare sprites you have compared to the sprites you need for the desired enemies. With this method, all enemies in a room could chase you to the edges of the room and all be rendered on screen at once. I believe Dark Arms uses a method like this. All enemies in a room seem to be persistent and can (if they're mobile) all move to a specific part of the room and be rendered at the same time (i.e. likely total sprites used in a given room is less than or equal to 64 unless some hblank trickery is employed to make it appear that there are more). I think this is more in line with a Castlevania SOTN style game (with a few exceptions of repeating enemies that come in from the edges of the screen like the medusa heads, or the respawning zombies that come up out of the ground).
2 is to dynamically recycle sprites. To do this you have to somehow limit the number of enemies that can be on screen at once (i.e. maybe the enemies won't jump off of a ledge or they have some barrier separating different groups), and manage reassigning sprites to other enemies at other areas of a room. This could get complicated to manage, depending on how it's done. Metal Slug: 1st Mission, for example, seems to make use of a limited number of enemies on screen at a time. The enemies disappear if they move off screen, and can respawn if the player goes back to their spawn point. I think Sonic Pocket Adventures uses a similar method. No enemies are going to chase you from one side of the map to the other. They have a limit of how far they move before they stop and end up off screen and into oblivion.
I am currently opting for method 1. All enemies are persistent in a room, and they are moving even when off screen, their sprites only rendered when they are on screen. In this way an enemy can be placed at the opposite far edge of the room and, if the player enters and just remains in place, the enemy will eventually makes its way to the player. Leaving and re-entering a room resets it, in Castelvania SOTN fashion, and each enemy starts at its original spawn point. While I haven't implemented any enemies that respawn within the same instance of a room, I may do so.