Whenever people discuss the advantages of using 128x128 chunks and path swappers, you'd usually hear about how it makes making more dynamic level layouts easier, compared to Sonic 1's bulky chunks with a very limited loop + roll tunnel system. However, what I haven't really seen documented properly is the amount of RAM you save by shrinking down the chunks, and I'm not referring to how the layout data gets shifted into ROM. Let me explain.
In original Sonic 1, you had 256x256 chunks. A chunk is a 2D grid of 16x16 blocks, so, a 256x256 pixel sized chunk would be 16x16 blocks in size. A block definition in a chunk is a word, so the size of each chunk is 16x16x2 bytes, or 512 bytes. A chunk ID in the level layout data is a byte, which limits you to 256 chunks per level. 512x256 bytes gets you a $20000 byte limit of chunk data. Now, of course, Sonic 1 loads all the chunks into RAM, and there's only $10000 bytes of RAM on the Genesis, and you'd still need plenty of it to handle the game logic, so they kept their chunk usage as small as they could, and wound up limiting it to $A400 bytes in RAM.
Let's move on to 128x128 chunks. Same deal with the formatting. You get 8x8 blocks in size per chunk, which means each chunk is 8x8x2 bytes in size, or 128 bytes. With a limit of 256 chunks, still, you get a hard limit of 128x256 bytes of chunk RAM, or $8000 bytes. Of course, you could have guessed that considering chunks are 4x smaller here, but nevertheless, this is quite a save. The 128x128 chunk hard limit is $2400 bytes smaller than Sonic 1's 256x256 chunk soft limit. That's $2400 bytes of free RAM in levels at $FF8000-$FFA3FF (the ending does use some of it in the $FF9xxx range for decompressing the ending flowers, though, even in stock Sonic 1, but eh).
To me, this is the best advantage to using the smaller chunks, besides the practicality advantages. Of course, this makes the layout data 4x as large, but in terms of RAM usage in Project Two Eight specifically, again, that all got shifted into ROM. Even if you kept the layouts in RAM, that would just be a $C00 byte increase, which still leaves you with $1C00 of free RAM.
In original Sonic 1, you had 256x256 chunks. A chunk is a 2D grid of 16x16 blocks, so, a 256x256 pixel sized chunk would be 16x16 blocks in size. A block definition in a chunk is a word, so the size of each chunk is 16x16x2 bytes, or 512 bytes. A chunk ID in the level layout data is a byte, which limits you to 256 chunks per level. 512x256 bytes gets you a $20000 byte limit of chunk data. Now, of course, Sonic 1 loads all the chunks into RAM, and there's only $10000 bytes of RAM on the Genesis, and you'd still need plenty of it to handle the game logic, so they kept their chunk usage as small as they could, and wound up limiting it to $A400 bytes in RAM.
Let's move on to 128x128 chunks. Same deal with the formatting. You get 8x8 blocks in size per chunk, which means each chunk is 8x8x2 bytes in size, or 128 bytes. With a limit of 256 chunks, still, you get a hard limit of 128x256 bytes of chunk RAM, or $8000 bytes. Of course, you could have guessed that considering chunks are 4x smaller here, but nevertheless, this is quite a save. The 128x128 chunk hard limit is $2400 bytes smaller than Sonic 1's 256x256 chunk soft limit. That's $2400 bytes of free RAM in levels at $FF8000-$FFA3FF (the ending does use some of it in the $FF9xxx range for decompressing the ending flowers, though, even in stock Sonic 1, but eh).
To me, this is the best advantage to using the smaller chunks, besides the practicality advantages. Of course, this makes the layout data 4x as large, but in terms of RAM usage in Project Two Eight specifically, again, that all got shifted into ROM. Even if you kept the layouts in RAM, that would just be a $C00 byte increase, which still leaves you with $1C00 of free RAM.
Last edited: