1. Make sure the legacy `timestamp_until()` and `timestamp_since()` functions check for any type of invalid timestamp
2. Add a useful `isFinite()` function
3. A timestamp delta on an immediate timestamp is more properly the actual delta, rather than another immediate timestamp
Prior to the timer upgrade, all simulation timestamps shared identical timer and timestamp values for the duration of the frame, since they were only updated within the `game_set_frametime` function. Since the timer upgrade depends on the system clock, timestamps evaluated near the end of the frame will be very slightly later than timestamps evaluated near the beginning of the frame. It is desirable to keep them all in sync.
This PR tweaks the timestamp system to take a snapshot at the beginning of the frame, then use that snapshot for the entire duration of the frame. This only affects simulation timestamps; real-time timestamps still use the live timer.
* Revert "synchronize simulation timestamps across the entire frame"
* try a proper fix instead of revert
* make sure nothing is reverted
* and back to full revert
Originally the check for event delay was this:
```
if ( (fix) Mission_events[i].timestamp + delay >= Missiontime )
return SEXP_FALSE;
```
This returns false even when the mission time is equal to the timestamp. Therefore the timestamp check needs to use >, not >=.
Thanks to Durandal and ShivanSpS for helping to track this down.
Prior to the timer upgrade, all simulation timestamps shared identical timer and timestamp values for the duration of the frame, since they were only updated within the `game_set_frametime` function. Since the timer upgrade depends on the system clock, timestamps evaluated near the end of the frame will be very slightly later than timestamps evaluated near the beginning of the frame. It is desirable to keep them all in sync.
This PR tweaks the timestamp system to take a snapshot at the beginning of the frame, then use that snapshot for the entire duration of the frame. This only affects simulation timestamps; real-time timestamps still use the live timer.
For all POFs that use animated textures, if no starting timestamp is specified, assume animation started at the beginning of the mission. This fixes a bug reported in Starfox: Event Horizon where weapon POF animated textures stopped animating after the texture timestamp upgrade.
These fix up the in-game confirm packet and help sync client and server through a few timing fixes.
Co-Authored-By: Taylor Richards <[email protected]>
The movie player code was missing some important functionality, in particular:
1) There was only one timing method to get real-time elapsed time, which was not suitable for pausing or time compression
2) There was an improper cast for the FPS property, causing a script error
3) The `getSeconds` method lost precision during casting
This patches those deficiencies.
A bit overkill for some of this but just covering the bases.
* fix issues with in-game join
* fix multi messaging and multi pause screen
* make sure maintenance stuff (pings, voice, file xfer, etc.) isn't
affected by pausing or time compression
This adds a type-safe TIMESTAMP, similar to UI_TIMESTAMP. Eventually all of the FSO codebase will be switched over to this new type. In the meantime, just the supernova code is switched over.
If a breakpoint is hit in the code, the SDL time will keep running even though FSO doesn't realize things are effectively, if not actually, paused. Detect this situation and adjust the timestamp offset to compensate.
Previously, the game used a dead-reckoning system for measuring time, where several time counters were incremented as long as time was running. This unfortunately has no way to synchronize time in the long term, and therefore in-game time will tend to run faster or slower than real time by a few percent, depending on various factors.
This PR redesigns the timestamp system to use the SDL time counter which will always keep it in sync with real time. However this necessarily involves a bit of clever handling when the game is paused and unpaused. It also revealed several minor bugs in several places in the code where timestamps were handled.
This PR is currently in draft status until the design can be updated to handle time compression. In all other respects it should be working.
Goober5000