summaryrefslogtreecommitdiff
path: root/m4
diff options
context:
space:
mode:
authorVito Caputo <vcaputo@pengaru.com>2023-08-29 13:38:21 -0700
committerVito Caputo <vcaputo@pengaru.com>2023-08-29 13:41:35 -0700
commit64e4cd08b56866ab64da4ab0be158155747243ec (patch)
tree43a9678bf8e205d47364535a4c8305923ad9f611 /m4
parent25ae095b243cd2fc221200944c0fbcf9cc9429b4 (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 'm4')
0 files changed, 0 insertions, 0 deletions
© All Rights Reserved