05-05-2020, 07:05 AM
I have been experimenting with the NGPC C framework, and I am developing a platformer engine with it. I'll try to document progress and concepts/methodology here.
Tiles and sprite are some that I drew up pretty quickly to test functionality, and are not necessarily representative of what I will end up with in a "final" game.
So far the engine supports a main sprite of 3x3 tiles that is fixed in the center while the level tiles are put into one of the scroll planes. The scroll plane is then moved left or right, and the next tiles needed are drawn on demand just off-screen, so they seamlessly scroll in when the player moves.
On that note, the scroll plane coordinate manipulation is not obviously integrated into the C framework, at least not as obvious functions. These variables are defined in ngpc.h and can be set as needed to alter scroll plane coordinates:
SCR1_X
SCR1_Y
SCR2_X
SCR2_Y
These are 8 bit numbers, so only 0-255 are supported, and the plane will loop back onto the screen as the limits are crossed. Because the coordinates are limited until they loop back, the max width (and I assume the same for height, but did not test) is 32 tiles (256 pixels). The screen shows 20 tiles (or rather 120 pixels - with a potential for partial tiles on the edges), so there is space to work with on the plane outside of the visible screen.
Without streaming in tiles on demand, you'd be stuck with a level that is limited to 32 tiles wide.
I have done several experiments, and the NGPC is actually pretty capable of quickly redrawing the entire visible screen (i.e. erase and redraw tiles every loop), but I was noticing some flickering in some cases on real hardware when doing so. It's more efficient, and eliminates flickering, to just draw the next set of tiles just off screen and let them scroll in. For example, if you're moving right, before the next column of tiles scrolls onto the screen, they get drawn. This operation only has to draw a column of 19 tiles at a time, instead of redrawing the entire visible screen (20x19=380 total tiles).
I am basically infinitely looping the coordinates of the scroll plane, tracking them, and figuring out the coordinates of the next column (according to the direction the player is moving), read them in the from the level map, and draw them.
At any rate, using tiles on demand is a way to increase the amount of space you can use. I currently have a level array defined that is 19 rows high by 100 columns wide. Each position in the array represents a tile. The value of each tile that needs to be drawn is stored, and 0 is a blank tile that erases the space if it is occupied. You would be limited by the amount of storage space, but the width of a level used this way does not have to have a fixed limit.
Note, that I think you could reasonably create a Zelda-type game that utilizes the limits of the scroll plane without managing on demand tiles, where each "room" would be made to fit inside the 32x32 tile space, but you would have to design it with that limit in mind.
Next steps, in no particular order are:
-layered character sprite for more than 3 colors
-character sprite animation
-collision mapping and detection
-character jumping
Once those are in place, I'll proceed with enemies and items.
Time will tell if anything comes of this, but I am enjoying working with the NGPC so far.
Tiles and sprite are some that I drew up pretty quickly to test functionality, and are not necessarily representative of what I will end up with in a "final" game.
So far the engine supports a main sprite of 3x3 tiles that is fixed in the center while the level tiles are put into one of the scroll planes. The scroll plane is then moved left or right, and the next tiles needed are drawn on demand just off-screen, so they seamlessly scroll in when the player moves.
On that note, the scroll plane coordinate manipulation is not obviously integrated into the C framework, at least not as obvious functions. These variables are defined in ngpc.h and can be set as needed to alter scroll plane coordinates:
SCR1_X
SCR1_Y
SCR2_X
SCR2_Y
These are 8 bit numbers, so only 0-255 are supported, and the plane will loop back onto the screen as the limits are crossed. Because the coordinates are limited until they loop back, the max width (and I assume the same for height, but did not test) is 32 tiles (256 pixels). The screen shows 20 tiles (or rather 120 pixels - with a potential for partial tiles on the edges), so there is space to work with on the plane outside of the visible screen.
Without streaming in tiles on demand, you'd be stuck with a level that is limited to 32 tiles wide.
I have done several experiments, and the NGPC is actually pretty capable of quickly redrawing the entire visible screen (i.e. erase and redraw tiles every loop), but I was noticing some flickering in some cases on real hardware when doing so. It's more efficient, and eliminates flickering, to just draw the next set of tiles just off screen and let them scroll in. For example, if you're moving right, before the next column of tiles scrolls onto the screen, they get drawn. This operation only has to draw a column of 19 tiles at a time, instead of redrawing the entire visible screen (20x19=380 total tiles).
I am basically infinitely looping the coordinates of the scroll plane, tracking them, and figuring out the coordinates of the next column (according to the direction the player is moving), read them in the from the level map, and draw them.
At any rate, using tiles on demand is a way to increase the amount of space you can use. I currently have a level array defined that is 19 rows high by 100 columns wide. Each position in the array represents a tile. The value of each tile that needs to be drawn is stored, and 0 is a blank tile that erases the space if it is occupied. You would be limited by the amount of storage space, but the width of a level used this way does not have to have a fixed limit.
Note, that I think you could reasonably create a Zelda-type game that utilizes the limits of the scroll plane without managing on demand tiles, where each "room" would be made to fit inside the 32x32 tile space, but you would have to design it with that limit in mind.
Next steps, in no particular order are:
-layered character sprite for more than 3 colors
-character sprite animation
-collision mapping and detection
-character jumping
Once those are in place, I'll proceed with enemies and items.
Time will tell if anything comes of this, but I am enjoying working with the NGPC so far.