12 ms·

Where do all the bytes come from?

90 points by EddieRingle 11y ago

fbbbbb 11y ago
I was mildly surprised when John Carmack retweeted the original tweet. https://twitter.com/smashingmag/status/675624576630571009 https://twitter.com/smashingmag/status/675624576630571009 The state of the image (jpeg artifacts), was a dead giveaway that the comparison is worthless.
- pavel_lishin 11y ago
  > a dead giveaway that the comparison is worthless. Worthless to anyone who understand both how the NES and JPEGs work, but pretty worthwhile to someone who's just learning about it.
  - codyb 11y ago
    Yea, and the reference links were interesting too. The LZSS youtube video was an enjoyable watch.
- venning 11y ago
  To be fair, the original tweet references "website weight" which is dependent on generic image formats, as the author here addresses. Being limited to generic image formats does add a lot of weight to sites, but also means all browsers can view them.
larrik 11y ago
I don't know, it's a bit like taking a screenshot of a text file, and wondering why the screenshot is 64k and the text file is only 500 bytes (or whatever).
- joezydeco 11y ago
  That's a much better analogy. I was expecting more of a realistic explanation about how the NES puts up the frame without a frame buffer. This falls into a mess about graphics compression, which is kind of irrelevant.
  - corysama 11y ago
    You would like this: "How 'oldschool' graphics worked Part 1 - Commodore and Nintendo" https://www.youtube.com/watch?v=Tfh0ytz8S0k https://www.youtube.com/watch?v=Tfh0ytz8S0k
    - joezydeco 11y ago
      I prefer Montfort and Bogost's Racing the Beam from MIT Press: https://mitpress.mit.edu/books/racing-beam https://mitpress.mit.edu/books/racing-beam
- kozukumi 11y ago
  Indeed. I also didn't much like the comparison to the .kkrieger demo saying it was "only" 24KB more. Sure the raw exe is but it still needs GB of memory and a crazy fast CPU to do all the content generation at runtime. He also used inconsistent mb/MB, etc. which always gets on my nerves in a technical post but now I am just being an asshole at it is 2am here ;)
joosters 11y ago
Minor nitpick, but it screws up all the calculations: The original NES console was only designed to output images that were 256 wide by 240 high; meaning that the final image that needed to be displayed to the screen was 180kb in size. The NES definitely didn't have 24-bit colour, so the final image data was at most 60kb, assuming 256 colours, or 30kb assuming 16 colours and a palette. I don't know for sure what colour settings the NES had, I doubt it had a freely selectable 256 colours for each pixel. Probably a limited palette, maybe per-sprite, maybe for the whole screen.
- mhurron 11y ago
  > I don't know for sure what colour settings the NES had, I doubt it had a freely selectable 256 colours for each pixel. Probably a limited palette, maybe per-sprite, maybe for the whole screen. http://www.thealmightyguru.com/Games/Hacking/Wiki/index.php?title=NES_Palette http://www.thealmightyguru.com/Games/Hacking/Wiki/index.php?... "a total of 64 pre-set colors (56 of which are unique), and you can only show 25 on the screen at one time (under normal circumstances)." So ya, a little more limited than 24-bit colour.
- wlesieutre 11y ago
  Wikipedia to the rescue: https://en.wikipedia.org/wiki/List_of_video_game_console_palettes#Famicom.2FNES https://en.wikipedia.org/wiki/List_of_video_game_console_pal... - 4 palettes for sprites at a time, each containing transparent + 3 colors. So 12 sprite colors. - 4 more palettes for background (applied to 16x16 areas), each sharing their first color, for another 13 colors in the background. - Total up to 25 colors on screen simultaneously, selected from a 64 color palette that really had 54 useful colors.
