Yeah, the size of the level shouldn't matter much, you just have to know WHERE to find the collision data for any given block, based on level coordinates. As long as you can manipulate level coordinates in a way that allows you to traverse the data structures you need to in order to find the collision attributes for the block under those coordinates, it'll work.Sogona wrote:I already asked about this in another thread, but from what others have said it seems to be more involved when there's scrolling. After thinking about it for a bit, though, isn't the only difference really that you're working with 16-bit values instead of 8-bit?
Could "something else" be water? Personally, I think that 4 types is too little. What if in the future you decide to add ice, lava, conveyor belts, spikes (only one side hurts), slopes, and so on? I'd reserve AT LEAST 4 bits for the type. You can get by with 2 bits in a basic game, but it's not very expansible.I think I want to try and have collision data work like attribute data, where there can be four different types of collisions (Nothing, solid, death, something else) and 4 16x16 pixel blocks can be packed into one byte.
Here's another thing I'd do differently... I'd much rather have the collision information be an attribute of the metatile. Think about it: a metatile is likely to ALWAYS have the same solidity ANYWHERE it's used. If it has rocks on the bottom and grass on the top, it'll probably ALWAYS be solid, so think about all the ROM space you'll waste specifying that - EVERY - SINGLE - INSTANCE - of that metatile is solid. Each time you use any metatile, anywhere, BAM, 2 bits lost. Use the same metatile 4 times and you already wasted 8 bits on it, enough to specify 256 different types if you stored that information in the metatile itself rather than in a separate map. And I bet that most metatiles will be used way more than just 4 times!So for each room there could be a pointer table for the collision data for each screen.
If you actually needed a metatile to be solid in some places but not others for some reason, you'd waste much less space by creating a duplicate metatile that looks the same but has different collision information, but I honestly doubt that would happen much. For consistence, you generally want things that look the same to behave the same, otherwise you'll confuse the player.
Another advantage of making the solidity an attribute of the metatile, besides not having to painstakingly draw/type an overlay collision map for every room of every level, is that you can reuse the code you already wrote to fetch tiles for scrolling. You already have the working logic to locate metatiles in the level map, so you can use the exact same logic (if not the exact same routine(s), depending on how exactly you implemented the scrolling) to find them, the only difference is that when you do, you'll not read its tiles or palette information, but its collision information.
I didn't realize you were using RLE for the level data... Are you decompressing the RLE on the fly to fill the tile and attribute buffers without buffering small sections of the level first? Still, independent collision maps for the whole game would take so much space that giving up on the RLE might still result in lower ROM consumption overall... You'd have to check how much ROM the RLE compression is saving you versus how much ROM the raw collision maps take.
