0
\$\begingroup\$

Here is the main loop that I currently have (and it does work perfectly):

// in another header:

...
using i64u = unsigned long long;

...

// mainloop:
i64u lastTime = static_cast<const i64u>(SDL_GetPerformanceCounter());
double accumulator = 0.0;

double t = 0.0;
double dt = 1.0 / 30.0;

SDL_Event e;

while (IsRunning())
{
    bool bRet;

    bRet = SDL_PollEvent(&e) == SDL_TRUE;
    if (bRet)
    {
        if (SDL::ProcessMessages(e))
        {
        }
        else
        {
            IsRunning() = false;
            break;
        }
    }
    else
    {
    }

    bool render = false;

    const i64u now = static_cast<const i64u>(SDL_GetPerformanceCounter());
    const double frameTime = static_cast<const double>((now - lastTime) * 1000) / SDL_GetPerformanceFrequency();

    accumulator += (frameTime / 1000);

    while (accumulator >= dt)
    {
        if (bRet)
        {
            if (this->Game().Get()->InputDevice().Get()->ProcessMessages(e))
            {
            }
            else
            {
            }
        }
        else
        {
        }

        // side-note: should OnUpdate go here?
        // or remain outside of this loop and keep passing "frameTime"?

        t += dt;
        accumulator -= dt;

        render = true;
    }

    this->Game().Get()->OnUpdate(frameTime);

    lastTime = now;

    if (render == true)
    {
    }
    else
    {
    }

    this->Game().Get()->OnDraw();

    SDL::SwapWindow();
}

...
bool& <App>::IsRunning()
{
    return m_Running;
}

const bool <App>::IsRunning() const
{
    return m_Running;
}

My question is: How should (or rather, how does it normally tend to be implemented) a frame be determined?

For example, should lastTime be set after the OnDraw(), or should it be set before OnDraw() but AFTER the the logic and input has been determined (after OnUpdate())?

What truly constitutes "a frame"? In my mind, a frame would constitute as "everything being prepared in order to be drawn", which I think of as "get the input, calculate physics and other game logic data, and then once that "frame" is finished, draw the "frame" - though I'm not really sure how this is (or might) done in the real world.

Is there even "a right or wrong way" when implementing this kind of loop? I would imagine so.

What would y'all recommend?

(Also, ignore the trailing if statements; that's some stuff to help me keep track of what's going on.)

\$\endgroup\$
3
  • \$\begingroup\$ "How should a frame be determined?" and "and it does work perfectly" Why do you ask, you don't seem to be having any issue with the way you're doing things at the moment. \$\endgroup\$ Commented Jul 29, 2021 at 15:57
  • \$\begingroup\$ @Vaillancourt I was just wondering 'cause a lot of people like to do what I did (lastTime = now;) right after frameTime is calculated, while I did so after the game finished updating, and was curious whether there are any reasons why one way may or may not be any better than the other. I guess it doesn't matter too much since yeah I'm not having any issues with the code. \$\endgroup\$ Commented Jul 29, 2021 at 20:58
  • \$\begingroup\$ There is a classic way of implementing the game loop: this one gafferongames.com/post/fix_your_timestep and this one gameprogrammingpatterns.com/game-loop.html \$\endgroup\$ Commented Aug 30, 2021 at 19:47

2 Answers 2

Reset to default
1
\$\begingroup\$

Assuming that you want to measure how long it takes to do one iteration of your game loop: It doesn't really matter at which point of your game loop you measure performance. All that matters is that you accurately measure the time it took since the last execution of that line of code:

 now = TheMostAccurateTimeFunctionYouCanFind();
 secondsPerFrame = now - last;
 last = now;

This gives you a measurement of how long the last iteration of your game loop took. Take the inverse, and you got the infamous Frames Per Second number the players like to obsess about so much: The number of different pictures being displayed on the screen during one second of wall-clock time.

This is also the number you need as a delta-time value if your game uses a variable time-step (as yours seem to do, implied by you passing the frameTime to OnUpdate). The real-world time marches on regardless of if your game is busy with rendering or busy with updating. So both account for the time it took since the last update.

\$\endgroup\$
0
\$\begingroup\$

In my mind, a frame would constitute as "everything being prepared in order to be drawn", which I think of as "get the input, calculate physics and other game logic data, and then once that "frame" is finished, draw the "frame"

This sounds like a sensible definition. As long as you're consistent with this definition, and all parts of your game are written in agreement with this shared convention, you should be in good shape.

\$\endgroup\$

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.