Fixing my timestep using PIXI.Ticker

[Dharwin]

Hi all,

I'm currently working on fixing my timestep in my Pixi application. So far, I've been using a single PIXI.Ticker, which came with the PIXI.Application. In the tick method, I am stepping my game logic. Since the PIXI.Application ticker is also used for rendering, I am essentially coupling my render and logic time steps, as I understand it.

In the infamous Gaffer on Games timestep article, they end up with a single game loop that contains the render and logic updates. The loop is at the bottom of this post for reference.

My question is this: Can I use two PIXI.Ticker instances to achieve the same result? I am thinking about keeping the PIXI.Application ticker for the render loop, and creating a second PIXI.Ticker instance where I attach my game logic update.

This feels like it should work, but I can't tell if I'm missing something or not. It's effectively two loops running at different tick rates, which ultimately seems to be the goal... But wondering if I'll get myself into trouble with this approach. In the Gaffer on Games loop example, it seems very intentional when multiple simulation ticks occur for a single frame. In the case of multiple PIXI tickers, it's less coupled, since it's just two timers. Is that bad?

Thanks for any help!

 

Reference loop from Gaffer on Games:

    double t = 0.0;
    const double dt = 0.01;

    double currentTime = hires_time_in_seconds();
    double accumulator = 0.0;

    while ( !quit )
    {
        double newTime = hires_time_in_seconds();
        double frameTime = newTime - currentTime;
        currentTime = newTime;

        accumulator += frameTime;

        while ( accumulator >= dt )
        {
            integrate( state, t, dt );
            accumulator -= dt;
            t += dt;
        }

        render( state );
    }

 

[ivan.popelyshev]

> So far, I've been using a single PIXI.Ticker, which came with the PIXI.Application

Clone the application, make your own. Change ticker to something else if you don't like it.

Yes, you can use two tickers, but there's no guarantee which one wilnl be executed first in the frame.

That article supposed to be introduction to v5 app: https://github.com/pixijs/pixi.js/wiki/v5-Custom-Application-GameLoop , however "InteractionManager" is stil inside renderer, those changes weren't accepted by the team. 

[Dharwin]

Quote

Yes, you can use two tickers, but there's no guarantee which one wilnl be executed first in the frame.

I couldn't put my finger on why the two ticker approach felt weird, but this is exactly it. I cannot guarantee execution order.

The new method I have in place is an effort to re-use as much of PIXI.Application and PIXI.Ticker as I can.

The changes I made are:

1) On PIXI.Application, set autoStart to false. The PIXI.Application ticker never actually gets used or started. This also means that the pixi renderer never gets render() called.

2) When the game starts, I create a new PIXI.Ticker instance called gameLoopTicker. I add my own tick function to it.

3) In the tick function, I do the following:

  private timeMs = 0;
  private readonly dtMs = (1000 / 60); // Game logic delta time (60hz)
  private dtAccumulatorMs = 0;

  private tickGame = (deltaTime: number) => {
    // elapsedMS is the ms between the last loop and this loop.
    const { elapsedMS } = this.pixiApp.ticker;
    this.dtAccumulatorMs += elapsedMS;

    while (this.dtAccumulatorMs >= this.dtMs) {
      this.gameSystems.update(this.dtMs);
      this.dtAccumulatorMs -= this.dtMs;

      this.timeMs += this.dtMs;
    }

    this.pixiApp.render();
  };

Since ticker uses RAF under the hood and does some basic utilities around that, I figured I could re-use it. This is essentially a RAF loop that mirrors the article example.

It seems to be working so far, hopefully it continues that way. Please let me know if anything looks incorrect.

Thanks for the help!

[ivan.popelyshev]

Good job! 

Now get rid off pixi Application class. Its supposed to be mashup for hello-world applications  Its just the Stage+ticker+renderer combo.

[Dharwin]

I think I will. I need to clean up some of my initialization code before I can do that though. I really just need the renderer and stage, which is small.

I'm also considering replacing the pixi application class with Smoothie. In my current code, if I tick my game loop at less than 60hz, it looks pretty choppy. I like Smoothie's idea of doing interpolation in the render loop.

[ivan.popelyshev]

> if I tick my game loop at less than 60hz, it looks pretty choppy. I like Smoothie's idea of doing interpolation in the render loop.
 

What do you mean by that? You can add your interpolation to pixi ticker too.

[Dharwin]

I wrote game loop, but meant game logic loop. If I set the tick rate of the logic loop to something low, then things look choppy, even with 60hz rendering. That's because I do my interpolation in my game logic loop, not in my render loop. I could move that interpolation to the render loop, but I currently have the interpolation happening in my ECS system, which steps in its entirety during the game logic tick.

I switched to Smoothie, since that handles interpolation in the render loop. The code for the fixed tinestep on the logic loop looked really similar to mine, so I just switched to using theirs.

The result works pretty well. Even when I update my ECS at 10hz, the rendering looks pretty smooth.

Hopefully that makes sense. My interpolation was in my logic loop, not the render loop before, and Smoothie helped me move interpolation to the render loop instead of me doing that myself.

[ivan.popelyshev]

if (time_to_update) {
 UPDATE_THINGS
}

interpolate()
render()

 

[ivan.popelyshev]

All in the same ticker.

I also recommend to add setInterval() that takes care of long updates if user switched the tab. Otherwise your delta will be too high after he switches back

[Dharwin]

Thanks for the tips. Smoothie effectively implements the interpolate function for me, which saves me some time. I'll write my own down the road if Smoothie no longer does what I need.

I'll see about doing the setInterval. Thanks.