Well, thanks to all your guys' help, I've managed to create a mostly clean game engine, minus a few bugs. Once I'm done with this, I'm going to adapt all my projects to use it.
However, I have one problem. I've been working on a tiling system for a about 6 hours straight, I have a bug, and I cannot test it because of LAGGGGGGGG. I don't even know if my tile function works because of this. I need serious help. Heres the dropbox file of my game (Don't steal my graphics, they aren't authorized to be used in any other projects of any sort) The compiled project with the lag is under the "Release" folder:
I was looking into FPS control as you can see in my code, but its not making much of a difference. I have a feeling it is because all of the blitting of tiles to the screen.
#1: You are loading the tileset image at drawing time.
#2: You are loading the tileset image for each tile, every time it's drawn
#3: You never unload the tileset images.
Loading is very slow, and consumes a lot of memory. Your tileset image is 192x64 pixels.
at 32bpp, this means having the image loaded once in memory consumes at minimum 192*64*4 = ~49K
You are drawing 441 tiles per frame. Each time you draw a tile, you are loading the image yet again. This means you are loading a 49K image 441 times.
This will consume > 2MB of memory per frame.
After 1000 frames (maybe 16 seconds of game time), that's over 2 GB of memory. On top of all the work the computer has to do to load that much. It's no wonder you're getting crap performance.
You need to load images only once. Keep the SDL_Surface around for as long as you'll be drawing from it. Do not keep recreating new surfaces every time.
Additionally.. each tile should use the same surface. You should not have the same tileset graphic loaded for each of the 441 tiles.
To make this easier, you can make a resource manager which owns all the image surfaces. Then your tiles can just poll that resource manager to get the pre-loaded surface, rather than having them load the image themselves.
It's also worth noting that I've found SDL (1.2)'s performance to be subpar even when used correctly. The list of games Script Coder linked to probably do their drawing with OpenGL and just use SDL as the window manager. In my experience that's the only way to get anything near acceptable performance out of it.
Just scanning through (without compiling and running), I notice a problem in Map.cpp, line 87. You re-load the entire tileset image into memory for every tile you draw. You pass the SDL_Surface pointer to Tile::Render, which blits the surface, then leaks the SDL_Surface pointer (afaik, you have to call SDL_FreeSurface to properly delete SDL_Surface contents from memory. I don't know if you can just let the pointer go out of scope or not.)
So you re-load the tileset into memory for each tile you want to load, then possibly have an accumulation of unused copies of the tileset in memory because they're not being deleted.
Load the tileset into memory once, then hold onto that SDL_Surface pointer.
@ devonrevenge: The most common issue I see with this is that the images aren't in the correct working directory. This is a huge PITA because each IDE seems to have it's own opinion of what your working directory should be. It's easiest to just use complete paths to your image files and not relative ones.