In the past I've been making simple games with a simple game loop where I handle input, do logic calculations, draw, and then cleanup. However, on my current, large 2d project, I realized that this method no longer applies well in the "larger games" arena. This method, when used, kills the game's FPS. So far the current rate is 25, and I haven't implemented all the features yet. Now some of you would argue that 25fps is fine for 2d games, however, I haven't implemented much of the game yet.. So I was wondering if you guys have any suggestions for optimizing this simple loop method or have a better method altogether...

You're doing something wrong with the drawing if you only get 25 FPS. A typical game loop looks like this:

while (!done) {
   while (timer_ticker > 0) {
      process_one_frame_of_logic();
      --timer_ticker;
   }

   if (need_to_redraw) {
      draw_one_frame_to_the_backbuffer();
      blit_buffer_to_screen();
   }
}

Any major deviation from this is likely to be wrong.

wegstar, could you provide a sample of what your code's loop currently looks like?

int main(void)
{
  ...
  while (!exit_game)
  {
    get_userinput();
    update_animations();
    move_npcs();
    move_player();
    play_sound();
    blit_to_screen();
  }
  return 0;
}

This is a generic loop you might see in different peoples' code. Are you saying that this is where all of your FPS slowdown is coming from?

NO! it should not run at less than 60fps.

OOP is the only way to write complex games IMHO.

Or if you want to ruthlessly abuse the CPU: (This is so you can see how fast your CPU maxes out).

while (!done) {
   while (timer_ticker > 0) {
      process_one_frame_of_logic();
      --timer_ticker;
   }

   while (timer_ticker <=0) {
      draw_one_frame_to_the_backbuffer();
      blit_buffer_to_screen();
      fps++; //<--- For kicks you know.
   }
}

My code roughly translates to this:

int main(void)
{
  ...
  while (!exit_game)
  {
    get_userinput();
    update_world();
    update_player();
    update_npcs(); // loop through a global list of npcs and run their update funcs
    //draw some extra things here
    blit_to_screen();
  }
  return 0;
}

When I removed a portion of the code where I did drawing in a for loop, I had a 5 fps increase...

for(int i = 0; i < int(player.bullets); i++){
     blit_bullets_to_buffer(x*i, y); // (x position, y position)
}

But normally, doing simple logic calculations involving setting variables shouldn't cause too much latency..correct?

Are you loading and unloading and data inside the loop? If so, then don't. Are you doing any drawing in the logic code? Don't do that either. How do you measure the framerate? Why aren't you using timers?

Okay, as requested, here is a bad summary of Game Coding Complete's architecture.

You have three separate systems, that communicate via a message system that is controlled by the Game Application Layer.

• Game Application Layer

• Game Logic Layer

• Game View*

_{*Game View is actually a list of Game View interface objects that can be local players, AI agents, or networked players.}

Example of message system:
"A" Button is pressed on keyboard

Human View checks for button presses, translates button press to game message "Apply Emergency Brake" and sends it

Game Logic receives message and changes the state of the player's car, sending a message back to the Human View: "Car State: E-Brake On"

Human View responds to the message by maybe changing the visual representation of the car to have its tires lay down rubber or something

---Game Application Layer---
Connection and disconnection of devices like keyboards and mice
Files
RAM
Timing
Language DLLs
Threads
Network connection
Core libraries
The main loop (AppLayer->Run();)
Init & Shutdown

---Game Logic Layer---
**you may have different implementations of the Game Logic that you swap in and out depending on whether the player is in server or client mode, single player or multiplayer, whatever**
Game State & Data Structures
Physics
Events*
Process Manager**
Command Interpreter***

*Send messages such as "time bomb created" so Game View can play a ticking sound and make a visual representation of it and so AI agents can run from it, etc **Processes are anything that needs to run every loop; this is essentially your Update() function (they are esentially threads, but in a cooperative multitasking environment rather than this mutex locking, time-wasting jazz) ***Takes the messages from the Game View and does something with them inside the Game Logic, like applying the E-Brake and then sending a message back to the Game View so it knows to lay down the rubber trails

---Game View (Human)---
Game display
^- the scene
^- GUI
^- FLIC anims
Audio
^- sfx
^- music
^- speech
Input interpreter*
Process Manager** (yet again!)
Options

*Should be obvious what this does... **For button animations, little graphical tricks, anything that needs to have the equivalent of an Update() function

---Game View (AI agent)---
Stimulus interpreter
Decision system
Process Manager
Options

Rather self-explanatory

In addition, you may have a "Remote Game View" derived class that gets messages from a server game logic instead of a local game logic. If you need me to explain that in detail, ask me to.

That's the basic setup, here's the execution of it.

//entry point for the file
GameAppLayer g_app;

int main(int argc, char *argv[])
{
    if (g_app.Init())
    {
        g_app.Run();
    }
    g_app.Deinit();
    return g_app.GetExitCode();
}

There's a ton more to this architecture, but I'm not about to type up 900 pages.

Edit: Corrected.

There's probably a few things to comment about the above, but I'll keep it to one thing.

