@normalized I appreciate your effort.
4 Likes
I also appreciate your effort. That’s a great visualization and it helps a ton.
Does that mean though that it’s impossible to return real timestamps at consistent rates, or to return timestamps of events that happen between frames?
For example, if a stopwatch measures the lap time of a car being simulated in _physics_process() and the car “crosses” over the finish line at a time between frames, is there anyway to return an exact timestamp (millisecond precision) of when that event happened? Would you just have to manually interpolate it at that point?
1 Like
Why do you need realtime timestamps? Your _physics_process() is a simulation step. For consistent timing inside the simulation - use the provided delta. You don’t need to mess with the real time there.
The real question is do you really need to run the physics simulation 4 times the rate of the rendered frames. What’s gained from that?
2 Likes
You’d store the usec time at race start. Then when the player crosses the finish line, you’d subtract the first time from the new time and get your time. _physics_process() would never be involved. Because you don’t need to monitor if the player has crossed the finish line every frame.
But the better way to do it would be to start a Timer at race start for say 5 minutes. If the Timer expires, the race is over and the player loses. Otherwise the Timer is stopped when the player crosses the finish line, and you use that for the time. If you want a clock on screen, you pull the running time from the Timer - and you’d put that in _process() for the Label, not in _physics_process().
Note that the granularity of both - Timer and _process() is equal to the granularity of rendered frames. If you want to measure time with the higher granularity by running the physics ticks at the higher rate, you’ll need to use delta in _physics_process().
Your cars move in the simulation time, not in real time. They integrate their position based on simulation delta, not on real time timestamps. So if a car reaches the finish line in a 2nd physics tick inside the frame, you can detect that in _physics_process() and react accordingly. You don’t need or want real time for that. Just note that your reaction can’t become visible before the pending frame is displayed.
1 Like
Sorry, I just brought up real timestamps as a way to understand if information could be obtained between frames, not so much to ask if they’re purposeful.
Also, I agree that such a high physics rate is irrelevant for any kind of game I’m going to make in Godot. If I can lower the physics rate and still get very precise (or interpolated) values then that would open up a lot of doors.
It’s my understanding based on the link paintsimmon provided that _physics_process() handles interpolation between frames, but if there’s no way to actually store the interpolated information (like a laptime) then I’m stuck with laptimes of either 1:00.013 or 1:00.026.
Checking the car’s position at each frame or even each physics tick might only amount to a ±10 ms difference in laptime but for a skill-based game it can be fun to see tiny incremental progression.
It does but from where would you access the interpolated values? Interpolation is really useful only when the physics tick rate is lower than the frame rate, so you can use the interpolated values in the code that runs on per-frame basis, i.e. in _process(). You have no other place to run some code that may fall in-between physics ticks as _physics_process() runs on tick.
If you want to test if some condition was satisfied between ticks you’ll have to devise your own test which will depend on what you’re testing.
As a simple example here’s how you can determine exactly when an uniformly changing value reached zero:
var time := 0.0
var velocity := 9.23
var position := -3.0
var position_previous: float
func _physics_process(delta):
position_previous = position
time += delta
position += velocity * delta
print("time = %f, position = %f"%[time, position])
if position >= 0.0:
set_physics_process(false)
var frame_time_zero = time - inverse_lerp(position, position_previous, 0.0) * delta
print("-> Zero reached exactly at: %f"%frame_time_zero)
time = 0.033333, position = -2.692333
time = 0.066667, position = -2.384667
time = 0.100000, position = -2.077000
time = 0.133333, position = -1.769333
time = 0.166667, position = -1.461667
time = 0.200000, position = -1.154000
time = 0.233333, position = -0.846333
time = 0.266667, position = -0.538667
time = 0.300000, position = -0.231000
time = 0.333333, position = 0.076667
-> Zero reached exactly at: 0.325027
4 Likes
Okay, that makes sense. That’s sort of what I was anticipating based on what you’d said earlier so it’s good to know and to have an example.
Thanks again for your help (and everybody else’s as well) and for the detailed explanations and examples. All of this information will be well-used and cherished. 
4 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.