diff options
author | Vito Caputo <vcaputo@pengaru.com> | 2023-08-29 13:38:21 -0700 |
---|---|---|
committer | Vito Caputo <vcaputo@pengaru.com> | 2023-08-29 13:41:35 -0700 |
commit | 64e4cd08b56866ab64da4ab0be158155747243ec (patch) | |
tree | 43a9678bf8e205d47364535a4c8305923ad9f611 /src/modules/ray/ray.c | |
parent | 25ae095b243cd2fc221200944c0fbcf9cc9429b4 (diff) |
main: prevent ticks from going backwards
Outside of overflow (which I'm ignoring for now) ticks shouldn't
go backwards. With the introduction of adding the frame-buffer
delays, which vary, there's the potential for the delay to go
from large to short in quick succession, to such a degree that
the next render's now+delay is in the past relative to the
previous now+delay.
For now this simple fix is to just track the last_ticks and
always use the maximum of the last_ticks and now+delay, ensuring
it never goes backwards.
This was making alphazed exit prematurely at spurious times by
sending the rocket_row into oblivion because (ticks - last_ticks)
was negative w/unsigned arithmetic. This will all get more work,
and maybe ticks should be allowed to go backwards actually, but
some things are assuming that's not the case as-is.
Regardless, it's not desirable for ticks to go backwards because
of the frame-buffer delay. In that case just chill on the ticks
advancement for a frame. This will need revisiting for sure, as
I don't think re-rendering the exact same tick as the last frame
is likely to be what's wanted either. Probably some little
advancement should still be performed...
Diffstat (limited to 'src/modules/ray/ray.c')
0 files changed, 0 insertions, 0 deletions