I’ve seen the meme/info-graphic that the original file for Mario Bros. was approx. 32kb, but a picture file would be 10x more.
I’ve googled it and looked, but it seems to have some nebulous answers. Could someone please ELI5?
In: 26
As an example, the clouds in the sky and the bushes on the ground are the exact same image, except one was white and one was green. Neither one of them needs to look photorealistic. Mario is scarcely more than a stick figure and only has very few poses. Computer storage space and processing ability were both expensive commodities when that game was released, and to make a playable/ enjoyable game a lot of graphics quality had to be sacrificed. Programmers spent a *lot*of time trying to eke just a little bit more performance out of the computer because every little scrap mattered.
A JPEG, on the other hand, Is a technology from almost a decade later when processor power and memory had advanced quite a bit. A JPEG is designed to look photo realistic – it is designed to store information that makes up a picture in a way that natural images look OK to humans while not using a relatively huge amount of storage space either. The trade-off, though, is you are trading a much better quality of graphic for more storage space and a heavier load for the processor to lift to display the file.
Aside from all the comparisons of file sizes, a video game’s code and an image aren’t even close to the same thing.
When you play a level of Mario, all the data file has is an identifier of what tile is in what position on the level. So it will load the little 12×12 sprite for a brick, and just draw that over and over on the screen hundreds of times.
When you go to a different level, it loads the exact same brick image, and then palette swaps it – the image itself may just be a handful of bits, not even a full byte, which tell it which color in the palette is drawn. It doesn’t have any actual color data of its own, which is why you can have levels with red bricks, blue bricks, grey bricks, green bricks, etc. Same with the clouds and the bushes; same sprite, but the bush would be placed in the background halfway below the brick and colored from the green palette.
Consoles were optimized to render things this way, because shaders didn’t exist yet and because they didn’t really have a lot of memory. So there were lots of optimizations, tricks and reuse of assets to work with what was available.
A JPEG on the other hand is a full-sized image of the entire level (not just what’s on screen as you actually play the game), and it saves 32-bit color data of every single pixel. So those thousands of bricks? The data might be repeating from brick to brick, but it’s still saving all of the data of every single pixel of every single brick.
To put it another way, think of the game’s code as letters of the alphabet. You can construct ANYTHING out of them, but there are only 26 of them. The JPEG is an encyclopedia.
Aside from all the comparisons of file sizes, a video game’s code and an image aren’t even close to the same thing.
When you play a level of Mario, all the data file has is an identifier of what tile is in what position on the level. So it will load the little 12×12 sprite for a brick, and just draw that over and over on the screen hundreds of times.
When you go to a different level, it loads the exact same brick image, and then palette swaps it – the image itself may just be a handful of bits, not even a full byte, which tell it which color in the palette is drawn. It doesn’t have any actual color data of its own, which is why you can have levels with red bricks, blue bricks, grey bricks, green bricks, etc. Same with the clouds and the bushes; same sprite, but the bush would be placed in the background halfway below the brick and colored from the green palette.
Consoles were optimized to render things this way, because shaders didn’t exist yet and because they didn’t really have a lot of memory. So there were lots of optimizations, tricks and reuse of assets to work with what was available.
A JPEG on the other hand is a full-sized image of the entire level (not just what’s on screen as you actually play the game), and it saves 32-bit color data of every single pixel. So those thousands of bricks? The data might be repeating from brick to brick, but it’s still saving all of the data of every single pixel of every single brick.
To put it another way, think of the game’s code as letters of the alphabet. You can construct ANYTHING out of them, but there are only 26 of them. The JPEG is an encyclopedia.
Aside from all the comparisons of file sizes, a video game’s code and an image aren’t even close to the same thing.
When you play a level of Mario, all the data file has is an identifier of what tile is in what position on the level. So it will load the little 12×12 sprite for a brick, and just draw that over and over on the screen hundreds of times.
When you go to a different level, it loads the exact same brick image, and then palette swaps it – the image itself may just be a handful of bits, not even a full byte, which tell it which color in the palette is drawn. It doesn’t have any actual color data of its own, which is why you can have levels with red bricks, blue bricks, grey bricks, green bricks, etc. Same with the clouds and the bushes; same sprite, but the bush would be placed in the background halfway below the brick and colored from the green palette.
Consoles were optimized to render things this way, because shaders didn’t exist yet and because they didn’t really have a lot of memory. So there were lots of optimizations, tricks and reuse of assets to work with what was available.
A JPEG on the other hand is a full-sized image of the entire level (not just what’s on screen as you actually play the game), and it saves 32-bit color data of every single pixel. So those thousands of bricks? The data might be repeating from brick to brick, but it’s still saving all of the data of every single pixel of every single brick.
To put it another way, think of the game’s code as letters of the alphabet. You can construct ANYTHING out of them, but there are only 26 of them. The JPEG is an encyclopedia.
You know all those bushes and clouds you see in the game while you’re playing it?
They only need ONE bush and ONE cloud in the game’s code, and they can re-use the same asset repeatedly to generate the frame on screen. Repeat for all the frames that need to be drawn.
But if you take a screenshot, that image will record ALL the bushes and clouds that happen to be on screen at the time separately, because it’s basically a grid of pixels as tall and as wide as the whole screen.
Now, are you ready to *really* blow your mind? The bush and the cloud are actually [the same asset](https://www.reddit.com/r/gaming/comments/8ij644/the_bushes_and_clouds_in_super_mario_bros_are_the/), just painted different colours at render time.
Repeat such tricks and a few others, and that’s how you fit a whole game in 32 KB.
You know all those bushes and clouds you see in the game while you’re playing it?
They only need ONE bush and ONE cloud in the game’s code, and they can re-use the same asset repeatedly to generate the frame on screen. Repeat for all the frames that need to be drawn.
But if you take a screenshot, that image will record ALL the bushes and clouds that happen to be on screen at the time separately, because it’s basically a grid of pixels as tall and as wide as the whole screen.
Now, are you ready to *really* blow your mind? The bush and the cloud are actually [the same asset](https://www.reddit.com/r/gaming/comments/8ij644/the_bushes_and_clouds_in_super_mario_bros_are_the/), just painted different colours at render time.
Repeat such tricks and a few others, and that’s how you fit a whole game in 32 KB.
You know all those bushes and clouds you see in the game while you’re playing it?
They only need ONE bush and ONE cloud in the game’s code, and they can re-use the same asset repeatedly to generate the frame on screen. Repeat for all the frames that need to be drawn.
But if you take a screenshot, that image will record ALL the bushes and clouds that happen to be on screen at the time separately, because it’s basically a grid of pixels as tall and as wide as the whole screen.
Now, are you ready to *really* blow your mind? The bush and the cloud are actually [the same asset](https://www.reddit.com/r/gaming/comments/8ij644/the_bushes_and_clouds_in_super_mario_bros_are_the/), just painted different colours at render time.
Repeat such tricks and a few others, and that’s how you fit a whole game in 32 KB.
If you had an image file of the same resolution of the original game it would be of a similar size. Jpeg isn’t the format you’d want to use, the overhead is greater than the pixel days (around 50000 total pixels, with just a couple of bits per pixel for color)
The default for current images would be a minimum of 8 bits per pixel per color (RGB)
50000 pixels at 8bit color depth would be 1.2Mb (150kB)
If you had an image file of the same resolution of the original game it would be of a similar size. Jpeg isn’t the format you’d want to use, the overhead is greater than the pixel days (around 50000 total pixels, with just a couple of bits per pixel for color)
The default for current images would be a minimum of 8 bits per pixel per color (RGB)
50000 pixels at 8bit color depth would be 1.2Mb (150kB)
If you had an image file of the same resolution of the original game it would be of a similar size. Jpeg isn’t the format you’d want to use, the overhead is greater than the pixel days (around 50000 total pixels, with just a couple of bits per pixel for color)
The default for current images would be a minimum of 8 bits per pixel per color (RGB)
50000 pixels at 8bit color depth would be 1.2Mb (150kB)
Latest Answers