Grauw’s RPG in development

Ah good! That gives me some confidence this is a good approach worth implementing . And thanks for elaborating about your set-up, it’s interesting to read!

I’ve a similar idea for a 32x32 circular buffer in RAM which represents the “local” area. Kind of like a simulated name table in RAM. Then code would only have to deal with one buffer in a fixed memory location. Tile animations could modify and flag tiles for repaint, and entities could activate as they enter it. However it’s not implemented yet and maybe it’s not needed, it would require copying a bunch of data within a strict frame budget, so I would have to stagger the copying to limit the overhead.

About the collision indirection, tiles aren’t referenced by index but by a memory address so I can’t take the approach you mentioned. However I do have some unused bits in the memory address that I could encode a few collision bits in, or I can add more bytes per tile.

But another thing I’m more convinced about after watching Reidrac’s video is that, originally I thought it would be efficient to encode certain things like animations and collision in the tile data, since you only need to consider the tiles the player is standing on. That’s why I set up the tiles as objects which are referenced indirectly, so I could extend the type of the tiles with additional functionality. However in practice it isn’t really working out, so along with this partitioning I’ll remove that indirection on the tiles, keep ’em dumb. And specify those other things as separate entities, the partitioning will improve the efficiency of looping over them.

If the game is for MSX2+, you have at least 64KB of RAM. So even if it is a ROM, you can copy the map data into RAM at load time (when moving to another area) and exchange the page slots to RAM-ROM when required.
This allows to have a more alive environment, as you can modify/update data in RAM like animated ones even if they are out of screen area.

About special tiles, I use standard data (common) for tiles, reducing its data a lot, and for special cases simply GameObjects placed in the map. Can be an invisible GameObject (no gfx attached), with a collision coinciding with the tile area size to cover, so you see the tile but the collision is handled by the involved GameObjects scripts. This is for some specials like items and interactive ones.

The other approach, is more general and more focused on special collision tiles, like spikes, as if you have many of them (separated so each block requires its own GameObject), adding so many objects could be much for the CPU.
In this case I set a number from which lower/greater (the best for you) than N are considered special tiles, i.e. we will use the lower. Then the collision module, when checks for map collisions against the tiles the character is over, it checks if it is lower than N, and if the case adds it to a list of special tiles collided. Then the MapCollision script of the character reads that list and handles it.
Yet working on it as the ideal would be to have a list of (tile, count) pairs so you get the tile and how many of them are in collision with the character, but handling lists in this way is CPU consuming, so currently they are simply added, so repeated values, and then let the MapCollision character script handle it.
There is an approach at the cost of using (N*2)+1 bytes to store that list, and I think slower for the CPU to handle it on the script, as it would be an indirect indexed table instead a single direction incremental indexing one.
The value of N can vary on each area or even per character, setting its value before checking collisions.
Something that adds much versatility is to add other byte of flags, that can be read and used by the scripts, but only adding a single byte doubles the size, and most of the tiles in the map will not use it. Currently using a single byte per tile and adjust the scripts and N value for it.

DarkSchneider, good points!

As for the RAM, a practical complication is that if I swap RAM in page 2 that leaves me just with two 8K segments in page 1 which are both going to be code. And I really want to stream various things from ROM through page 2. Maybe I could use the DOS environment (via a disk ROM) in combination with ROM in page 1 or 2, could be nice. Or switch page 2 between ROM and RAM, but not too often. Either way it’s kind of awkward. For now I think I have enough memory in page 3.

Regarding special tiles, indeed using entities (game objects) for them is my current thought. Good to have another confirmation that this is a good set-up. Also nice example about the spikes, indeed there the above approach won’t work, just like solid tiles. So it seems tile collision is still definitely needed. Thanks for the explanation.

To optimise the collisions, I was thinking to generate a “CollisionPair” object for each two colliders that can collide with each other, store the sum of the collider sizes on it (as an optimisation), and then each tick loop over them to evaluate which ones collide. The list of collision pairs would be part of those 16x16 partitions, and I only evaluate colliders that are in the same partition.