mindslight 11y ago
I don't see why it's an "unfair" comparison. You just need to think of it in the right context. At the time Super Mario was popular, storing a still raster image took a lot of hardware. Generating an interactive picture on a TV was easy enough on consumer hardware, but simply recording a picture was not! Today we take the concept for granted, eg digital cameras.
DiThi 11y ago
- The tiles have many repeated images while in the original they could flip them and change the color palette. Note that the bushes and the cloud share sprites. - .kkrieger wasn't 64 kb, it's 96 kb. Still impressive though. - The image in the tweet is 51.4 kb. I was expecting some explanation about how the sprites are so tiny because they use a palette of 4 colors (and 4 pixels fit in one single byte), then the colors themselves are stored separately.
- lost_name 11y ago
  I feel like this is pretty important since the article is talking about the comparison in the first place. Here's a couple blog posts on the subject, which I think explain it better. http://www.dustmop.io/blog/2015/04/28/nes-graphics-part-1/ http://www.dustmop.io/blog/2015/04/28/nes-graphics-part-1/ http://www.dustmop.io/blog/2015/06/08/nes-graphics-part-2/ http://www.dustmop.io/blog/2015/06/08/nes-graphics-part-2/
deleted 11y ago
[deleted]
tribune 11y ago
Reminds me of a sarcastic response from my classmate back in my undergrad Signals class... the professor showed us a sample black-and-white photo and asked (rather rhetorically) how we would represent it using as few bits as possible. Classmate said he would build a machine that only displays that image, and give it an On/Off switch - a whole image with only 1 Bit!
- TeMPOraL 11y ago
  And this is the crucial insight. An image, or a game, does not contain all its data in those bytes you have stored in its file. A lot of information is spread around in the environment. It's one of the main ways demo-makers can cram so much content into so little space - they pull as much stuff from the environment as it's possible (and allowed by contest rules). To give an example: one of the most basic tricks, if you're allowed to use OpenGL and WinAPI, is to use WGL to render your system fonts into 3D shapes[0]. This allows you to get a lot of 3D models from just the few bytes it takes to call wglUseFontOutlines()[1]. You may think that there isn't anything interesting in a basic font, but - even forgetting about Unicode - every Windows has Wingdings... (Or look into the good old .EMF[2] format, which was basically direct encoding of Windows GDI calls.) For much more in-depth discussion on where exactly information is stored, be sure to read GEB[3], if you haven't already. [0] - https://www.youtube.com/watch?v=iri5CgLglkk https://www.youtube.com/watch?v=iri5CgLglkk - 1/10th size of Mario! [1] - https://msdn.microsoft.com/en-us/library/windows/desktop/dd374393%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/dd3... [2] - https://en.wikipedia.org/wiki/Windows_Metafile https://en.wikipedia.org/wiki/Windows_Metafile [3] - https://en.wikipedia.org/wiki/G%C3%B6del,_Escher,_Bach https://en.wikipedia.org/wiki/G%C3%B6del,_Escher,_Bach
  - pavel_lishin 11y ago
    > And this is the crucial insight. An image, or a game, does not contain all its data in those bytes you have stored in its file. A lot of information is spread around in the environment. This is also an argument I've heard about growing people new bodies to transfer into (like Old Man's War) or digitizing humans (like the Singularity); apparently, a sample of DNA isn't enough to create a whole new person. You need, at least, a womb.
Gravityloss 11y ago
A large portion of the data is noise nowadays. Cell phone camera pixels are so small that they capture very little signal, yet everything is saved at full resolution. It's digital pollution.
jjaredsimpson 11y ago
kolmogorov complexity and mutual information are the things that explain the difference. The super mario rom is a very compact description of the super mario game, in the context of its environment. The jpeg environment isn't very well designed as an environment to display a single frame from a flat colored video game.
venning 11y ago
If you're interested in this stuff, the author also hosts the excellent Compressor Head video series: https://www.youtube.com/playlist?list=PLOU2XLYxmsIJGErt5rrCqaSGTMyyqNt2H https://www.youtube.com/playlist?list=PLOU2XLYxmsIJGErt5rrCq...
- deleted 11y ago
  [deleted]
- deleted 11y ago
  [deleted]
- deleted 11y ago
  [deleted]
- deleted 11y ago
  [deleted]
faint_coder 11y ago
really? this stupid question on Hacker News? O_O of course the bytes surplus derives from the fact that the image is a raster bitmap, while the game program DRAWS the bitmap, just like the difference between rasterizers and vector graphics. Its like having 1kb monolithic kernel which prints "Hello World" and then goes in while(1); forever, and snapshotting the entire screen and saving it in a .png file..

