koobas.hobune.stream
Physics after build feel different vs In-Editor (Time.deltaTime)
Hey all so I ran into this issue here.
Here's a quick video to summarize it
Let me know if you need any more details.
Thanks for your help in advance!
@AlwaysSunny Hey could you help me with this? ^
~The guy you helped make the third person camera a while ago :)
I'm afraid I've had my own troubles getting the standalone builds to behave 1:1 to the Editor. I'm still on 4.x so it's a whole different problem, I'm sure.
It's a good idea to paste in your relevant code (was collapsed in video) - but given your normal experience in the Editor it's likely fine.
$$anonymous$$y first thought is to tinker with vsync and other project settings. I recall that certain features will (or used to) behave differently in the editor vs standalone, but I don't recall which / what / how.
Rule out your logic as the culprit first (paste & share if you're not positive), but either way that's an area worth studying: The differences between testing in the editor vs standalone builds.
I'm sorry I don't remember specifics or have a resource to share. $$anonymous$$y prior cursory investigations revealed that there are indeed discrepancies that may cause issues related to time. Whether such a discrepancy is the issue remains to be seen. Best,
@AlwaysSunny First off, thanks for responding! I really appreciate it. O$$anonymous$$, so I did some digging, and I set up the profiler to the standalone build. I managed to get something interesting.
That's a screenshot from what the profiler showed me.
Seems the big culprit is GFX.WaitForPresent
Any clue what that could mean?
As I understand it, WaitForPresent is like idling. If the CPU is working, but the GPU has finished, you get WaitForPresent. There's an Idle CPU / Busy GPU equivalent too that'll show up in the CPU graph. Basically it's what you get when the two devices have different workloads per frame.
This thread gets into it pretty deep if you want to explore. They discuss some valuable ideas, though I'd caution you that only half of them seem to know what they're talking about.
I think at best it's indirectly related to your problem, though. As someone pointed out, trying to "fix" WaitForPresent is like trying to alter a thermometer to control the heat.
Given this question hasn't got any traction, I'd consider rewriting it with a different title. The video still applies, of course, but you should try to briefly summarize it in text too - and share code. Even perfect questions will get ignored, but it's worth a shot.
Title it something like Game Performance Different In Standalone (Video Example). If you still don't get any help, maybe drop by the Unity IRC channel - I'm assu$$anonymous$$g there still is one - because the big dogs don't seem to cruise UA as often as they used to.
If this is using physics, you shouldn't really be using Update() as the physics don't update themselves every frame.
Have you tried porting the physics to FixedUpdate() with time.fixedDeltaTime ins$$anonymous$$d?
I'd like to thank both of you so much for all your help! I finally fixed it!
For anyone else suffering from these issues,
Use FixedUpdate() and Time.fixedDeltaTime for physics and movement!
These changed EVERYTHING!
I got 144fps both in the editor and on a standalone build.
The actual gameplay is now 1:1.
Originally, I didn't want to use FixedUpdate() that much because it looked like all the movement was jittery. Although I think Time.fixedDeltaTime was the trick to fix that.
I did tweak some project settings but to no avail. It was FixedUpdate() and Time.fixedDeltaTime that fixed everything!
Thanks for your help!
Aha! And that's why it's always a good idea to show your code. ;) You have stumbled upon the correct paradigm for managing physics-related activities: Get your input in Update and drive anything physics-related in FixedUpdate. Still not sure why it impacted framerate in the way it did, but I'm glad you got it sorted out!
$$anonymous$$e too! Yeah the fps issues didn't make any sense though :/
