Originally posted by: SoleGooseProductions
Originally posted by: Mario's Right Nut
I wouldn't worry about saving sprites at this stage. I'd be surprised if you ever have enough going on (that looks okay) to where you actually run out of them. I'd focus more on making your game look cool and colorful than this stuff.
Right now the sprite breakdown for the playing state looks roughly like this:
4 - Hero
1 - Hero's face
2-4 - Weapon A
6 - Weapon B
20-24 - Enemies (generally four sprites each, maximum of 6 large enemies on a given screen, which yes, I realize is high and will cause scan line issues if measures are not taken)
10-12 - Enemy weapons (2 sprites each, though this may be reduced)
? - Dropped items (may be able to reuse enemy sprites?, not sure as I have not tried to do these yet)
? - Objects, items, etc. (doors, keys, chests, switches, whatever; although some of these could be done with background tiles)
? - Graphical flair
2-4 - Weapon B status bar image
It seems to be adding up pretty quickly, but then again there is not a lot more that needs to be accounted for (feel free to point out omissions/oversights). I have probably budgeted too many sprites for certain things, but I'd rather be thinking ahead than running out of room by misusing things unknowingly.
I was kind of trying to avoid this, but since it looks like sprites are the way to go when it comes to an inventory screen there results a question. When switching between the playing state and the inventory state, what would be a decent way of preserving the active positions/tiles/attributes of the on-screen sprites? I have BunnyBoy's update sprite concept working well, meaning that when the start button is pressed the state and screen switch and move all sprites off-screen. When the button is pressed again the game returns to its previous state and the sprites resume their last positions. As it stands, this will work great for cut scenes and other static screens composed solely of background tiles. However, if the inventory screen is made up of sprites and these are updated using the same method as in the playing state (some form of updates will need to occur as weapon and items are added to the player's inventory), this alters their last position, causing them to move when play is resumed. If there were enough free sprites I could simply move the playing ones off-screen and the inventory ones on-screen, but it seems that the playing sprites (hero, enemies, weapons, etc.) will have to be re-purposed for the inventory screen (8 weapons/items using 2-4 sprites a piece, plus whatever else). A clunky way to preserve their positions would be to save the sprite positions/attributes/tiles to a place holder variable and reload it, but I am guessing that there is a more elegant, and less variable costing method. Of course, the other way to do all of this would be to use background tiles for the weapon/item images, but this will eat up a lot of background tiles. A separate CHR page (pardon the terminology if this is not correct) could be devoted to the inventory screen, but this may not be ideal. Any thoughts?
One idea which might help and which I think is reflected in a lot of game engines, NES and modern is to abstract your drawing code away from your "object" code. In other words, you might have some portions of RAM devoted entirely to the abstract idea of an object or "entity" as I call them in my engine. So you might have:
entity_alive: .res MAX_ENTITIES ;where MAX_ENTITIES might be say 8 or something, whatever you want
entity_type: .res MAX_ENTITIES ;this could be an index into a look up table of "brain routines" for each object
entity_x: .res MAX_ENTITIES
entity_y: .res MAX_ENTITIES
entity_sprite_lo: .res MAX_ENTITIES
entity_sprite_hi: .res MAX_ENTITIES
And you'd have a part of your engine called something like:
.proc update_entities
;in here, iterate over entity_alive, and for any entity that is alive, look up its "brain" routine using entity_type
;each entity "brain" routine would be responsible for making that entity move the way it is supposed to.
rts
.endproc
and you might also have:
.proc draw_entities
;in here, interate over all entities that are "alive" and call a metasprite drawing routine and pass it entity_x and entity_y, entity_sprite_lo and entity_sprite_hi (the full address of a metasprite for the entity).
rts
.endproc
The metasprite drawing routine would read the metasprite and shovel the sprites into $0200. Exactly *where* it gets shoveled will depend on your game engine. For simpler games that do not require sorting of any kind, a common technique is to store one variable for the last sprite written (a pointer into $0200), and just shovel metasprites into that point, and let that variable keep wrapping around the page. This is a cheap way to implement sprite flickering, too, but for simpler games this typically won't even show up that much.
But anyway, I just skimmed a ton of details there...but the main point is that if you can separate out the concept of "make stuff move around" from "draw stuff" and treat the sprite page as just the thing to which you draw things, you can switch states in your game with ease and not worry about what sprites were occupying the sprite page. They would still be in your entity variables.
Feel free to PM or email me, too, if you are interested in talking more about any of that stuff.
