4 ms·

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 give

by Dwedit 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y ago
    Use xxd or od then.
rahen 3y 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 3y 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 3y 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 3y ago
    Out of curiosity, could you cite a few of those paradigms? I wholeheartedly agree, by the way.
bluedino 3y 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 3y 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 3y 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.
    - 3y ago

by Dwedit 3y 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 3y 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 3y 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 3y 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 3y 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 3y 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 3y ago
  Use xxd or od then.

rahen 3y 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 3y 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 3y 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 3y ago
  Out of curiosity, could you cite a few of those paradigms? I wholeheartedly agree, by the way.

bluedino 3y 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 3y 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 3y 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.
  - 3y ago