Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About nucky9

  • Rank

Personal Information

  • Interests
  1. nucky9

    Fixing your Timestep and evaluating Godot

    No, my latest example works very well. There are definitely problems when using an unadjusted deltaTime in update though. Even Unity's own tutorial projects suffer from it, and it is especially bad if Vsync is turned on. Thanks for the links lawnjelly! Lots to consider in them.
  2. nucky9

    Fixing your Timestep and evaluating Godot

    Haha, sorry about that! This issue (the Unity deltaTime issue) has been driving me crazy for a few days, and I could only find people reporting the problem, not offering any solutions. I saw this blog, and got excited... I'm actually new to the site and didn't realize posting to the forum would make sense in this case. But again, thanks all for the help! Actually I think your explanation was good. I did try to do as you are saying (using both your snippets and the ref #3), and had something like this (although this is a bit cleaner then it was I think): using UnityEngine; public class CameraController : MonoBehaviour { double accumulator; float dt; float speed = -3f; double currentTime; Vector3 oldPosition; Vector3 newPosition; Vector3 direction; void Start() { direction = new Vector3(1, 0, 0); dt = 1f / 60; oldPosition = transform.position; newPosition = transform.position; currentTime = Time.time; } void Update() { double frameTime = Time.time - currentTime; currentTime = Time.time; accumulator += frameTime; while (accumulator >= dt) { oldPosition = newPosition; newPosition += direction * dt * -speed; accumulator -= dt; } double fractionalFrame = accumulator / dt; transform.position = oldPosition + ((newPosition - oldPosition) * (float)(fractionalFrame)); } } However, when I tested it in the editor, it was/is just as bad as using transform.position += direction * Time.deltaTime * speed in Update(). I should have tried testing a build, since it is much better there. Anyway, the combination of it apparently not working, and a lot of frustration resulted in me boiling down the parts I felt most sure of. I think I locked the framerate in to screen refresh as a troubleshooting measure originally (to see if I could get things smoother by going to the 'old ways'), but forgot about the downside, heh. Yeah, Unity's Update() deltaTime is broken, which causes major jitter if using it (and I think Godot has the same issue). I thought your post was an attempt to fix that issue (or maybe I just wanted to believe that!), but I guess it was more around how to implement your own timekeeping independent of the engine. Of course, doing so does solve the Unity issue as well, but it can also be solved by using a fixed tick that is = 1 / 60 (i.e. a multiple of typical FPS as you say), which is what Update()'s deltaTime should give when vsync is on, and the game logic isn't causing things to chug.
  3. nucky9

    Fixing your Timestep and evaluating Godot

    This is much better, thanks! I can still see some small jitters occasionally though (usually about one loop out of three or four has some rough frames). I'm not sure if that is a Unity problem or a Windows problem, but anyway, it is much better, and would definitely be an improvement over what I had previously. From reading the thread I posted, using your own clock as you are and Mussi suggested seems to be the best solution, given Unity's timekeeping problems. Thanks again for all the help!
  4. nucky9

    Fixing your Timestep and evaluating Godot

    In that example I wasn't updating targetPosition, because I was just doing one pass of the background with the camera as a test case. In my actual game, I wasn't using Lerp, because everything is moving at deltaTime * speed in one direction (it is an endless runner). I could use Lerp, but as I said it doesn't seem to make a difference. The deltaTime issue is discussed here: https://forum.unity.com/threads/time-deltatime-not-constant-vsync-camerafollow-and-jitter.430339/ so yeah it seems like it isn't good to use when vysnc is on, and simply turning vsync off isn't much of a fix. But if you ignore this issue, are you still saying that deltaTime shouldn't be used? I don't really understand that then, since isn't that the point of it (assuming vsync is on, and it is locked to screen refresh)? Certainly all the unity examples use deltaTime this way. My understanding of lawnjelly's post was that it was trying to fix this issue. Anyway, all that said I do find things improve when I used the suggestion to manually set the deltaTime intervals using Time.captureFramerate = 1 / 60, so using a fixed update does help as you and Septopus suggest.
  5. nucky9

    Fixing your Timestep and evaluating Godot

    First, I want to thank you for taking so much time to help we with this, I really appreciate it! Unfortunately though, I don't see the sphere as being smooth, and in fact is quite rough. I built it and posted it to itch.io: https://nucky9.itch.io/spheretest?secret=shdJdxrMEmjcBoatbSNoCs2ZU. A few others I had test it can see it too on other computers as well, although some people find it easier to spot than others. For me it looks very jittery. It also looks jittery in the Unity player. If it is smooth for you, I wonder if it is something in your player/build settings, or version that is different from me? I am using 2018.3.0f2.
  6. nucky9

    Fixing your Timestep and evaluating Godot

    No that still doesn't help . I think the problem is when you simply scroll over a linear background, it is quite obvious when the refresh and the transforms aren't synchronized, as discussed in the article. where there are many complex shapes moving simultaneously in many directions, which makes it much harder to pick out. Unfortunately, the game I am making is pure 2d, so this is a big issue.
  7. nucky9

    Fixing your Timestep and evaluating Godot

    I tried Lerping before, but maybe I'm not using it the way you are. Here is what I am currently doing in a simple scene, where all I move is the camera, and have a static 2d background image that is panned over: void Start() { startTime = Time.time; distance = Vector2.Distance(transform.position, targetPosition); timeToComplete = Mathf.Abs(distance / speed); startPosition = transform.position; } void FixedUpdate() { float timeComplete = Time.time - startTime; percentComplete = timeComplete / timeToComplete; transform.position = Vector2.Lerp(startPosition, targetPosition, percentComplete); } The background image still appears to jitter slightly as the camera moves.
  8. nucky9

    Fixing your Timestep and evaluating Godot

    The jitter in both Godot and Unity has been driving me crazy, and this is the first article I have seen that tries to address the problem directly. In my Unity game, everything is being moved by adjusting the transform.positions by a factor of time and speed: void Update() { transform.position += direction * Time.deltaTime * speed; } This leads to some noticeable sprite jitter. So, I tried to implement the interpolation system you described, but it didn't make any difference. Here is what I did: void Start() { Application.targetFrameRate = Screen.currentResolution.refreshRate; timePerFrame = 1f / Screen.currentResolution.refreshRate; direction = new Vector3(1, 0, 0); } void Update() { float timeLeftOver = Time.time % timePerFrame; float fractionalFrame = timeLeftOver / timePerFrame; newPosition += direction * Time.deltaTime * speed; Vector3 interpolatedPosition = oldPosition + ((newPosition - oldPosition) * fractionalFrame); transform.position = interpolatedPosition; oldPosition = newPosition; } Could you give any insight into why this doesn't work and/or how you would fix the jitter in Unity when moving 2D objects by position?
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!