Why does multiplying by what print(delta) spits out not work the same as just using *delta?

Archive
1
:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By denxi

I started my game using move_and_slide, but recently converted over to move_and_collide because I wanted to gather information in between collisions of a slide, and this was easier to do. I’m making a game that uses a replay system and requires frame perfect replication of the game, no matter what the computer specs/lag. I can get the new move_and_collide process in complete sync if I multiply the motion value by delta, the same as what move_and_slide does, but if I print out the delta value of the physics frames (0.016667) and multiply my motion by that, I get desync.

My two questions are:

  1. Can someone explain why exactly this desync would be occurring? What’s the difference between referencing delta, and just inputting the number, assuming delta is static.

  2. Does it even matter? Is it at all possible that relying on delta as a motion modifier could cause desync if there’s any cpu lag that causes a physics frame lag, or am I worried about it for nothing?

I think you should reconsider your approach. using the games delta should probably only be used for rendering, not for tracking your internal games state.

but to answer your question, I think if you Print() it will cause the frame to take a long time, which is probably why it desyncs.

Jason Swearingen | 2020-02-09 20:56

There’s nothing to reconsider, I’m not using delta anymore. I was just in the process of converting my motion values from move_and_slide to move_and_collide, and noticed the discrepancy and wanted to know what was up.

And it’s not print causing lag. I’m not even printing during running either of them, I just used print(delta) once to see what the physics delta was, then was using motion*0.016667 (that number being what print(delta) was showing).

I’m guessing the difference has something to do with rounding, but I don’t really know.

denxi | 2020-02-09 22:19

Why use delta for a recording?

Merlin1846 | 2020-02-10 15:14

Like I said, I’m not. I was initially because move_and_slide is automatically run using delta, and I didn’t know that when I first started. However, as I said, I’m now using move_and_collide, so delta isn’t relevant to my current code. I still have questions about the mechanics of it, however.

denxi | 2020-02-10 15:45

Need more info. Can you provide sample code? Not sure how you can multiply something that’s printed, except manually.

lucaslcode | 2020-02-10 20:59

That’s what I’m doing. Printing delta at 60 physics frames returns 0.016667. The following:

move_and_collide(motion*0.016667)

move_and_collide(motion/60)

move_and_collide(motion*delta)

provide different results. I’m just curious as to the exact mechanism behind why.

denxi | 2020-02-11 13:33

2
:bust_in_silhouette: Reply From: Jason Swearingen

see this: Reddit - Dive into anything

That guy also sees “weird” behavior when printing.

as I mentioned in my first comment, I firmly belive because calling Print() takes a LONG time, and doing it 60 times/sec is going to slow your game down.

slowing your game down means that it might be in the next physics frame before the Print() command is done, thus the desync.

Well, as I have said before in the comment thread, I am not printing during runtime. I printed ONCE, to get the number that the physics frames were using as delta at 60 fps, and then slotted that number into the equation. I still get desync without calling any prints.

Furthermore, I can run the print function as much and as randomly as I want DURING runtime, and as long as the replay was recorded with the same motion modifier as I play it back with, I get absolutely 0 desync. The print function is completely irrelevant to this inquiry.

denxi | 2020-02-11 22:34