So I decided to once again dabble in game development and again do 2D for experience. Last time I used SDL 1.2 and sprites(BlitSurface), this time I will use SDL 2.0,Chipmunk-Physics and again some 2D sprites.
First off I'd like to question your use of a physics library in a platformer. I think there's a bit of a misconception from people about needing to use a physics library in a game with motion.
Thing is a physics library is often designed for things like rigid body physics, complex interactions and movements that often are a lot harder to process than simple movements. A good candidate for when you might use a library like that is if you want actual physics objects, like being able to run into a box and it tumble. You would not use it for something like mario, the code will if anything be much slower and needlessly complex, especially when you're doing things like impulses for movement instead of just adjusting velocity.
You can see that the character is walking on stone BUT above him there are objects he can interact with(in this game's case, usually smashing those bricks or bumping the question marks if he hits them from below, or walk on those objects) and there are objects behind the character such as bushes or trees and even clouds above which do not collide with the character.
But what kind of map is that, and how can I replicate the results(I do not want to make a clone, just something that utilizes this concept). Because I have no idea how one would describe that map. Funny, the game was made in 1984, and nearly 30 years later I still have no idea how it's done.
I'll go into a little lesson just to illustrate the process of thinking over just taking a ready made solution.
The easiest way to think about how to deal with stuff like this is to seperate it mentally into two seperate "planes of existance" in memory, and on disc. In memory you may have something like a grid where "tiles" are placed, objects like boxes and things in a mario game may count as a special tile or perhaps a seperate entity, things like enemies would of course be seperate from a tile.
Now that you have that in your head, think about the information you need to save from that. Well you certainly don't need to save the enemies with the tiles, if you needed to save them at all you could save their positions as seperate information, what you end up with is the fact that you need to save the positions of each tile and then simply place that back into memory when loading the level.
So how could you do that? Well the easiest way would be to split the map into a grid and simply save -every- tile, but thats a little wasteful, especially on a game like mario where most of the "blocks" will be sky and the rest will be sparsely placed areas above the ground. So maybe you could do something like only save each block that isn't just air and its position, that would probably at least half the information needed to actually have the level ready in memory.
So of course now you have your data, you can save it and load it. One thing a game may choose to do is since we have that information as just a bunch of bytes now, you could theoretically use some kind of algorithm to compress the data together(merging sets of numbers into a single number then reverting it to normal form when you load the level.) A bit of an advanced topic but it of course gives an insight into how you might -approach- things like this.
And while I have not forgotten, on a tile-based map how can one place objects on the tiles themselves? For my old game test(which was just random junk) I read the map from a file being just numbers that represented a different sprite but one couldn't describe an object on those tiles.
As I pointed out that usually depends on your game and how you seperate objects and enemies. In a 3d game for example the terrain is often saved and treated in a vastly different way from a moving object like an enemy or physics object, it's often saved seperately so that a map file might contain just the static geometry of the level and all the entity data, trigger data, map flags and such all squashed together into a compressed file.
For instance in a mario game how would you treat the moving platforms that follow rails like in super mario world? Logically you probably would save them as entities instead of a map tile or something because they have complex motion behavior. But on the other hand if you have something that animates but may be treated in code as a tile you may just save it as one. It's all about the game and your perspective.
And perhaps last, but probably not least. Using OpenGL or the Graphics API in SDL 2.0 for the sprites/drawing? Because I feel like I am not yet ready for GL.
If you aren't ready for straight opengl, don't use it. Quite frankly the only time I would suggest venturing into opengl is either when you become curious about it or you really hit a point in developing a game where you -need- that extra performance. Don't learn things just to learn things, if they're important you'll learn about them when the time comes and get -way- more out of them!
Also yes, tiled is a good suggestion for a tool, you can adapt it to save data in a way you need it to, and set your game up to load it.