For the whole of my stay in the Sonic ROM hacking scene, I've only ever worked with 256x256 chunks (except for the few times I've tried making levels in Classic Sonic Simulator, which I find to be somewhat more frustrating than with the regular ROM hacking tools, so that really doesn't count). When I thought of a potential switch to 128x128, I honestly was not looking forward to it, especially after having created a level with plenty of different 256x256 chunks (around $E0 different chunks used, although I could've been smarter about chunk allocation). Now, I'm in the middle of creating my first somewhat serious 128x128 level, and I must say, I'm actually having fun! Sure, the level being based off of a Sonic 1 zone does make it more painful to place specific groups of chunks, but otherwise, I actually feel my level is coming up more varied than something I'd have made with 256x256 chunks for the same zone! Plus, I can do plenty of chunk optimizations for the zone in question, leaving me with way more free chunk slots than I'd initially envisioned. However, I still can't decide which of the two chunk types I truly prefer. I did read about the general consensus being that 128x128 chunks are better, but there are still some things about them that I really don't like, with the worst one being having to make way more chunks to fulfil a specific purpose that I'd be able to achieve with fewer 256x256 chunks. For example, the S tube and loops from GHZ would respectively occupy 3 256x256 chunks (4 if you're working without path swappers). However, in 128x128, something like that would cost you 12 chunks to make! Another fault of the 128x128 chunks I know of is layout size, which quadruples when put against a 256x256 chunk level of the same size. So, I decided to come here and spark this debate (probably once more, because a debate like this must've happened before). What chunk size do you prefer? Do you believe the pros and cons of the two chunk sizes should affect which size one should pick? Would it be worth it to have both systems in a ROM hack? Do tell whatever you can on the subject, for I'm really curious. There's one more thing I specifically would like to know. For Sonic 1 level design, and to design levels strictly based on the original zones, would you stick with 256x256 chunks? Or do you see value in using 128x128 chunks?
From a purely technical standpoint, I personally prefer 128x128 chunks. A 128x128 chunk only occupies 0x80 bytes, which makes 256 chunks fit in 0x8000 bytes. 256x256 chunks take quadruple the space, and you can't truly use all the available chunk IDs unless you referenced them from a source of memory that can hold the data, like in ROM, since 256 256x256 chunks would cost 0x20000 bytes. Sonic 1 limits the chunk buffer in RAM to 0xA400 bytes, which only allows for 0x52 chunks. With stage layout data, yes, with smaller chunks, the amount of memory needed for layouts increases. In the case of 256x256 -> 128x128 chunks, that's a 0xC00 byte increase. In total, chunks + layout data with 256x256 chunks takes up 0xA800 bytes (0xA400 + 0x400), and 0x9000 bytes (0x8000 + 0x1000) with 128x128 chunks. That's a 0x1800 byte save in RAM. You say that a fault with 128x128 chunks is that it requires multiple chunks to build a structure of sorts. I'm gonna go ahead and say that a fault of 256x256 chunks is that it's not precise enough at times. I've had times where I had to duplicate chunks just to change a corner of it, which wouldn't be an issue with smaller chunks. It doesn't take any more or less memory to use 4 chunks to fill in a 256x256 space than using 1 256x256 chunk, it just takes up more chunk IDs. Personally, I would prefer to use up more chunk IDs than to be making duplicate chunks and using up more memory. I do wonder with your chunk usage with the 0xE0 amount of chunks, how many duplicate chunks you would end up with if you were to split them into 128x128 chunks.
Yeah, I can understand your points about chunk mapping size, and the lack of precision of the 256x256 chunks. I'd have to rely on sprites to optimize some of my chunks. I have these underground sections in that really large level I released a while ago that would generate TONS of duplicate (or very similar) chunks, kind of in a similar manner to 128 MZ, which does have plenty of duplicates from the get go. Ironically, 128 MZ is one of the levels I can say can easily take advantage of the smaller chunk structure, though I'm still not quite sure if zones like 128 GHZ or 128 SYZ would benefit from such a change. You mention memory usage, which made me curious. I wonder if the same benefits can be applied to larger scales. Using uncompressed S2 format for both levels (as used in Large Levels Tech Demo), a level that is $8000x$2000 pixels in size (without optimizations) would occupy 8KB in 256, and 32KB in 128. 256 uncompressed chunk mappings, as stated earlier, are 32KB in 128, and... 128KB in 256. Yes, I can clearly see the technical advantage. I would need to quadruple the level size again for the space advantage to be nullified entirely, and for the average Sonic level, it's just not worth the hassle.
256x256, they're fun sized! =P On a more serious note though, I think 256x256 feels less cramped. I have no idea why, but I feel like I can do more with it for some reason.
I got experience with 256x, I suck with 128x But well, Never its late to learn how to make good levels with that type of chunks ¯\_(ツ)_/¯
I haven't done serious level designing with 128s in a while, but I've generally come to prefer 256s since I've been working with just Sonic 1 for almost 2 years now They do have some annoying disadvantages, like not being as malleable as I'd like in certain scenarios and requiring multiple duplicate chunks to achieve what you could do with less 128s, but I find them easier to fill in levels with rather than 128s (maybe that's because sonic 1 has some fairly malleable 256s? Most of CD's 256s by comparison absolutely suck to make new levels, with the exception tidal tempest which for some reason has great chunks). Most of the time I find that Sonic 1's chunk limit of $52 is just fine for my level design needs, but since my future zone ideas require custom chunks I might want to look into attempting the ROM chunks and $FF chunks guides (I believe I've tried $FF chunks and it didn't pan out but I'm not entirely sure).
While I have not used it yet, I would say 128x128 chunks would be my bet. Personally, it pretty much is a set standard for Sonic level design since Sonic 2, an I would bet some good-looking and well made levels have been made with 128x128 chunks. I have never dealt with level design before, but 128x128 would be my ideal level chunks for level design (if I ever get around to it). 256x256 chunks are nice, however they are incompatible with Sonic 2 and its sequels, due to the way the chunks are formatted and laid out.
I tend to prefer 128, but both have there advantages 128... - takes up less space, and fits in RAM better (takes up $8000 max, which pads the rest of RAM exactly to the point of word-based uses. 256 exceeds that) - provides better methods for pathswapping (used for loops and alternate paths) - is better at dealing with small edges 256... - can fit a full loop, whereas 128 needs 4 chunks - takes up less space for layout data, being better for a game with longer stages (ironic) - is easier to work with if you're designing the stage in an editor and don't have a planned out level beforehand Both of them have top solid and side solid blocks, so either is good
