Inaccurate FPS capping + two solutions to fix it about the-powder-toy HOT 16 CLOSED

yeah the draw cap's not so important. Still, it looks like it should work correctly. Since this appears to be done (unless playtesting proves otherwise, I guess), I'm closing this now.

from the-powder-toy.

Does this look good? 2cb6b96

from the-powder-toy.

Does this look good? 2cb6b96

Looks right, except for two mistakes I noticed. On line 515 you put frameStart = std::max(frameStart, ...); but it needs to be frameStart = std::max(now, ...);, and on line 520 you forgot a * 0.95 in the computation of correctedFrameTimeAverage.

The first error means that if you do something laggy and drop to 10 FPS for a while, then clear the current save it’ll shoot up to 300 FPS or whatever according to your computer’s capabilities until it’s caught up on all the missing frames and then it’ll drop to 60 FPS again. By maxing with now instead of frameStart you keep it from holding a backlog of more than 1 frame.

The second error means that even if the FPS is stable and correct, it’ll display a completely incorrect FPS estimate that never rises, only falls, and keeps falling indefinitely, approaching zero.

Also, I like the change to use nanoseconds instead of milliseconds. Makes things a little nicer than dealing with casts/rounding between float and int.

from the-powder-toy.

Oh gosh, I accidentally hit the “close” button. Oops! Reopening now.

from the-powder-toy.

Neither of your observations is correct. frameStart is equal to now by the time the max-ing takes place, and the 0.95 is not needed because I converted the b * f - a * (1 - f)-type b * f + a * (1 - f)-type expression to a a + (b - a) * f-type one.

from the-powder-toy.

Might be a good idea to explain that with comments.

from the-powder-toy.

Oh, good point! In that case, both issues I mentioned are resolved, but if I’m not still misunderstanding things, then that raises a different issue. The computation of frameStartTimeBlock relies on frameStart equaling the time the frame started at, not now. Computing frameStartTimeBlock with now means that if every frame takes about 20 ms, which should result in 50 or so FPS, it’ll actually drop to exactly 30 FPS.

from the-powder-toy.

That is correct. I shot myself in the foot by reshuffling code to make way for the fpsLimit <= 2 (no limit) case. Will fix in a bit.

from the-powder-toy.

That said, somehow, it caps to 60, not 30.

from the-powder-toy.

That said, somehow, it caps to 60, not 30.

It’ll only cap to 30 if frames don’t fit in the 16 millisecond window. If they do fit, it’ll cap to 60 instead.

from the-powder-toy.

Just changing line 513 to use oldFrameStart instead of frameStart should do the trick, I believe.

from the-powder-toy.

Yeah that's what I'm doing, among other things.

from the-powder-toy.

Okay yeah I won't overcomplicate it. master...LBPHacker:The-Powder-Toy:better-fps-cap

from the-powder-toy.

I guess I should add that we don't care nearly as much about the "draw cap" (RPS cap? no idea) as the FPS cap. It's fine for it to be imprecise, it's only meant to give an FPS boost when you really need it.

from the-powder-toy.

Yeah github's issue-closing mechanics are not exactly intuitive.

from the-powder-toy.

Fixed by c6d6a7d.

from the-powder-toy.