Determing what to render

Hey there /prog/

What's the best method to handle different "states" for rendering in my application?  I'm not too sure if this requires much time to process, but I'm sure there's a better method.

Currently I do:


...
namespace Worlds
{
    const int MainMenu = 0;
    const int Level = 1;
    const int Settings = 2;
}
...

//Loop:
switch (CurrentWorld)
{
    case Worlds:MainMenu:
        mainMenuWorld.draw();
    break;
    case Worlds::Level:
        levelWorld.draw();
    break;
    case Worlds::Settings:
        settingsWorld.draw();
    break;
}

"LevelWorld" Class's Draw Method:

switch (LevelID)
{
    case Levels::Grassland:
        grasslandLevel.draw();
    break;
    case Levels::Factory:
        factoryLevel.draw();
    break;
    case Levels::Town:
        townLevel.draw();
    break;
}

Obviously it's only an example, but I'm curious as to the best method for telling my application what it needs to render.

>>1
You should only have at most two worlds loaded (if you consider the loading screen as a "world").


//loop:
if (loading)
   draw_loading_screen();
else
   draw_world();

When you need to transition to another world, just have a function which unloads the current world and resets everything except the loading screen, and then loads in a specified world from disk:

reload_world("data\levels\level02.dat");

>>2
Each world has their own unique properties, so I'm not exactly sure how I could set something up like that and determine the "CurrentWorld" to render.  I only setup and allocate memory the world whenever I'm switching to it (i.e. "levelWorld.setup();")

I can only think of determining what to render with my switch loop.

>>3
Switch block / statement, not loop.

state machine. look it up.

>>1

For ENTERPRISE _scalable ^SOLUTION you can make an interface for things that can draw themselves like so:


class Drawable {
public:
  virtual void draw() = 0;
};

And then have your different worlds inherit from Drawable and override the draw method with something appropriate:


class MenuWorld : public Drawable {
public:
  void draw() {
    ...
  }
}

class LevelWorld : public Drawable {
public:
  void draw() {
     ...
  }
}

class SettingsWorld : public Drawable {
public:
  void draw() {
    ...
  }
}

And then you can store a pointer to the instance of Drawable that is currently being drawn on the screen:


class Screen {
  ...
  Drawable* thingyUserIsViewing;
  ...
}

And then instead of a switch statement, you'll have something like:


class Screen {
public:
  void update() {
    ...
    thingyUserIsViewing->draw();
    ...
  }
private:
  Drawable* thingyUserIsViewing;
}

This wont be any more efficient than your current method though. The only advantage is that it reduces the invocation of the draw function to a single line, and the different implementations can be spread out amongst many files. If your game is only going to have like 3 or 5 different views, then it might not be worth the trouble, and the switch statement may be easier to read and manage.

RENDER MY ANUS

>>6
virtual functions cost more.

switch is only faster when its compiled to a jump table, which virtual functions do by default.

Doesn't

class T {
public:
  void f();
};
mean the same as

struct T {
  void f();
};
?

Why are people afraid of using struct keyword? Is it just to show everyone your usage of classes?