90 points by EddieRingle 11y ago

I was mildly surprised when John Carmack retweeted the original tweet. https://twitter.com/smashingmag/status/675624576630571009 https://twitter.com/smashingmag/status/675624576630571009 The state of the image (jpeg artifacts), was a dead giveaway that the comparison is worthless.

pavel_lishin 11y ago
> a dead giveaway that the comparison is worthless. Worthless to anyone who understand both how the NES and JPEGs work, but pretty worthwhile to someone who's just learning about it.
- codyb 11y ago
  Yea, and the reference links were interesting too. The LZSS youtube video was an enjoyable watch.
venning 11y ago
To be fair, the original tweet references "website weight" which is dependent on generic image formats, as the author here addresses. Being limited to generic image formats does add a lot of weight to sites, but also means all browsers can view them.

larrik 11y ago

I don't know, it's a bit like taking a screenshot of a text file, and wondering why the screenshot is 64k and the text file is only 500 bytes (or whatever).

joezydeco 11y ago
That's a much better analogy. I was expecting more of a realistic explanation about how the NES puts up the frame without a frame buffer. This falls into a mess about graphics compression, which is kind of irrelevant.
- corysama 11y ago
  You would like this: "How 'oldschool' graphics worked Part 1 - Commodore and Nintendo" https://www.youtube.com/watch?v=Tfh0ytz8S0k https://www.youtube.com/watch?v=Tfh0ytz8S0k
  - joezydeco 11y ago
    I prefer Montfort and Bogost's Racing the Beam from MIT Press: https://mitpress.mit.edu/books/racing-beam https://mitpress.mit.edu/books/racing-beam
kozukumi 11y ago
Indeed. I also didn't much like the comparison to the .kkrieger demo saying it was "only" 24KB more. Sure the raw exe is but it still needs GB of memory and a crazy fast CPU to do all the content generation at runtime. He also used inconsistent mb/MB, etc. which always gets on my nerves in a technical post but now I am just being an asshole at it is 2am here ;)

joosters 11y ago

Minor nitpick, but it screws up all the calculations: The original NES console was only designed to output images that were 256 wide by 240 high; meaning that the final image that needed to be displayed to the screen was 180kb in size. The NES definitely didn't have 24-bit colour, so the final image data was at most 60kb, assuming 256 colours, or 30kb assuming 16 colours and a palette. I don't know for sure what colour settings the NES had, I doubt it had a freely selectable 256 colours for each pixel. Probably a limited palette, maybe per-sprite, maybe for the whole screen.

mhurron 11y ago
> I don't know for sure what colour settings the NES had, I doubt it had a freely selectable 256 colours for each pixel. Probably a limited palette, maybe per-sprite, maybe for the whole screen. http://www.thealmightyguru.com/Games/Hacking/Wiki/index.php?title=NES_Palette http://www.thealmightyguru.com/Games/Hacking/Wiki/index.php?... "a total of 64 pre-set colors (56 of which are unique), and you can only show 25 on the screen at one time (under normal circumstances)." So ya, a little more limited than 24-bit colour.
wlesieutre 11y ago
Wikipedia to the rescue: https://en.wikipedia.org/wiki/List_of_video_game_console_palettes#Famicom.2FNES https://en.wikipedia.org/wiki/List_of_video_game_console_pal... - 4 palettes for sprites at a time, each containing transparent + 3 colors. So 12 sprite colors. - 4 more palettes for background (applied to 16x16 areas), each sharing their first color, for another 13 colors in the background. - Total up to 25 colors on screen simultaneously, selected from a 64 color palette that really had 54 useful colors.

mindslight 11y ago

I don't see why it's an "unfair" comparison. You just need to think of it in the right context. At the time Super Mario was popular, storing a still raster image took a lot of hardware. Generating an interactive picture on a TV was easy enough on consumer hardware, but simply recording a picture was not! Today we take the concept for granted, eg digital cameras.

DiThi 11y ago

