6 ms·

I hope developers still love to blog details with article mode like this, rather than vlogging it on YouTube. A lot of detail packed into a few kilobytes only.

I hope developers still love to blog details with article mode like this, rather than vlogging it on YouTube. A lot of detail packed into a few kilobytes only. "Super Mario World" is still the masterpiece game ever. It has amazing characters, sprites, and stages packed into only 360 KB.

Dwedit 2y ago
The file sizes given by the site are wrong. Super Mario World is 512KB, or 508KB if you discard the padding at the end. Only compressing it to ZIP format gives you a file size around 360KB.
- fabiensanglard 2y ago
  Yea, after writing this I regretted using zip to estimate usage. Probably would get better number by extracting each zip and look how much zero padding is at the end of the file. WDYT?
  - Dwedit 2y ago
    I think applying RLE to the file might give a better estimate, because files have blank space throughout, not just at the end. Just tried it on Super Mario World and the estimated size was 479,154 (468K) bytes. If you don't have an RLE tool handy, you can force Pucrunch to act as an RLE-only compressor by using the -r 0 switch which disables the LZ compression feature.
  - justsomehnguy 2y ago
    Just query each archive for the total uncompressed data. While the 'real' code+data is less than the size of the banks, the banks are always ^2.
    - Dwedit 2y ago
      The goal here isn't to tell the real file sizes, the goal here is to estimate the "effective" file size without any padding. Padding can be at places other than the end of the file.
  - morcheeba 2y ago
    hexdump will automatically does "squeezing" of repeated lines. Follow this with a line count and multiply by the bytes/line and you'll get a rough number of non-repetitive bytes. https://man7.org/linux/man-pages/man1/hexdump.1.html https://man7.org/linux/man-pages/man1/hexdump.1.html
    - anthk 2y ago
      Use xxd or od then.
- rahen 2y ago
  It's still quite impressive to fit such a lengthy and fun game into 508KB without any procedural generation, just tight assembly and clever use of bitmaps. This is programming art.
  - bdw5204 2y ago
    This is largely a lost art because of several bad paradigms that have become very popular in recent years, making software exponentially worse in the process. In the old days, it was common and NES games were even smaller than SNES games because the graphics were much less complex. I believe Super Mario Bros 3, which many people still insist was better than Super Mario World, actually fit into 32KB.
    - jsd1982 2y ago
      SMB3 is 3 Megabits in size, aka 384 KiB. You're likely thinking of the original Super Mario Bros which is just 40 KiB.
    - rahen 2y ago
      Out of curiosity, could you cite a few of those paradigms? I wholeheartedly agree, by the way.
- bluedino 2y ago
  Did they not compress the assets like they did in other games, like M.C. Kids? https://games.greggman.com/game/programming_m_c__kids/ https://games.greggman.com/game/programming_m_c__kids/
  - JohnBooty 2y ago
    As the linked article notes, some of the special on-cart chips were mainly used for data decompression, like the SPC7110. So on those games, definitely compressed assets! But... I'd love to know how often assets were compressed on "normal" carts without special chips. Decompressing assets on the fly during gameplay action seems like it would be quite a challenge for the SNES' CPU. My understanding is that images on title screens and cinematics were often compressed. Anime/comic art styles lend themselves really well to RLE compression because you have lots of consecutive pixels of the same color. And, obviously, these can be fairly static images that don't need to be updated 60 times a second. Definitely an outlier, but: the title screen of Secret of Mana was actually a JPG that took around a minute (!!) to decompress. The music and scrolling text are cleverly designed to mask this: https://manaredux.com/lore/how-was-the-incredible-title-screen-sequence-for-secret-of-mana-made/ https://manaredux.com/lore/how-was-the-incredible-title-scre...
    - wk_end 2y ago
      From what I've seen, on average, with many exceptions, most games will lightly compress most data. Tile graphics and layouts only need to be decompressed whenever a scene/level/map is loaded. Games aren't doing streaming audio or anything, so song data can be decompressed and uploaded to the sound processor before a level starts too. Likewise, text needs to be decompressed once immediately before it's displayed, so games will usually compress that - it's quick enough to decompress a few hundred bytes while the text box loads. The only thing that I've seen that's usually stored uncompressed is sprite animation data - particularly for player characters with lots of different animations. There's not enough VRAM to load all of it at once, so it needs to be streamed in, and in that case the CPU often just doesn't have the muscle.
      - 2y ago
