Super Mario Bros. game was just 31 Kilobytes. How's that possible?

1. Super Mario Bros. is 40KB (PRG ROM is 32KB, and CHR ROM is 8KB). That said, I suppose if you were to compress the ROM, you probably would end up with value like 31KB.

2. Levels don't use RLE or LZ77, that would use too much space. Rather, the game uses commands like "from now on, use this ground fill pattern", "draw pipe here", "put a staircase", "put a goal". Super Mario Bros. uses two bytes per object, representing the following information: XXXXYYYY PSSSVVVV, where X is horizontal position within the page, Y is vertical position within the page, P moves to the next page, S is a command, and V is its parameter (length or number of an extended object). Y positions bigger than 0b1011 are used for special commands (as such parameters would be rendered out of bounds).

3. Graphics aren't compressed as they are stored in CHR ROM, and are directly accessed by the PPU (PPU cannot access RAM). However, as the graphics are 2bpp, they don't use as much space. Palettes are used to not restrict the entire game to 2bpp - note that 16x16 blocks have different color palettes. Some tricks are used to reduce the number of necessary tiles - for instance, clouds are the same thing as bushes, just with a different palette applied.

4. Demoscene is misleading. The way demoscene works is that most things are using procedural generation, meanwhile the levels in Super Mario Bros. are actually designed, and graphics were drawn by an artist, they aren't using some arbitrarily picked mathematical function chosen because it looked cool. The game has to be playable after all.

To explain Super Mario a bit better, it's really not using many tricks. The graphics are uncompressed and take up 8KB. The code is uncompressed. The only thing really compressed is the levels. The explosion in video game size from then to now is because asset detail grows O(N^2) - if you double the detail of a texture you end up squaring the size.

Erm, not really. Most of the time it's because they spend like 3 minutes of loading time generating textures and all in memory before displaying anything on screen. And they rely on the giganormous graphic libraries of Windows (for Windows demos) + the huge driver stack that would never fit in 64kb in the first place.

I am much more impressed by demos built to run on "the hardware" back in C64 and Amiga days.

Note: I think you can actually talk about fractional bits in information through

> Which, for the next 2 billion folks in emerging markets, on 2G connections, is like the worst idea ever.

Which emerging markets still use 2G? In almost all of the world 2G is being phased out and it’s in developed economies where it is scheduled to take the longest. Many emerging markets had their infrastructure created after 2G was obsolete and are already on better technology.

https://www.emnify.com/blog/global-2g-phase-out

Back in the '00s, I made a j2me mobile realtime multiplayer online strategy game, which included animations, music and sfx. It was 60kb, because I wanted to target as many devices as possible.

Later it grew till about 200kb

Lots of space and performance optimizations.

I'll take the devil's advocate position on this tangent. Mobile data infrastructure is remarkably reliable and cost-effective in emerging markets.

Anecdotally, I live in Canada. We have some of the most expensive and restrictive mobile phone service in the world. 4G coverage is still spotty, even in major cities. On a recent trip to Morocco it was really astounding to me how much cheaper, faster and more ubiquitous 4G service was.

Here is some actual data:

[0] Global pricing of 1GB of data: https://www.cable.co.uk/mobiles/worldwide-data-pricing/

[1] Mobile data speeds by country: https://www.opensignal.com/reports/2018/11/global-state-of-t...

Interesting that a single screenshot of the game weighs more than the entire game.

So i'd say the final image would be 60 kbytes. Can someone confirm ?

It's good to look back and appreciate the fundamentals, since there was a lot of clever thinking in this we can learn from today. There are often times I'll come up with an overly hefty solution in a generic case, instead of thinking like Nintendo did about focusing on making something cool to look at with a fun experience, though with a much narrower scope. NLP is one place I see this a lot - it's often very easy to make aws happy when I go through GBs of data, for something where 95% of the value to the end user could be reached with a 50kB file on the S3. Dapps are another one - helps a lot to think like a Nintendo dev in the 80s about what the reusable parts of your data are.