Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views


Sign in to follow this  


  • Random Observation of the Day
    Chicks dig giant robots!

I tried to beat MindWipe's .. record today. His was 8, I'm up to 5 so far (my old record). Pretty frickin' hard to get more than that, though (no, pun intended).

Just... don't ask.
Sign in to follow this  

1 Comment

Recommended Comments


### 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

#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

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!