c0wb0yc0d3r 2y ago
> hope developers still love to blog details with article mode like this, rather than vlogging it on YouTube. I think the driving force behind this for many is it's much harder to steal video content. With text bits can scrape it change a few words and reuse it on an SEO ad site.
- nicole_express 2y ago
  I've definitely noticed as a blogger many sites are so brazen stealing content that they'll even hotlink to my images, so I can find their copying in my server logs. Very annoying.
wazoox 2y ago
"Pitfall!" on Atari VCS held 255 entirely different game screens in a 4k cartridge :)
- cduzz 2y ago
  Isn't it more of "Pitfall!" has a set of 255 levels that are procedurally generated and the author spent a ton of time searching for the best seed that would generate the levels we know today. It isn't as if you could have a map editor and adjust the levels or the order of the levels, though you could run the generation procedure to find new levels to your liking. Still an amazing game. In 4k it is astonishing.
  - netmare 2y ago
    David Crane, the creator of Pitfall, explains it all very nicely in a GDC Classic Game Postmortem [1]. I'm linking at the relevant timestamp, but the whole video is pure Atari 2600 goodness. The full Postmortems playlist is quite enjoyable too. I particularly liked the talks about the original Deus Ex, Myst, Loom, Adventure, Marble Madness, Ms. Pac-Man, Paperboy, Lemmings, and more. I find these videos very soothing and nostalgic. Got to rewatch them now... [1]: https://youtu.be/tfAnxaWiSeE?list=PL2e4mYbwSTbbiX2uwspn0xiYb8_P_cTAr&t=1346 https://youtu.be/tfAnxaWiSeE?list=PL2e4mYbwSTbbiX2uwspn0xiYb...
- rahen 2y ago
  Take a look at Solaris. Another huge game with 48 sectors and probably the best graphics seen on the 2600, all in a 16k cartridge. Quite a feat considering how horrifyingly difficult programming the 2600 was. Even the SDK was fairly barebones, basically a VT100 connected to a PDP-11 running RT8 and a 6502 assembler
  - rahen 2y ago
    ^ Sorry, I obviously meant RT11, not RT8.
tombert 2y ago
Super Mario World is great, but I stand by Donkey Kong Country 2 being the best game on the system. To me, it just nails every single aspect of platforming, with awesome music, tight controls, and appealing graphics. Terranigma is right up there as well for me; Super Mario World is probably number 3 in my book.

Dwedit 2y ago

The file sizes given by the site are wrong. Super Mario World is 512KB, or 508KB if you discard the padding at the end. Only compressing it to ZIP format gives you a file size around 360KB.

fabiensanglard 2y ago
Yea, after writing this I regretted using zip to estimate usage. Probably would get better number by extracting each zip and look how much zero padding is at the end of the file. WDYT?
- Dwedit 2y ago
  I think applying RLE to the file might give a better estimate, because files have blank space throughout, not just at the end. Just tried it on Super Mario World and the estimated size was 479,154 (468K) bytes. If you don't have an RLE tool handy, you can force Pucrunch to act as an RLE-only compressor by using the -r 0 switch which disables the LZ compression feature.
- justsomehnguy 2y ago
  Just query each archive for the total uncompressed data. While the 'real' code+data is less than the size of the banks, the banks are always ^2.
  - Dwedit 2y ago
    The goal here isn't to tell the real file sizes, the goal here is to estimate the "effective" file size without any padding. Padding can be at places other than the end of the file.
- morcheeba 2y ago
  hexdump will automatically does "squeezing" of repeated lines. Follow this with a line count and multiply by the bytes/line and you'll get a rough number of non-repetitive bytes. https://man7.org/linux/man-pages/man1/hexdump.1.html https://man7.org/linux/man-pages/man1/hexdump.1.html
  - anthk 2y ago
    Use xxd or od then.
rahen 2y ago
It's still quite impressive to fit such a lengthy and fun game into 508KB without any procedural generation, just tight assembly and clever use of bitmaps. This is programming art.
- bdw5204 2y ago
  This is largely a lost art because of several bad paradigms that have become very popular in recent years, making software exponentially worse in the process. In the old days, it was common and NES games were even smaller than SNES games because the graphics were much less complex. I believe Super Mario Bros 3, which many people still insist was better than Super Mario World, actually fit into 32KB.
  - jsd1982 2y ago
    SMB3 is 3 Megabits in size, aka 384 KiB. You're likely thinking of the original Super Mario Bros which is just 40 KiB.
  - rahen 2y ago
    Out of curiosity, could you cite a few of those paradigms? I wholeheartedly agree, by the way.
