Loop & managing states

Started by
1 comment, last by Red Ghost 15 years, 11 months ago
Hello, I'm new to this whole game programming thing -- but not new to programming. Basically I'm writting a little game in C, and I have a few questions that various books & tutorials I've read seem to miss. I'm managing internal engine states & looping as such, menu.h

extern struct menu_s
{
    int isAcitve;
} menu;
render.h

extern struct render_s
{
    int maxfps;
} render;
render.c

void render_frame(void)
{
    /* render everything */
    if(menu.isActive)
        menu_render();
}
think.c

/* physics, animation & such (update game states) */
void think_frame(float delta)
{
    /* ... */
    if(menu.isActive)
        menu_think(delta);
}
main.c

for(;;)
{
    sTime = timenow();

    think_frame(delta);

    if(should_render_for_maxfps(render.maxfps) == GL_TRUE)
    {
        render_frame();
    }

    delta = timenow() - sTime;
}
Basically my question is, can I merge 'thinking' & 'rendering' together? And should I be limiting the FPS of my think frames? (ie using 100% of the CPU because I can seems like a waste)? Since 'think' and 'render' are in different functions I also have to check the state of the menu each frame twice, seems like a waste -- could I do: render.c

void render_frame(float delta)
{
    menu_frame(delta);  /* does menu cals and renders? */
}
And then limit render_frame to maxFps? Thanks in advance :) I'd hate for my game to use 100% CPU if it didn't have to.
Advertisement
Are you using OpenGL? I dont know that much about OpenGL (so forgive me if i'm wrong) but I dont think it will be possible to get 100% CPU if you have a lot of rendering work to do. The pipeline will fill up after a few frames of draw calls and the CPU will stall until the GPU catches up anyway. I don't think you have to worry about it yet until you have a lot more done too as you may find later that you need that extra bit CPU for game AI etc, and may have to remove the CPU limiting code.
Hi,

Your question is just one of architecture. There are no definite answers as the most important question is to check where the bottleneck is.

Separating Think and Render functions:
- easier to maintain as you separate logic from rendering code
- the think function can even be in a separate thread
- eventhough some data may be checked twice, it is rarely where code bottlenecks are. Best is to profile your code with a debugger to see where there is the most performance hit.

Regarding limiting thinking to a maximum number of frames, it all depends on your game. A turn based game evaluates its thinking method once per round. A FPS game evaluates its thinking method many times per second. You might need to limit thinking evaluation:
- when it is computationally intensive and its results are not that different between two rendering frames.
- when you want the thinking evaluation to mimic that of a human player (to simulate longer reaction time for example).

IMHO, the best step is to write a workable program then profile to see where are the performance hits. Then you can take steps to improve your program.

Ghostly yours,
Red.
Ghostly yours,Red.

This topic is closed to new replies.

Advertisement