DementedPurple wrote:
I don't want to make a clone of that game, I want to make a game that's similar as in it has large scrolling levels and I don't know how I would fit these level into 32 kilobytes of space.
Why are you creating this artificial limitation of 32KB? Back when SMB was made there was a reason for such a limitation, but nowadays you can easily use bankswitching and not have to deal with such a convoluted level format.
SMB's level compression is based on objects, meaning that each screen is initialized to a mostly blank template and is then populated with "objects", which are block-based structures of varying dimensions drawn at specified X&Y coordinates.
Quote:
I don't really care if it's the level compression the Super Mario Bros. used, all I care is if it's a form of level compression one way or another.
The ideal level compression scheme is the one that takes advantage of the redundancy that exists in the kind of structures the game uses. But for beginners, it's best to go with simpler formats that are easy to encode/decode, so as to not dramatically increase the complexity of the program or the tools used to design the levels.
For side scrolling games, I always recommend a column-based approach: create a dictionary of columns and then reference those columns to create level maps. This results in decent compression ratios but is still dead simple to code, and you can easily build levels without using any tools (just type it all as .db statements).
Quote:
I was just asking for the Super Mario Bros. way of doing it because I assumed it would be less complicated then all of the other ones.
If you really need to know it, SMB's level compression is pretty well documented (
here, for example), so there's no need to repeat any of that information here. IMO, it's actually fairly complicated and restrictive, and that's because they needed to cram a lot of stuff in just 32KB.