bluedino 2y ago
Did they not compress the assets like they did in other games, like M.C. Kids? https://games.greggman.com/game/programming_m_c__kids/ https://games.greggman.com/game/programming_m_c__kids/
- JohnBooty 2y ago
  As the linked article notes, some of the special on-cart chips were mainly used for data decompression, like the SPC7110. So on those games, definitely compressed assets! But... I'd love to know how often assets were compressed on "normal" carts without special chips. Decompressing assets on the fly during gameplay action seems like it would be quite a challenge for the SNES' CPU. My understanding is that images on title screens and cinematics were often compressed. Anime/comic art styles lend themselves really well to RLE compression because you have lots of consecutive pixels of the same color. And, obviously, these can be fairly static images that don't need to be updated 60 times a second. Definitely an outlier, but: the title screen of Secret of Mana was actually a JPG that took around a minute (!!) to decompress. The music and scrolling text are cleverly designed to mask this: https://manaredux.com/lore/how-was-the-incredible-title-screen-sequence-for-secret-of-mana-made/ https://manaredux.com/lore/how-was-the-incredible-title-scre...
  - wk_end 2y ago
    From what I've seen, on average, with many exceptions, most games will lightly compress most data. Tile graphics and layouts only need to be decompressed whenever a scene/level/map is loaded. Games aren't doing streaming audio or anything, so song data can be decompressed and uploaded to the sound processor before a level starts too. Likewise, text needs to be decompressed once immediately before it's displayed, so games will usually compress that - it's quick enough to decompress a few hundred bytes while the text box loads. The only thing that I've seen that's usually stored uncompressed is sprite animation data - particularly for player characters with lots of different animations. There's not enough VRAM to load all of it at once, so it needs to be streamed in, and in that case the CPU often just doesn't have the muscle.
    - 2y ago

c0wb0yc0d3r 2y ago

> hope developers still love to blog details with article mode like this, rather than vlogging it on YouTube. I think the driving force behind this for many is it's much harder to steal video content. With text bits can scrape it change a few words and reuse it on an SEO ad site.

nicole_express 2y ago
I've definitely noticed as a blogger many sites are so brazen stealing content that they'll even hotlink to my images, so I can find their copying in my server logs. Very annoying.

wazoox 2y ago

"Pitfall!" on Atari VCS held 255 entirely different game screens in a 4k cartridge :)

cduzz 2y ago
Isn't it more of "Pitfall!" has a set of 255 levels that are procedurally generated and the author spent a ton of time searching for the best seed that would generate the levels we know today. It isn't as if you could have a map editor and adjust the levels or the order of the levels, though you could run the generation procedure to find new levels to your liking. Still an amazing game. In 4k it is astonishing.
- netmare 2y ago
  David Crane, the creator of Pitfall, explains it all very nicely in a GDC Classic Game Postmortem [1]. I'm linking at the relevant timestamp, but the whole video is pure Atari 2600 goodness. The full Postmortems playlist is quite enjoyable too. I particularly liked the talks about the original Deus Ex, Myst, Loom, Adventure, Marble Madness, Ms. Pac-Man, Paperboy, Lemmings, and more. I find these videos very soothing and nostalgic. Got to rewatch them now... [1]: https://youtu.be/tfAnxaWiSeE?list=PL2e4mYbwSTbbiX2uwspn0xiYb8_P_cTAr&t=1346 https://youtu.be/tfAnxaWiSeE?list=PL2e4mYbwSTbbiX2uwspn0xiYb...
rahen 2y ago
Take a look at Solaris. Another huge game with 48 sectors and probably the best graphics seen on the 2600, all in a 16k cartridge. Quite a feat considering how horrifyingly difficult programming the 2600 was. Even the SDK was fairly barebones, basically a VT100 connected to a PDP-11 running RT8 and a 6502 assembler
- rahen 2y ago
  ^ Sorry, I obviously meant RT11, not RT8.

tombert 2y ago

Super Mario World is great, but I stand by Donkey Kong Country 2 being the best game on the system. To me, it just nails every single aspect of platforming, with awesome music, tight controls, and appealing graphics. Terranigma is right up there as well for me; Super Mario World is probably number 3 in my book.