Not sure if this is the right place to post this, but here goes: I've been programming with C++ and DirectX for several years now but I've just now started looking into SDL. I like the simplicity of it, and since 2D games are mainly what I've been programming it seems like a good fit for me. My question, is this: I really want to build a basic framework around SDL: like some wrapper classes and such, but a little more advanced than that. Are there any good tutorials out there that can put me on the right path as far as the basics of building an engine? I'm looking for suggestions on how it should be organized, like what base classes I should have, etc. Thanks, greystone

You want SDL, try http://cone3d.gamedev.net
You will find a complete collection of perfect SDL tutorials. It also explains basic use of 2d graphics with sound support. For other things such as SDL_net or SDL_image try Lazy Foo's tutorials. So putting it together Cone3d and Lazy Foo are best for SDL.

I'm far from an expert when talking about engines. But in my SDL based framework, I basically encapsulated all SDL related stuff in a class called system. Actually it's SDLSystem which derives from System interface. At least in theory it should provide pretty independent way to handle all the basics. Thought I haven't tried to port it to any other library/API.

Scummvm seemed to do it the same way. So if it doesn't feel too daunting I recommend to read its sources. At least to me the code of Scummvm looks pretty clean and easy to understand.

I've never seen a good tutorial for writing an actual game engine. There's probably books, but I tend not to buy them (I'm not made of money :P ).

I've been working on an engine, and learned a lot, both good and bad, from looking at other engines.

Take Ogre3D for example. I wanted platform independence, so I copied it's rendersystem setup, where you have a "RenderSystem" class that has OpenGL and Direct3D implementations. But at the same time, I made a point of not using 1000 singletons like it does.

So a brief summary of how mine works (I use c#):

I have an IGraphicsProvider interface that serves both as a thin wrapper around Direct3D, OpenGL, and Xna implementations, and as a factory for device dependent objects like vertex buffers and textures.

IGraphicsProvider has a "CreateWindow" function that surprisingly enough, returns an implementation of the IWindow interface with the given dimensions and colordepth, in windowed or fullscreen mode.

The Xna and Direct3D versions return a winforms implementation of IWindow. At least in windows: when running on the xbox, the Xna implementation mostly doesn't do anything, since you don't have access to an actual "window". It's mostly a placeholder to maintain cross platformability.

However the OpenGL implementation of IWindow uses SDL. The nice thing about this object orientated setup is that later on I can replace SDL without breaking anything. Personally I hate dependencies, so later I can have CreateWindow return platform specific implementations of IWindow. That is, win32 for windows, SDL for linux (since linux usually has SDL anyways), and cocoa for osx. But until I get around to researching that, SDL serves admirably. And because it's abstracted away, the user won't be aware of the change.

Anyways the engine makes use of IGraphicsProvider, and so NEVER directly accesses OpenGL, Direct3D, or Xna. It doesn't know or care which api is being used.

Incidently, I use the same setup for input. An IInputProvider interface with DirectInput, SDL, and Xna implementations. Ditto with Audio.

Wow guys thanks for all the great feedback. You have given me a lot to think about. Thanks again.