I’ve been working out the logic for an object reference map. This type of map is just like a tile reference map (tilemap) except it’s sprite based. I originally needed something for Lunar for overlapping parts of the town/houses/dungeons/etc.
What’s the purpose of an object map? Pretty much the same purpose of the tilemap (in this case). I needed flexibility, so I decided to see what could be applied in the most extreme cases. Say, something like a whole separate movable map layer. Something solid enough in operation to be a foreground map. Now, I could have made something up from scratch to fit the need/hardware. But that’s less challenging. Thinking through some games that I’ve always wanted to demo with this sort of technique… Sonic for the Genesis comes to mind.
Looking at Chemical zone and applying it against a pseudo tilemap. 16×16 was too small to satisfy most areas, because of the limited (in this case) 64 entries of the SAT. 16×32 and 32×16 still presented limitations. 32×32 on the other hand fit perfectly. To keep transition from screen edges, one would need a smaller window than the sprite bandwidth limit. 240 or 232 pixels wide instead of the normal 256. 240 is doable, seeing as how the VDC drops cells automatically when the sprite limit is met on a scanline. That would allow free scrolling left and right with seemless transition (no wholes or such – a solid ‘edge’ across the screen is doable). Limit the screen height to ~192 pixels and use a ‘window’ either top or bottom of the screen for status stuff (pretty standard). And you have yourself a nice clipped window setup for sprite-made foreground layer.
Now, 32×32 is fairly large. And it’s also pretty wasteful in areas. I had originally though maybe a four layer map (one 32×32, one 16×16, one 16×32, one 32×16). As long as you didn’t purposely overlap sprite entries, you solve the problem of small sections of the 32×32 that only needs small ’tiles’. The idea works, but its simplicity ends up bloating logic and size (or resource for decompressing).
I took another approach at representing theses 32×32 segment. Meta-cells. The 32×32 entry is just a reference to an object that is build of attributes, instead of direct hardware reference. Another layer before it gets to the hardware layer. This isn’t anything new. This concept has been around for a long time. PCE games often use tilemaps that reference metatiles. Usually in defines of 16×16 sections (four 8×8 real tiles).
The concept is the same. The metacell references an object that may actually be a direct reference to a hardware level element (single 32×32 sprite cell). But it also might reference a group of 16×16 sprite cells. Actually, any number of hardware sprite configurations. And other attributes like sprite flipping, palette attribute, and sprite/sprite and BG/sprite priority settings. The cool thing about the object map, as opposed to just a tilemap, is that each entry isn’t limited to to the grid point it was assigned to. The grid point of the 32×32 sectioned map, is just a reference point. Because sprites are independent objects, you can assign relative offsets to that map point. That’s the power of an object map. The flexibility over a tilemap, but a mapping point system to more easily parse and handle objects on a larger field without having to parse and apply coords/logic to every single object, and then more so once it reaches the ‘view window’.
This makes it easier to apply objects for pixel accurate priority between sprites and BG layers (which many RPGs do on the PCE). There are sooo many parameters and features you can directly apply to objects too. Like the previous mentioned masking/priority system, and have it go ‘live’ when an active sprite is near the required zone (instead of having there all the time. Many PCE games do this too).
An Object map with 32×32 segment size makes it possible to mimic a separate foreground/background layer, without eating up the Sprite Attribute Table entry list (or to keep it minimal as possible). It also makes it possible to have more object oriented behavior when required. With the attempt to keep logic/cpu resource at a realistic/less complex level. The real trick comes when you have to write the SAT sorting routine. A fully loaded dynamic SAT list isn’t particularly easy to write the coder for. But not beyond the skill of any coder (just a pain depending on the requires of the game engine VS how much cpu resource you throw at it).