With some basic Googling It looks like that the max size was around 512 KB. How is this even possible to fit games of this size onto such little memory? What is this magic?
In: Technology
**Turn back, this way lies madness.**
It is all highly optimized code using weird tricks on top of tricks on top of tricks. The kinds of things where one engineer explaining to another might take an hour to show how 5 lines of code does anything, let alone what the first engineer is claiming they are doing with it.
Old games are like storing a brick and the plan of the house, then tell the processor to copy the brick according to the plan to build the house. Most of the size gain is because the graphics are done using repeating patterns and only storing a little square and telling the processor to repeat it.
Modern games are like storing the whole house and its 500 000 bricks. Often even the parts of the bricks you never see because they don’t care about size anymore.
The game is a grid. Legend of Zelda is 16 screens wide by 8 screens tall. And each screen is a grid of 11×16 tiles. Now let’s say there are 16 different types of tiles, then you only need 4 bits of information for each tile, which means the entire overworld of zelda is only 11kb.
But 11kb is a lot in the 1980’s. They probably used a lot of tricks to make it less than that. How about instead of 16 different types of tyles, each screen only has 4 types of tiles (and those 4 can be different for different screens, so one screen might be sand, rock, water and cave, but another screen might be sand, grave stone, bush, and tree). Now you only need 2 bits for each tile, so your file size is 5.5kb.
And maybe you come up with some other shortcuts… like on a desert screen you make “sand” the default tile and now you only have to store the data for the rocks on the top of the screen.
Look up a picture of the first Zelda. The screen is made of little pictures (tiles) on a grid. How big is the grid? I count 17 by 11 tiles. So that’s 187 bytes for a screen. How big is the world? If you look up a map, it’s 16 by 8 screens. Maybe triple that because of all the dungeons and stuff. So that makes 384 screens which are 187 bytes each, which is 71808 bytes. Still plenty of bytes left.
[removed]
A lot of reused assets. If you look at the dungeons in the game they all look the same, but just rearranged and maybe with different colors. The different colors aren’t even separate files, they are changed programmatically.
For that matter there’s other tricks like using black space. The areas that are black in the game are actually just the absence of any assets being loaded.
For both Zelda and Final Fantasy they even reused sprites for enemies. So you could have a variety of enemies that just have maybe the color changed about them to differentiate them.
[removed]
All graphical information was stored in 16KiB of memory. This area of memory was divided into sections.
The first was a pattern table. The table was 8KiB in size and divided into 8×8 tiles. The table was usually split vertically, half for backgrounds, half for sprites. A pixel was stored in 4 bits, meaning the NES could display 16 colors. The pattern table only stored the lower 2 bits of each pixel. The other two bits were looked up in one of the other two tables.
The next table was the “name table”, of which there were typically 2 but up to 4. A name table is 960 bytes. This corresponds to a 32×30 grid of 8×8 tiles from the pattern table. The top and bottom 8 scanlines weren’t rendered on a CRT television, so that memory could be used to hold game data. You can see the effect along the top and bottom edges of Tecmo Super Bowl.
A name table has an attribute table 64 bytes in size that maps the upper two bits of every pixel to the lower two bits in the pattern table.
There was also a sprite table, or sprite RAM, that used 4 bytes to map the x and y location, upper color bits, the tile index (meaning the x and y location is relative to a given tile in the background), horizontal or vertical flip, and foreground/background. This table was 256 bytes so there could be 64 sprites on the screen at any given time.
There were two color pallets of 16 colors each, and the color bytes split between the pattern table and the name or sprite tables indexed into these pallets. One was for the background, the other for the sprites. These two 16 color pallets mapped into a 256 color pallet built into the hardware.
If you don’t understand all that, don’t fret. The whole thing works out like a relational database, where one table maps into another. The data is down to packed bits, so while you have addressable bytes, you had to mask and pick out bits and combine them in registers to get complete values out. The hardware was built around all of this and could do it for you, which is how the system was fast enough to actually render this much data onto a CRT. A cartridge was ROM that basically plugged into this memory space, so the data was already laid out and good to go, the video hardware mapped right onto the cartridge data.
Short version: *insanely* talented coders doing everything they could to maximize space. I’m gonna blow your mind right now. Take a look at the [intro to SMB1.](https://cdn02.nintendo-europe.com/media/images/10_share_images/games_15/virtual_console_nintendo_3ds_7/SI_3DSVC_SuperMarioBros.jpg) We’ll ignore for a moment the fact that that screenshot takes up more memory than the entire game did.
Anyway, take a real hard look at it. Check out everything – the bricks, Mario, the Goomba, the hill, the clouds, the bushes… the clouds, the bushes… *the clouds, the bushes*…
Yeah. They’re the same icon, just with a new color palette swapped in. All sorts of little tricks like that in old-school programming.
And it’s not totally dead either! There’s still a (mostly European) subculture devoted to slick programming, called the [Demoscene](https://en.wikipedia.org/wiki/Demoscene). I’m gonna date myself here, but when I was a College Freshman I was introduced to a Demo called “[The Product](http://theproduct.de/)” – it’s a several minute long music video, all 3d generated graphics, made in under **64Kb**. I just downloaded it and checked – still runs on my fully updated Windows 10 machine, but I know for a while there it wasn’t playing nice with new computers so YMMV.
So coders are still out there that are capable of doing, frankly, ridiculous shit like that (even though that’s nearly 20 years old at this point, it’s still ongoing) — just they don’t *have* to anymore because it’s assumed most people will have reasonable stats on their computer. If everyone has 16 gigs of ram, who cares if you lose a couple kilobytes? Guys who are programming for efficiency, that’s who.
[removed]
Latest Answers