Game slower/faster on different computers

I built a game via unity 3.x. The game runs great in the editor and on some computers. However, on other computers the game runs either faster or slower. On one computer, which has multiple (and different nVidia cards) the game runs a different speed on each monitor (correct on one and fast on another).

What can I do to adjust the hardware (I assume it's a video card issue) so that the game plays back at the correct speed? I figure it's a timescale issue, but I don't know what's causing it to differ between machines.

Oh, and the issue still exists regardless of Windows XP and Windows 7 operating systems. And the game was built on a Mac.

 

You're not multiplying by deltaTime, as is required for any kind of predictable behavior.

http://unity3d.com/support/documentation/ScriptReference/index.Keeping_Track_of_Time.html

You really should read over everything on this page before trying to script anything. I never did any scripting before Unity, and that was all really helpful.

 

Since I'm already using deltaTime where applicable, switching some of my Updates to FixedUpdate seems to have nailed the problem almost completely. I still have a slight time issue, but I think it's something for which I can compensate.

Thanks Jessy. I've been working with Unity for a while, but mostly on portable devices where this hasn't been an issue.

 

If it's an issue on the desktop, it's an issue everywhere else. Mobile devices just don't have as wide a range of power. Moving non-physics things into FixedUpdate is a poor practice hack that is going to break everything if you rely on it. If FixedUpdate helped you, then it just means you need to work on your Update code, keeping it there, where it belongs, and actually making it framerate-independent.

 

I know its an old topic but I just looked for a solution myself and want to share what I found.

I had the same issue and it isn't specifically to do with deltaTime or Update().

In my game I want the game to slow down at lower framerates. Multiplying by deltaTime has the effect of 'jumping' things on the screen at lower framerates. For some games, its better to have it 'jump' frames rather than slow to a crawl. In my game, (a bullet-hell type), the slowdown is preferred. In which case, you don't want to multiply by deltaTime.

Anyhow, since i'm ok with my game running slower than the target 60fps, thereby simply slowing down Update() calls, I only had a problem when the framerate went above 60fps. In other words, if the game can slow down, it also can speed-up on higher refresh rate monitors. Which is definitely not good. So from there I looked at how to limit the framerate. There are some 'fixes' available but the easiest thing for me to do was just disable any of the lower quality settings in Project Settings > Quality Settings.

To see why, take a look at any quality setting below "good". It doesn't perform a Vsync on every frame! So, by removing these settings you force VSync which guarantees that your Update() waits, if needed, to sync with higher refresh rates. You probably will have to do some other tweaks in script to account for edge-cases but this is a good fix when testing builds on different platforms.

 

The deltaTime you multiply by doesn't have to be UnityEngine.Time.deltaTime. You still should be multiplying by a deltaTime so that your values make sense, and are universally tied together.

 

Hi Jessy,

UnityEngine.Time.deltaTime refers to the time between draw calls in the engine. Which other deltaTime could/should I use in its place (I wasn't aware of any other deltaTime I could be using)?

Thanks so much for your help!

 

I meant that you make your own. Something like this, perhaps.

Code (CSharp):

1. static class Time {
2.     static float? _deltaTime;
3.     public static float deltaTime {get {
4.         return _deltaTime ?? UnityEngine.Time.deltaTime;
5.     }}
6.     public static float? targetFrameRate {set {
7.         _deltaTime = value.HasValue ? 1 / value.Value : value;
8.     }}
9. }