8.3 Timing your Loop - Subsection Order

[abreathingcorpse]

8.3 Timing your Loop - Subsection Order

[Penaz91]

Hello!

The Game loop section surely needs some refreshing, and some fresh eyes are definitely needed.

My idea was the following:

• Fixed timesteps are the most raw way of creating a game loop: you have no delta-time, thus if you run the game on a faster PC, it will run faster. Definitely not a good option for anything that is more than a simple experiment that will never leave the current PC.
• Variable Timesteps is a bit more advanced way of creating a game loop, you have a delta-time and you can use it to avoid having a game running faster or slower on different PCs. You have a way to reliably "convert" seconds into frames so to speak. This has an issue too: if (for some reason) the PC slows down by a lot, the simulation may "break", usually collision detection will, because the bigger the "slowdown" the higher dt is, and the higher dt is, the bigger is the distance covered by an object between two frames (so much so that it may be able to completely miss a wall or floor). This is a good and simple way to make your game loop work that works in around 80% of cases.
• Semi-fixed timesteps tries to be a somewhat naive approach where you hard-limit the delta-time to avoid "breaking collisions", but has the "spiral of death issue" where we make some assumptions that may not hold true. This may be a good loop that works in around 80% of cases too, it just covers a different "computer demographic" so to speak: it gives away some stability on one side to fix an issue on the other.
• Frame Limiting is a simpler and more brutal approach: we set a maximum framerate and try to stick with it. If the game can go faster, it won't (this way it doesn't become "too fast to play"). If the game goes slower (due to poor PC performance), we give up on the current frame in an effort to have a lighter load on the system (we "drop a frame"). This is the type of loop you should be looking for if you want to make something close to "commercial quality games".

I see "frame limiting" as a way of "thinking outside the box" and making a completely new way of managing the game loop (as in "we are not trying to save each single frame anymore"). A paradigm shift of sorts.

What are your thoughts about it?

As always, thank you for bringing these questions to my attention!

[abreathingcorpse]

Well, unlike you, I haven't done a Game so, I'm not sure how much I can bring to the table. However, I've heard before that the Game Programming Patterns is like a bible of sorts for Game Developers.

Which is why when I was left with the question: Which Game Loop should I pick for my Game? After reading the 8.3 Timing your Loop section, I decided to compare this section to the GPP's Game Loop.

GPP Section -> Penaz's Section
Run, run as fast as you can -> 8.3.2 Fixed Time Steps
Take a little nap -> 8.3.5 Frame Limiting
One small step, one giant step -> 8.3.3 Variable Time Steps
Play catch up -> 8.3.4 Semi-fixed Time Steps

I've compared all of the codes within the two books' Game Loop Section and I came to the conclusion that I'd like to use the Game Loop that you've described within your 8.3.4 Semi-fixed Time Steps section. I believe that your code doesn't require one to use the render(lag / MS_PER_UPDATE); hack that the GPP's Play catch up eventually needs to use.

I might be wrong here but, usually these books kinda save the best for last. So, maybe that's why I'm picking it.

[Penaz91]

Well, unlike you, I haven't done a Game so, I'm not sure how much I can bring to the table.

Considering that this project is aimed to be both a somewhat in-depth guide and an introduction to Game Dev, I believe firmly that an external point of view is invaluable.

However, I've heard before that the Game Programming Patterns is like a bible of sorts for Game Developers.

It is, and deserves the title indeed. It's an Amazing read.

I've compared all of the codes within the two books' Game Loop Section and I came to the conclusion that I'd like to use the Game Loop that you've described within your 8.3.4 Semi-fixed Time Steps section. I believe that your code doesn't require one to use the render(lag / MS_PER_UPDATE); hack that the GPP's Play catch up eventually needs to use.

I'm not sure if my code doesn't need the lag-correction that GPP uses, since it works in a bit of a different way but has more or less the same concept in mind. My hypothesis is that the min(dt, frametime) does what lag/MS_PER_UPDATE is trying to do, just in a different way.

While GPP tries to look-ahead and render using the lag variable to "predict" how the frame will look. In my case there is a kind of "forced synchronization" between the update and draw functions, to avoid having to mix "update logic" inside the "drawing logic". I don't remember how my code performs at all, to be honest!

[Penaz91]

I created some simple test code, maybe this can give a better insight. It needs pygame.

import pygame


class Game:
    framerate = 60
    running = True

    def __init__(self):
        pygame.display.init()
        self.screen = pygame.display.set_mode((800, 600), pygame.NOFRAME, 32)
        self.clock = pygame.time.Clock()
        self.circlepos = [0, 300]
        self.circlespeed = 1
        self.frametime = 1./self.framerate
        self.dt = 1./self.framerate

    def update(self, dt):
        if self.circlepos[0] <= 0:
            self.circlespeed = 1
        if self.circlepos[0] >= 800:
            self.circlespeed = -1
        self.circlepos[0] += self.circlespeed * dt

    def draw(self):
        self.screen.fill((0, 0, 0))
        pygame.draw.circle(self.screen, (255, 255, 255), self.circlepos, 20)
        pygame.display.flip()

    def run(self):
        while self.running:
            while (self.frametime > 0):
                dt = min(self.dt, self.frametime)
                self.update(dt)
                self.frametime -= dt
            self.draw()
            self.frametime = self.clock.tick()


if __name__ == '__main__':
    game = Game()
    game.run()

It has no event handling so it will need to be killed (either via CTRL-C or a kill command) to be closed.

[abreathingcorpse]

I'm not sure if my code doesn't need the lag-correction that GPP uses, since it works in a bit of a different way but has more or less the same concept in mind. My hypothesis is that the min(dt, frametime) does what lag/MS_PER_UPDATE is trying to do, just in a different way.

While GPP tries to look-ahead and render using the lag variable to "predict" how the frame will look. In my case there is a kind of "forced synchronization" between the update and draw functions, to avoid having to mix "update logic" inside the "drawing logic".

Exactly, that's what I noticed as well.
If we have a δt lag keeps up summing them until they get bigger to what you call dt. And then does th update() (which for some reason doesn't receive any arguments).
However, you do not carry this δt, but instead run a update(δt) BEFORE calling the draw() function.

Hope I made sense there.

[abreathingcorpse]

I noticed that you didn't use neither the end nor the begin get_system_time().
Is it me? Or does self.clock.tick() does this for you? I seem to recall this. That is:
self.frametime = self.clock.tick()
Is the same as:
frametime = end - begin;

[Penaz91]

I noticed that you didn't use neither the end nor the begin get_system_time(). Is it me? Or does self.clock.tick() does this for you? I seem to recall this. That is: self.frametime = self.clock.tick() Is the same as: frametime = end - begin;

Yes, I make use of the pygame.time.Clock() to keep time. In this case I use it without parameters to avoid pygame's internal frame-limiting.

[abreathingcorpse]

Understood, thank you very much.
By the whay, should I close this issue?

[Penaz91]

No worries, don't hesitate to ask any question that may come to mind!