- The tiles have many repeated images while in the original they could flip them and change the color palette. Note that the bushes and the cloud share sprites. - .kkrieger wasn't 64 kb, it's 96 kb. Still impressive though. - The image in the tweet is 51.4 kb. I was expecting some explanation about how the sprites are so tiny because they use a palette of 4 colors (and 4 pixels fit in one single byte), then the colors themselves are stored separately.

lost_name 11y ago
I feel like this is pretty important since the article is talking about the comparison in the first place. Here's a couple blog posts on the subject, which I think explain it better. http://www.dustmop.io/blog/2015/04/28/nes-graphics-part-1/ http://www.dustmop.io/blog/2015/04/28/nes-graphics-part-1/ http://www.dustmop.io/blog/2015/06/08/nes-graphics-part-2/ http://www.dustmop.io/blog/2015/06/08/nes-graphics-part-2/

deleted 11y ago

[deleted]

tribune 11y ago

Reminds me of a sarcastic response from my classmate back in my undergrad Signals class... the professor showed us a sample black-and-white photo and asked (rather rhetorically) how we would represent it using as few bits as possible. Classmate said he would build a machine that only displays that image, and give it an On/Off switch - a whole image with only 1 Bit!

TeMPOraL 11y ago
And this is the crucial insight. An image, or a game, does not contain all its data in those bytes you have stored in its file. A lot of information is spread around in the environment. It's one of the main ways demo-makers can cram so much content into so little space - they pull as much stuff from the environment as it's possible (and allowed by contest rules). To give an example: one of the most basic tricks, if you're allowed to use OpenGL and WinAPI, is to use WGL to render your system fonts into 3D shapes[0]. This allows you to get a lot of 3D models from just the few bytes it takes to call wglUseFontOutlines()[1]. You may think that there isn't anything interesting in a basic font, but - even forgetting about Unicode - every Windows has Wingdings... (Or look into the good old .EMF[2] format, which was basically direct encoding of Windows GDI calls.) For much more in-depth discussion on where exactly information is stored, be sure to read GEB[3], if you haven't already. [0] - https://www.youtube.com/watch?v=iri5CgLglkk https://www.youtube.com/watch?v=iri5CgLglkk - 1/10th size of Mario! [1] - https://msdn.microsoft.com/en-us/library/windows/desktop/dd374393%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/dd3... [2] - https://en.wikipedia.org/wiki/Windows_Metafile https://en.wikipedia.org/wiki/Windows_Metafile [3] - https://en.wikipedia.org/wiki/G%C3%B6del,_Escher,_Bach https://en.wikipedia.org/wiki/G%C3%B6del,_Escher,_Bach
- pavel_lishin 11y ago
  > And this is the crucial insight. An image, or a game, does not contain all its data in those bytes you have stored in its file. A lot of information is spread around in the environment. This is also an argument I've heard about growing people new bodies to transfer into (like Old Man's War) or digitizing humans (like the Singularity); apparently, a sample of DNA isn't enough to create a whole new person. You need, at least, a womb.

Gravityloss 11y ago

A large portion of the data is noise nowadays. Cell phone camera pixels are so small that they capture very little signal, yet everything is saved at full resolution. It's digital pollution.

jjaredsimpson 11y ago

kolmogorov complexity and mutual information are the things that explain the difference. The super mario rom is a very compact description of the super mario game, in the context of its environment. The jpeg environment isn't very well designed as an environment to display a single frame from a flat colored video game.

venning 11y ago

If you're interested in this stuff, the author also hosts the excellent Compressor Head video series: https://www.youtube.com/playlist?list=PLOU2XLYxmsIJGErt5rrCqaSGTMyyqNt2H https://www.youtube.com/playlist?list=PLOU2XLYxmsIJGErt5rrCq...

deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]

faint_coder 11y ago

really? this stupid question on Hacker News? O_O of course the bytes surplus derives from the fact that the image is a raster bitmap, while the game program DRAWS the bitmap, just like the difference between rasterizers and vector graphics. Its like having 1kb monolithic kernel which prints "Hello World" and then goes in while(1); forever, and snapshotting the entire screen and saving it in a .png file..