As a kid in the early 1990s I always thought 8-1 was unusually long and I always seem to get down to the 99s warning music before I can finish the level, even running at full speed. This visualization really shows clearly how much longer that level is compared to the rest.
but a good image compression algorithm could find these repeated patterns and store them only once. If anything, I would expect that this image compressed by a modern algorithm would be much smaller than the original game.
It really can't, not in a way that would allow the image format to be generic enough. Remember that PNG is used for trillions of images, whereas SMB has the luxury of only caring about a limited set of colors, and of having a Sprite engine available in the console itself to help optimize it all.
You're looking at a lot of procedural data where for example the patterns behind the sprites can change without having to create a new sprite. Where the palettes were separate from the image data so they could look different without having to use double, triple the storage. These things can't be picked up on by png, it's not a smart enough format to be able to arbitrarily detect all repeated patterns of varying sizes and turn them into what amounts to a procedural level script.
I can't find a good exhaustive sprite sheet of SMB (this is the best I can find, but it contains a ton of repeats: https://www.mariouniverse.com/sprites-nes-smb/). I'd love a visualization of just how tiny SMB is in terms of what's stored in it.
A good image compression algorithm could. PNG just isn't smart enough for this purpose. One could argue that the NES code and PPU data itself constitute a very efficient compression scheme for compliant images, albeit human-crafted rather than algorithmic. IOW, it's unlikely any automatic compression scheme will outperform simply running the SMB program.
You sure this wasnt' in Nintendo Power back in '89? ;) I remember these types of visualizations to help walk through / beat the old NES games - especially Metroid!
The second column here [1] has links to individual level PNGs. It's not the whole game in a single image, though. I'm surprised to see that "VGMaps.com: The Video Game Atlas" hasn't been mentioned yet in this thread.
Very nice. A few years back I wrote http://mariocraft.club/ for fun (Super Mario in Javascript). Allows you to build your own levels. Very basic and unfinished but people love building levels.
If anyone has interest in picking up the project, and auto-generating the levels, ping me.
@matts_ramblings approach is great to get a perfect authoritative reference we can use to test and/or train other tools.
Other tools mapping the Super Mario Bros. levels:
1. animmerger [1] by bisqwit
Written in C++.
Takes png images as input.
This tool seems to be the reference in creating level maps for Super Mario.
Matt's tool seems to use animerger to generate the color palette according to the source code [2]
2. ALMA [3] by BZH314 (disclaimer: our baby project)
Matt mentions using this approach as a possibility in the post.
Written in Python using the OpenCV [4] computer vision library.
ALMA takes videos as input, generates the map levels as images (png and animated gifs) and also generates the videos to show the algorithm in action [5]
(shameless self plug: need more YouTube subscribers to get that sweet sweet vanity URL please :-)
ALMA applies background subtraction to remove the moving enemies in order to keep only the background (a problem Matt's tool does not have)
3. Manually stitched
If you're looking for good SMB1 level maps stitched manually, there are some good work out there:
I want to do more of these and experiment with training generative neural nets on that kind of thing when I get the chance.