The above is basically a model-view-controller architecture, except that the controller and view are combined. One suggestion might be that splitting the view and controller could give some benefits. In the above, the "human view" I assume is responsible for all rendering (graphics and sound), but it also processes input. If the input processing is split from the view, you can have different implementations of the controller. This may be useful for demo playback, or for spectating in an online game (where the input comes from a remote player).

Beyond the common mistakes, such as loading data while in your game loop, allocating and deallocating memory frequently, adding/removing items from vectors or using large linked lists, there are a few things you need to watch out for when coding with Allegro:

1. If you're doing more than one blit to video bitmaps per frame, including the screen, you have to lock that bitmap first before you draw to it using the acquire commands, then unlock with the release commands. (Doesn't apply for blitting video bitmaps to video bitmaps.) If you don't, locks are engaged and disengaged for every draw you make to a video bitmap, causing an enormous amount of slowdown. If you only ever draw to the screen or a video bitmap once every frame then there's nothing to worry about.

2. If you're working in 8-bit colour, be careful when you call the palette setting commands as some of them request a vsync() operation first, thus if you call those commands more than once in a frame you'll kill your framerate. (And you should thus never call more than one palette command which will vsync() per frame and you should always call it right before blitting to the screen.) Also, palette altering and page flipping don't mix harmoniously as both of them request a vsync() operation.

3. Since Allegro does not take advantage of hardware acceleration (excepting video to video blits) 32-bit colour will run nearly twice as slow as 16-bit colour. If you're working in 32-bit, trying scaling down to 16-bit.

4. If you run your program in a window, try not to run a 16-bit application with a 32-bit desktop or vice versa as you'll get some additional slowdown. (The amount of which will vary depending on how good your video card is.) 15-bit and 24-bit are very strange to work with anymore and you should avoid them. 8-bit should run fine in a window at any bit-depth desktop.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Controllers ought to be abstracted so the game view can't even tell what kind of controller the player is using. That allows for the different implementations.

The architecture already allows this, since input from remote players goes through the same channels as local players. Demo playback is essentially a dummy AI agent that sends messages from a game record file. As for spectating, you would just have to disallow input for the spectator and use the regular client game logic.

The only problem with Kibiz0r's main I see is that init usually allocates some memory such as creating buffers, ...

This way you can still call deinit to free any allocated memory.

Here is my typical app. main creates a buffer, loads a datafile, ...
I don't want to worry about freeing them in init if the something fails.

His run loop I don't like. What's up with the rest()?

Use Miran's. Do all logic, this might include multiple sets of logic.
Then draw the updated graphics once.

If you do it Miran's way, don't use a message system, because it will process all messages that have been queued up in multiple logic frames inside the equivalent of one logic frame.

I was told that rest(0) yields to other processes. We ought to not use the CPU as long as logic doesn't need to be updated, yeah?

Edit: Your code looks eerily similar to mine, it gave me chills, heh. Your loop, though... it will draw the current frame again if logic time == 0.

Edit 2:

Yeah, it's in the book that way, I don't know why I noobed it up.

15-bit IS 16-bit, it just uses a different color format (RGB-555 vs. RGB-565). It ignores one of the bits, but it's still there, and you could safely use it for storage if you wanted - just like 32-bit ignores a full byte. 24-bit is strange to work with if you need direct access to pixel data, otherwise it's exactly the same as 32-bit. And since some GFX cards prefer 24-bit over 32-bit (yes, some still do), I'd support it anyway, if only for the final display (leaving all sprites at 16 / 32). 15 <-> 16 and 24 <-> 32 conversions are relatively cheap.

But it also makes it a bit more difficult to make a good control scheme if you have to work on an abstracted layer with no assumptions about the control method (eg. using a keyboard will work differently than using a joystick, which will work differently than a gamepad, etc). Sure th ey can be abstracted to properly work on them all, but then the controls can't be as tailored to the control type the player is using, which can make things feel clunky.

rest(0) only yields the CPU, but returns ASAP. rest(1) will give away the CPU for at least 1 millisecond and return ASAP after that. The former will reduce CPU usage, while rest(0) takes full CPU usage.

I prefer the semaphore mechanism myself.
Literally the same thing as the tick variable but goes to sleep in the main loop if the value is 0. It will wake up when the value goes back up above 0.

There are various portable libraries, and standard OS implementations.

This is good stuff i think i am having the same problem. i do music and sound effects in the logic loop how much of a slow down are we talking about.
and for 32bit thingy are you talking about changing the graphics mode to 16 or the sprites?

What I meant to say was that the "Input Interpreter" ought to serve the same function and send the same messages regardless of the control scheme, but can have completely different ways of going about it, depending on what kind of input we're talking about.

For example, Up on a d-pad might only result in a message like Accelerate 100%, whereas on an analog stick, it could send anything from Accelerate 1% to Accelerate 100%.

As for clunkiness arising from supporting multiple methods of input... It's a problem that exists no matter what setup you use, really. As game designers, we try to set it up so that it feels right to us, but another player might have a completely different idea of what feels right. But that's the strength of this architecture: you can specialize the way input is interpreted for each device without changing the way the game itself is played.

I do have a question, though: Should dead zones be applied in the application layer, or the game view?
It alters the input itself, not how it is interpreted as a game command... yet, the amount of dead zone may have to do with personalized options, which are associated with the game view and really shouldn't be within a stone's throw of the application layer.