
Where do all the bytes come from? - EddieRingle
https://medium.com/@duhroach/where-do-all-the-bytes-come-from-f51586690fd0
======
larrik
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
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
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
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)

------
joosters
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.

~~~
wlesieutre
Wikipedia to the rescue:
[https://en.wikipedia.org/wiki/List_of_video_game_console_pal...](https://en.wikipedia.org/wiki/List_of_video_game_console_palettes#Famicom.2FNES)

\- 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.

------
tribune
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
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/dd3...](https://msdn.microsoft.com/en-
us/library/windows/desktop/dd374393%28v=vs.85%29.aspx)

[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
> _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.

~~~
TeMPOraL
This also ties back to the Reflections on Trusting Trust[0]. Living things are
not made in a single factory, but are akin to the compilers compiling
compilers. It's interesting to ask just how many things about us are not
expressed in the DNA at all, but instead propagated implicitly by the
replication mechanisms, Ken-Thompson-style.

[0] - [http://fermatslibrary.com/s/reflections-on-trusting-
trust](http://fermatslibrary.com/s/reflections-on-trusting-trust)

------
DiThi
\- 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
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/)

------
mindslight
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.

------
fbbbbb
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
> _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
Yea, and the reference links were interesting too. The LZSS youtube video was
an enjoyable watch.

------
jjaredsimpson
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.

------
faint_coder
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..

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

------
Gravityloss
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.

