______________________________________
### 3.1 Core App Design  (cSDLApp) ###

//// 3.1.0 Overview ////

I'll be using the cSDLApp base class for all my init stuff. I'll want to have a config
screen, which means I'll need a config file, which means I'll have to bring back my 
old file stream classes. The config editor will most likely be a separate app which.. 
edits the config file. The config file can also be editted by hand.


//// 3.1.1 cSDLApp methods ////

There are three primary functions which are overloaded, and form the basis of the game
application. All of the screen init stuff, input polling, screen updating, everything
is all already done for you in the background. Pretty handy stuff.

   virtual void cSDLApp::init();

This function is called once, and only once when the app first loads. Here we'll want
to set up the main menu, and stuff, basically get the game ready in its startup state.

   virtual void cSDLApp::running(DWORD step);

This is the function which is called every pass - we'll need to do all the rendering
keyinput, updating, everything in here. This is where it gets really messy.

   virtual void cSDLApp::shutdown();

Finally, this is where it all ends, everything is unloaded, and the app is shutdown.

   virtual void cSDLApp::onClick(int x, int y, int flags);

This is an input function I just now made up, whenever there is a mouse event it is 
called and sends the event type. The event types are stored in flags, with the following 
bitmasks
   
   #define MOUSE_RIGHT 0x00000001
   #define MOUSE_LEFT  0x00000002
   #define MOUSE_UP    0x00000004
   #define MOUSE_DOWN  0x00000008
   #define MOUSE_MOVE  0x00000010

The current position is passed via the 'x' and 'y' arguments. 

NOTE: While the mouse input could technically be buffered in a deque, immediate input 
processing is a good thing, and unlikely to bottleneck anything anyway.


//// 3.1.2 cSDLApp members ////

This is a list of members for cSDLApp. These members provide an easy interface between
the underlying functionality and your game code.

   bool         m_Running;

This is the main "running" variable for the whole app. The game code can force a 
shutdown with the following line:

   this->m_Running = false;

Doing this is much preferred over this->shutdown(); because shutdown is called anyway
when cSDLApp exits the main game loop. So, use m_Running to shutdown the app; don't 
call the shutdown function yourself :P

   SDL_Surface* screen;

"screen" is a pointer to the main SDL_Surface. It is set up and everything according
to the parameters you specify in cSDLApp::run (which can be overriden if you want).
This is the surface you should be rendering to. It is updated automagically each
pass by underlying code - don't worry about doing that.

   int          m_Width, m_Height, m_bpp;

These are helper variables that detail the format of the screen surface. Though they
can be extracted from the surface itself, using them like this is a lot cleaner.

   bool         m_Fullscreen;

Stores whether the app is in fullscreen mode or not. Doesn't make too much of a 
difference to gameplay, though it might potentially be helpful to know.

   bool         keys[SDLK_LAST];

This is where you get all your key input, which is stored as bools. Pretty simple.

   int          m_fps;

Handy variable which contains the fps of the app, which is sampled 5 times a second
(by default). You can change the sample rate by defining FPS_TIMESTEP before 
including "cSDLApp.h"

   int          m_Step;

Amount of time that has elapsed since last pass. Automagically passed to the 
cSDLApp::running(..) function each call anyway, though if you wanted to access it 
for some reason this way you could too (ie, passing a pointer to the game object, 
and not needing to pass the timestep).


_______________________
### 3.2 Game States ###

//// 3.2.0 Overview ////

While this is all fine and dandy, we need some way to store the state of the 
game - whether the user is looking at the main menu, or actually playing the game 
(or whatever). We can do this through game states, which basically partition different 
areas of code for the game.


//// 3.2.1 Base Class ////

Naturally, each game state would have unique code behind it. Since we don't know what 
kind of state we'd have, we'll be using polymorphism to give us a helping hand. Thus, 
all game states will be derived from the same base class (a pure abstract class)

class cState : public cSDLRenderable {

   // init function which sets up the instance. Could be alternatively be
   // done with a constructor.
   virtual void init();

   // render function inherited from cSDLRenderable. Gets passed the
   // main screen surface (cSDLApp::screen)
   virtual void