Hey all. I was talking about the level format in my current project in another thread and Disch gave me a simple but great idea on how to improve it, so I felt I could try it again for object placement.
Without going into details about the level format, all that I need to say is that it's essentially a 2-dimensional array of indexes pointing to 256x256-pixel blocks that contain terrain information.
My initial idea to place objects in those "screens" was to point to a ROM location (16 bits, with the highest indicating the presence of objects) where the object definitions for each screen were, in addition to indicating what 256x256-pixel block to use. That'd work fine, but I'd need 3 bytes per "screen", and most of them don't have objects, so that sounds like a huge waste.
Now, I feel it's important that the objects placed in a screen are somehow tied to it, so that I can easily locate them when it's time to load them, and so that I can save a few bytes from not having to define the high bytes of their coordinates (because I already know the coordinates of the screen where they are), as opposed to many games that just hold a big list of objects/enemies sorted by X and Y coordinates (works great in games that do not scroll vertically, but not so much otherwise).
The first solution I could think of was to also index the object definitions of each screen, limiting them to 256 (only 256 screens from the level map would have objects - or they'd reuse each other's objects, but that doesn't work so well -, which seems kinda limited). Then, each screen in the level map would only use 2 bytes (instead of 3), one pointing to the screen map and the other pointing to the object definition block. But I'd have the overhead of creating a table to translate the object definition indexes into their locations.
Does anyone have any thoughts on this?
Without going into details about the level format, all that I need to say is that it's essentially a 2-dimensional array of indexes pointing to 256x256-pixel blocks that contain terrain information.
My initial idea to place objects in those "screens" was to point to a ROM location (16 bits, with the highest indicating the presence of objects) where the object definitions for each screen were, in addition to indicating what 256x256-pixel block to use. That'd work fine, but I'd need 3 bytes per "screen", and most of them don't have objects, so that sounds like a huge waste.
Now, I feel it's important that the objects placed in a screen are somehow tied to it, so that I can easily locate them when it's time to load them, and so that I can save a few bytes from not having to define the high bytes of their coordinates (because I already know the coordinates of the screen where they are), as opposed to many games that just hold a big list of objects/enemies sorted by X and Y coordinates (works great in games that do not scroll vertically, but not so much otherwise).
The first solution I could think of was to also index the object definitions of each screen, limiting them to 256 (only 256 screens from the level map would have objects - or they'd reuse each other's objects, but that doesn't work so well -, which seems kinda limited). Then, each screen in the level map would only use 2 bytes (instead of 3), one pointing to the screen map and the other pointing to the object definition block. But I'd have the overhead of creating a table to translate the object definition indexes into their locations.
Does anyone have any thoughts on this?