8bitMicroGuy wrote:RAM compression!?
I didn't mean compression in RAM (although that's also possible), I meant a compression scheme in ROM that can be decompressed on the fly.
You can't compress the RAM! If you can, you'd have to can decompress which would need more RAM.
You most certainly can! You're thinking of compression schemes like RLE or LZ, which have to be decompressed in chunks before you can use the data, but there are other schemes that allow for random access, so you can decompress on the fly, without having to decode big blocks of data to RAM.
The Sonic games on the MD/Genesis are a good example of this: Levels are stored in the ROM using traditional LZ and Huffman schemes, but once decompressed to RAM this data is not a flat level, it's actually a map of 256x256-pixel chunks (in Sonic 1 and CD - 2, 3 and Knuckles use 128x128-pixel chunks), which are composed of 16x16-pixel metatiles. This means that levels are still compressed, in RAM, but this specific compression format is easily accessible in real-time.
Also, my games are kind of SMB3 and Minecraft where blocks can be broken, opened, etc.
Levels can still be changed to a certain degree even when they are stored in ROM. In my engine, modifiable blocks are stored as objects, and they claim a few bytes of RAM to represent the states of each block in the object. For example, a breakable wall that's 2x8 blocks. The object has a pointer that indicates the first of the 2 bytes (16 bits) of RAM it needs to represent the state of its 16 blocks. I dedicate 128 bytes for this purpose, meaning I can have up to 1024 modifiable blocks in each level (or level section, if I prevent backtracking from a certain point), even though my levels are in ROM.
Do you think that loading level data from ROM only while treating the ? blocks as active objects would be a better idea? Then I'd have more space + ? blocks. Is it possible?
That's how I go about it. Nearly everything that's not terrain in my engine is an active object, which can point to RAM locations where their state can be saved. This is also interesting because I can reuse screens and use objects to make them slightly different, by adding walls, platforms, and such.