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
One of the issue is that modern pictures formats assume that you can have every available color in every single pixel on the screen and that any pattern of pixels is possible to be in that picture.
The NES could theoretically display up to 56 colors, but it couldn’t display each color everywhere instead a pallette of 13 colors had to be chosen for each tile of 16 by 16 pixels.
You can create some beautiful graphics despite those limitations if you select the boundaries where the palette changes carefully.
You could also have some nice effects by changing pallets to create illusion of motion.
The tiles themselves were also not all drawn but puzzled together from a small library. So you might have had three different types of background rocks in a cave that became background clouds or bushes outside by drawing the same picture with a pallette of white and blue or green instead of brown.
So really you only needed to say which of the tiles from your library went where and what pallette they were using to draw the background instead of each individual pixel.
To draw a picture that was 256×240 pixels you really only had a matrix of 32 by 30 tiles and that you assigned form a small library of 256 background tiles. and you also had a grid 16 by 15 areas that you assigned one of your four pallets each.
This allowed you to tell the computer what to draw for the background with a tiny minimum of instructions compared to telling it how to draw the background pixel by pixel with each pixel being bale to be one of hundred of thousands of colors.
You still needed a bit of extra space to describe all the possible background tiles and the pallettes but those were fixed costs that wouldn’t get any bigger if you made the level bigger.
The moving parts, sprites, like Mario and the enemies he jumped on were similar except that you could only use a very small numbers of colors. This limitation influenced the design of many iconic charters that date this far back.
Overall it was all designed to use the tiny amount of available space as efficiently as possible.
Modern graphics formats try to use space efficiently too but not anywhere to that degree.
One of the issue is that modern pictures formats assume that you can have every available color in every single pixel on the screen and that any pattern of pixels is possible to be in that picture.
The NES could theoretically display up to 56 colors, but it couldn’t display each color everywhere instead a pallette of 13 colors had to be chosen for each tile of 16 by 16 pixels.
You can create some beautiful graphics despite those limitations if you select the boundaries where the palette changes carefully.
You could also have some nice effects by changing pallets to create illusion of motion.
The tiles themselves were also not all drawn but puzzled together from a small library. So you might have had three different types of background rocks in a cave that became background clouds or bushes outside by drawing the same picture with a pallette of white and blue or green instead of brown.
So really you only needed to say which of the tiles from your library went where and what pallette they were using to draw the background instead of each individual pixel.
To draw a picture that was 256×240 pixels you really only had a matrix of 32 by 30 tiles and that you assigned form a small library of 256 background tiles. and you also had a grid 16 by 15 areas that you assigned one of your four pallets each.
This allowed you to tell the computer what to draw for the background with a tiny minimum of instructions compared to telling it how to draw the background pixel by pixel with each pixel being bale to be one of hundred of thousands of colors.
You still needed a bit of extra space to describe all the possible background tiles and the pallettes but those were fixed costs that wouldn’t get any bigger if you made the level bigger.
The moving parts, sprites, like Mario and the enemies he jumped on were similar except that you could only use a very small numbers of colors. This limitation influenced the design of many iconic charters that date this far back.
Overall it was all designed to use the tiny amount of available space as efficiently as possible.
Modern graphics formats try to use space efficiently too but not anywhere to that degree.
The game and the JPEG take very different methods to produce an image on the screen, because they’re trying to accomplish different tasks. They’re both trying to do what they do as efficiently as possible, but they’re not trying to do the same thing.
The JPEG format is trying to reproduce photographs with as small a file size as possible, but while still making them close enough to the original that a human wouldn’t easily notice flaws. There are many ways that this is accomplished, and there are many different types of images that can be stored as JPEG, so the format has to be flexible and so it’s not always perfectly efficient. Quite notably images of old video games, with large areas of flat color, is one of the types that JPEG is worst at efficiently storing. Not only that, but the creation of a JPEG is almost always a completely automated process. It’s not something that gets hand optimized for the specific image being stored.
A NES game is not trying to recreate the real world, and the code for Super Mario Bros doesn’t have to be flexible. The code is written to work on very specific hardware, and do a relatively specific task. Other commenters have shared some of the tricks used to do this, and it’s a remarkable feat, but it took a lot of human effort to reduce that file size down.
A NES game is a recipe for a cake. The JPEG is a blog post trying to describe the resulting cake.
The game and the JPEG take very different methods to produce an image on the screen, because they’re trying to accomplish different tasks. They’re both trying to do what they do as efficiently as possible, but they’re not trying to do the same thing.
The JPEG format is trying to reproduce photographs with as small a file size as possible, but while still making them close enough to the original that a human wouldn’t easily notice flaws. There are many ways that this is accomplished, and there are many different types of images that can be stored as JPEG, so the format has to be flexible and so it’s not always perfectly efficient. Quite notably images of old video games, with large areas of flat color, is one of the types that JPEG is worst at efficiently storing. Not only that, but the creation of a JPEG is almost always a completely automated process. It’s not something that gets hand optimized for the specific image being stored.
A NES game is not trying to recreate the real world, and the code for Super Mario Bros doesn’t have to be flexible. The code is written to work on very specific hardware, and do a relatively specific task. Other commenters have shared some of the tricks used to do this, and it’s a remarkable feat, but it took a lot of human effort to reduce that file size down.
A NES game is a recipe for a cake. The JPEG is a blog post trying to describe the resulting cake.
The game and the JPEG take very different methods to produce an image on the screen, because they’re trying to accomplish different tasks. They’re both trying to do what they do as efficiently as possible, but they’re not trying to do the same thing.
The JPEG format is trying to reproduce photographs with as small a file size as possible, but while still making them close enough to the original that a human wouldn’t easily notice flaws. There are many ways that this is accomplished, and there are many different types of images that can be stored as JPEG, so the format has to be flexible and so it’s not always perfectly efficient. Quite notably images of old video games, with large areas of flat color, is one of the types that JPEG is worst at efficiently storing. Not only that, but the creation of a JPEG is almost always a completely automated process. It’s not something that gets hand optimized for the specific image being stored.
A NES game is not trying to recreate the real world, and the code for Super Mario Bros doesn’t have to be flexible. The code is written to work on very specific hardware, and do a relatively specific task. Other commenters have shared some of the tricks used to do this, and it’s a remarkable feat, but it took a lot of human effort to reduce that file size down.
A NES game is a recipe for a cake. The JPEG is a blog post trying to describe the resulting cake.
The video chip that rendered the images on screen was pretty weak, so to make it more efficient, they used a quick screen tiling mode, were you repeat indexed tiles on the screen, each tile being encoded in a efficient 2 bits per pixel, and the color also using indexing in a 4 color pallette shared by 4 tiles. This ensured a small sized image and game as a whole, but made it pretty difficult to draw anything complex. Modern hardware is more powerful and can render pretty complex images with no regards to size, so new image encoding schemes will create bigger images but they can also recreate complex and realistic images, what the NES could not. Also, modern computers don’t understand the NES encoding scheme, ao if you try to make a code to “translate” it, let’s say in python, the code is gonna also have a couple of kilobytes. It goes to show that the size of the game and the image is a result of the limitations of the era.
The video chip that rendered the images on screen was pretty weak, so to make it more efficient, they used a quick screen tiling mode, were you repeat indexed tiles on the screen, each tile being encoded in a efficient 2 bits per pixel, and the color also using indexing in a 4 color pallette shared by 4 tiles. This ensured a small sized image and game as a whole, but made it pretty difficult to draw anything complex. Modern hardware is more powerful and can render pretty complex images with no regards to size, so new image encoding schemes will create bigger images but they can also recreate complex and realistic images, what the NES could not. Also, modern computers don’t understand the NES encoding scheme, ao if you try to make a code to “translate” it, let’s say in python, the code is gonna also have a couple of kilobytes. It goes to show that the size of the game and the image is a result of the limitations of the era.
The video chip that rendered the images on screen was pretty weak, so to make it more efficient, they used a quick screen tiling mode, were you repeat indexed tiles on the screen, each tile being encoded in a efficient 2 bits per pixel, and the color also using indexing in a 4 color pallette shared by 4 tiles. This ensured a small sized image and game as a whole, but made it pretty difficult to draw anything complex. Modern hardware is more powerful and can render pretty complex images with no regards to size, so new image encoding schemes will create bigger images but they can also recreate complex and realistic images, what the NES could not. Also, modern computers don’t understand the NES encoding scheme, ao if you try to make a code to “translate” it, let’s say in python, the code is gonna also have a couple of kilobytes. It goes to show that the size of the game and the image is a result of the limitations of the era.
In addition to what’s already been said, a JPEG is good for things like photos where there’s a lot of different colors. For something with a small fixed color palette like old school pixel art, a PNG would be much more efficient. Especially if it’s exported with a limited color space to what was available for the NES.
In addition to what’s already been said, a JPEG is good for things like photos where there’s a lot of different colors. For something with a small fixed color palette like old school pixel art, a PNG would be much more efficient. Especially if it’s exported with a limited color space to what was available for the NES.
Latest Answers