Frame Time Question - ebiten.CurrentFPS() accurate?

[SolarLune]

Hello!

I'm sure questions regarding Ebiten's timing system have been asked many, many times before, but after seeing some odd FPS values when I've been testing my game, I have a question to ask.

It seems like ebiten.CurrentFPS() isn't always accurate (or perhaps ebiten isn't calling Game.Draw() all of the time and so the framerate is actually lower than it should be?). I'm not certain, but it feels like something is off between the actual FPS and TPS values, and the values returned from the ebiten.CurrentFPS() (and possibly ebiten.CurrentTPS()) functions. It's like the display framerate (FPS) is way lower than you would expect if Game.Update() (TPS) takes enough time.

Here's an example of the behavior I'm seeing in the form of a simple program.

package main

import (
	"fmt"
	"time"

	"github.com/hajimehoshi/ebiten/v2"
)

type Game struct{}

func (g *Game) Update() error {

	t := time.Now()
	time.Sleep(time.Millisecond * 16)
	fmt.Println("Update:", time.Since(t))

	fmt.Println("FPS: ", ebiten.CurrentFPS())
	fmt.Println("TPS: ", ebiten.CurrentTPS())

	return nil
}

func (g *Game) Draw(screen *ebiten.Image) {}

func (g *Game) Layout(w, h int) (int, int) {
	return 320, 240
}

func main() {

	game := &Game{}
	ebiten.SetFPSMode(ebiten.FPSModeVsyncOffMaximum)
	ebiten.SetMaxTPS(60)
	ebiten.RunGame(game)

}

With this simple example, I would expect that;

1. The game would take 16 milliseconds or thereabouts to call Game.Update(), leaving ebiten with not enough time to call Game.Draw().
2. This being the case, without VSync on, ebiten should still call Game.Draw() anyway, as often as possible.
3. The framerate (as reported by ebiten.CurrentFPS()) should be below 60FPS, but without rendering anything, it should be close to the tickrate reported by ebiten.CurrentTPS() (with both values being within, say, 50-59 FPS).

However, instead I get this output:

Update: 16.161087ms
FPS:  20.321200180146473
TPS:  59.99592434138482

And can see that Game.Draw() is not being called sometimes.

This seems to mean that if a Game.Update() function takes enough time, FPS plummets, despite VSync being disabled. This is odd, since Game.Draw() should be able to be called after Game.Update() whenever possible, essentially, and with an empty Game.Draw() function, CurrentFPS should be roughly the same as CurrentTPS.

Oddly, if I sleep for 17 milliseconds instead of 16, then FPS goes up:

Update: 17.135472ms
FPS:  25.947468467872863
TPS:  56.88483471802897

This makes me feel like there might be either a timing issue of some sort, or an issue with CurrentFPS() possibly not returning the correct values...?

EDIT: As an aside, I'm asking this because in my game, I'm seeing times where the FPS drops below the monitor's refresh rate while timing my game shows that the game's Update and Draw functions don't take up more time than is necessary to reach the target framerate. I chalked it up initially to "invisible time" spent flushing data to the graphics card when calling one of the Image.DrawTriangles() family of functions, but that doesn't quite make sense because I'm timing that process too, and that Draw functions have to be on the main thread, so there's nowhere that I can see for the time to "disappear".

[tinne26]

So, responding to your expectations:

1. Yes, the game takes 16ms to process each Update, but it will always call Draw after updates are done. See the GLFW main loop function at ui/context#L107. There's no conditional to call Draw, no additional timing check there. After updating, Ebiten always makes the game draw.
2. I don't understand. This being the case? What being the case? When FPSMode is FPSModeVsyncOffMaximum, the only difference is (as far as I understand) that draws / buffer swaps won't block. If the game is taking too much time on Update, you can't call Draw faster anyway, as the calls are not done concurrently. And in fact, depending on the exact moment at which Update calls end, you may spend more or less time blocking to catch the next graphics buffer swap.
3. Whether Draw draws anything or not doesn't change when it is called (I mean, unless it is causing lag). It is called always after the Update calls. But notice that FPS don't have to be close to TPS because the number of updates, as can be seen in ui/context#L97, can be variable. In particular, multiple updates can be issued before a single draw. It's even possible that Update won't be called at all. I don't know if by "Game.Draw() is not being called sometimes" you meant this, that Update may be called multiple times consecutively first.

Finally, about FPS going up despite updates taking more time...

• What I already mentioned about draws blocking can cause this kind of weird variations if VSync is active and update takes too long. The time you may spend blocking can be highly variable depending on when updates end.
• Even with VSync off, these variations are also possible. That's because the number of times that update will be called is not based exclusively on time elapsed. Initially, it is, but there are a few heuristics and conditional compensations in case everything is lagging too much. See clock/calcCountFromTPS. Whether these heuristics and conditionals are great at their job or not, I can't guarantee as I haven't studied them in depth.

[tinne26]

About the last point: yes, you are mostly right, but what I mention is a separate issue (and FPS may fall more or less than halving, depending on how many updates end up packing in a single updateFrameImpl). Say you have 16ms to execute update and draw. If you do it in 10ms, the buffer swap will block for another 6ms. If you do it in 17ms, you may have to wait an extra 15ms. But when you combine long updates and maybe multiple updates at once, the time you end up blocking can be highly variable and become larger or smaller in cycles. When you also factor in TPS timing corrections, it's very hard to predict what will happen. So, my point was that you can keep increasing the time that it takes to run a single update, but FPS and TPS won't change linearly; therefore, depending on the instant at which you are observing, you may see strange behavior.

[SolarLune]

I see, yeah - depending on when the time falls and how long the Update() is, Draw() can be pushed later and later.

That explains the FPS rising or falling depending on the delay I pass.

[tinne26]

Also, Ebiten prioritizes Update over Draw, quite heavily. You would have to modify the heuristics and conditional corrections from the previously linked clock file if you wanted to do it differently. Which could be reasonable too, there are many ways it could be done.

[hajimehoshi]

Assuming your question have already been answered,

1. There is no guarantee in FPS/TPS when Update takes longer than expected (the set max TPS)
2. Leaving Update and putting everything in Draw might be a good idea if you wan to rely only on the monitor's refresh rate. However, in the future Ebiten, Update might take some arguments that Draw doesn't, like inputting. I have not decided anything about this.

[SolarLune]

OK, I think I see what you mean - having the option to either use Update() or Draw() as necessary seems like a good thing to keep in mind for timing-heavy games. Thank you all for your input!