The Lenny said:
I guess my second question would be:
1. Tower of Turmoil was an amazing piece of work but not an extremely lengthy game, so if it took nearly 50%...how did Nintendo make games that were WAY longer (Mario Brothers for example) and still fit it one cartridge?
Super Mario Bros. used an "object based" format. That's how its levels are so small.
Really basic example:
There's a simple Super Mario Bros. scene. (Edited to keep the explanation simple.) Most NES games break things down into a concept of 16x16 "metatiles" (that are made of four 8x8 tiles, as dictated by the hardware). The screen is 256x240. 256/16=16, so the screen is sixteen 16x16 tiles across. 240/16=15, so the screen is fifteen 16x16 tiles down.
So if you wanted to store the metatile number of each 16x16 metatile in a screen, that's 16*15=240 bytes. (The 16x16 metatile definitions also take up space, but it's negligible relative to screen data, usually.)
240 bytes is not
a lot, but if you have a lot of screens, it really adds up. Super Mario Bros. has just 32KB available for all its code/non graphical data. 32*1024=32768 bytes. 32768/240=136.533333333. So using this format, the Super Mario Bros. cartridge could only store 136 unique screens and basically nothing else. (No physics, no music, etc.)
So there's a simple technique that stores the tile number for the metatile, and then how many times the tile appears in a row. Here's how that would shake out for the above scene:
The blue sky takes up most of the screen. It fills 10 entire rows, and 13 metatiles of the next row. So suppose the blue sky's metatile number was 0. To store it for this screen, you'd store 0 (one byte, the metatile number), 10*16+13 (one byte, how many times in a row it appears.).
Then the left side of the pipe interrupts the blue sky. It only appears once in a row. Say 1 is the metatile number for the left side of the pipe. To store it for this screen, you'd store 1 (tile number), 1(how many times).
The left side of the pipe is immediately interrupted by the right side of the pipe. Say the right side of the pipe is 2. It'd be stored as 2, 1.
The right side of the pipe is immediately interrupted by more blue sky. 0, 4.
The blue sky is interrupted after a short run by more pipe. 1, 1. Right side of pipe. 2, 1. Sky. 0, 8. We've hit another left side of a pipe, but it's a different metatile. Say 3. 3, 1. Right side of pipe middle, new metatile. 4, 1. Sky. 0, 4. Left pipe middle. 3, 1. Right pipe middle. 4, 1. Sky. 0, 8. Left Pipe Middle. 3, 1. Right Pipe Middle. 4, 1. Sky. 0, 1. Ground, new metatile. 5, 32.
Basically, this method takes two bytes every time the metatile number needs to change. The above screen would take 34 bytes. A screen that was only sky and ground, would only take 4 bytes. This method (number, then repeats) is called "Run Length Encoding". It is soundly defeated by a checkerboard pattern. Imagine a scene where the metatile change happens almost every tile:
0, 1. 1, 1. 0, 1. 1. 1. It's taking two bytes when the simpler method would only take one. There's a way to avoid this if you use fewer than 129 metatiles, but the point is: No one method will win in all cases. If you use Run Length Encoding, you avoid checkerboard patterns. If you need checkboard patterns, you use a different method than Run Length Encoding.
Still, 34 bytes instead of 240 sounds really good, right? But Super Mario Bros. goes even further. You may notice that after every left side of a pipe (top) is the right side of a pipe (top). 1, 1. 2, 1. And you may notice that after every left side of a pipe (middle) is the right side of a pipe (middle) 3, 1. 4, 1.
You may further notice that under every left side of a pipe (top) is left side of a pipe (middle). So Super Mario Bros. stores how to build a pipe. "A pipe is a thing that has metatile 1 in the top left, metatile 2 in the top right, and metatiles 3 and 4 below for however tall it is." So the pipe is defined as an "object."
And then Super Mario Bros. stores where the pipe is on screen (one byte), and how long it is (one byte). It also assumes the ground is 100% solid and at the same height for each screen.
There are two pipes in the above scene. 173 (metatile position within the screen where the first pipe starts) (one byte), 2 (height of the first pipe) (one byte). 179 (position of the second pipe), 1 (height).
The ground is assumed to be there. (Holes take up space, not the ground.) The sky is also assumed to be there. So the four bytes for those two pipes is the only data that's required.
4 bytes for this scene beats 34. 4 bytes for this scene soundly beats 240.
A screen that is only ground and only sky would take up no space, in theory, since they are assumed to be there and nothing needs to be added to them.
So for those keeping score, Super Mario Bros. had 32768 bytes for code/non graphical data. The average screen has more objects than two pipes. Say the average screen has six objects at two bytes per object. 12 bytes per screen.
32768/12=2730.666666667. It could fit 2730 unique screens. But it doesn't need that many. And that's how it has space for code/music/the other thing it needs.
(To kill the pedants, no, this isn't EXACTLY how Super Mario Bros. does things, but it's a similar concept.) (Edit: Well, an extra byte would need to be stored somewhere per screen. Either a length of how many bytes in the screen's stream, or just an object number that signifies the end of the object based stream. But still, you get the picture.)
So back to Earth. Back to NES Maker. Why doesn't NES Maker use a format like Super Mario Bros.? It'd have to allow the user to teach it how to build all the things. It'd be like everything was a path, that you had to define. It's also harder to write code to draw it.
Super Mario Bros. format makes assumptions based on the type of game it is. (2 metatiles tall ground for every screen unless objects say otherwise.)
NES Maker is trying to cover all types of games. Much like how the checkerboard pattern defeats Run Length Encoding, there are things that defeat the object based format.
Anyway, there ARE definitely ways NES Maker could manage space differently (better?) even if it's not how Super Mario Bros. does things, but I imagine it's not high priority. No one has really even maxed what's there.