Sprite Jitter
by Justin Proffitt · in Torque Game Builder · 04/16/2009 (4:56 pm) · 5 replies
I am fairly new to TGB (still using the trial version) and I appear to have come across a problem that cannot be fixed by playing with values in my scripts. I've created a small space environment in which you control a ship (using the ship image provided with the trial), and I've set my camera to follow the ship (with no offset) by changing its position to that of the ship every millisecond. Where I run across a problem is when I begin moving the ship, it takes on a jitter in the direction of its velocity which becomes worse as the velocity increases. I know it is the ship sprite which is shaking and not the camera because a parallax background of stars follows the ship as well, with no jitter what so ever.
I have tried everything I could think of to solve or even determine the exact nature of the problem, but nothing has been successful. I would be happy to provide any more information you all need, I just want to figure this out so I can move onto other things in Torque.
Edit: I have determined the nature of the problem, but not a solution; the sprite is not jittering, it's the camera and the background. These use the line %this.setPosition($player.getPosition()); to follow the ship ($player) every millisecond. So now I am wondering how I can build it so that both the background and the camera follow the ship without any of the three taking on that annoying jitter.
Edit2: Fixed! It might be worthy to note that using getposition to update the position of something can become quite inaccurate at any speed.
I have tried everything I could think of to solve or even determine the exact nature of the problem, but nothing has been successful. I would be happy to provide any more information you all need, I just want to figure this out so I can move onto other things in Torque.
Edit: I have determined the nature of the problem, but not a solution; the sprite is not jittering, it's the camera and the background. These use the line %this.setPosition($player.getPosition()); to follow the ship ($player) every millisecond. So now I am wondering how I can build it so that both the background and the camera follow the ship without any of the three taking on that annoying jitter.
Edit2: Fixed! It might be worthy to note that using getposition to update the position of something can become quite inaccurate at any speed.
About the author
I am a college student majoring in physics. As it so happens I like programming, a hobby which extends my profession in web design.
#2
The camera behavior script can follow the object in only the x or y or both at the same time. The script has no jittering issues whatsoever.
Here is the location of the script files:
http://www.gfx-null.com/behaviors/heal_camera_behaviors.zip
Also, if you are interested in further platformer behaviors I recommend downloading this too:
http://www.gfx-null.com/behaviors/platformer_behaviors.zip
I hope this helps,
Aaron
05/24/2009 (12:43 pm)
Hey, I recommend y'all take a look at my camera behavior script.The camera behavior script can follow the object in only the x or y or both at the same time. The script has no jittering issues whatsoever.
Here is the location of the script files:
http://www.gfx-null.com/behaviors/heal_camera_behaviors.zip
Also, if you are interested in further platformer behaviors I recommend downloading this too:
http://www.gfx-null.com/behaviors/platformer_behaviors.zip
I hope this helps,
Aaron
#3
The reason for this is that the simulation doesn't recalculate every object every frame as the frame-rate itself is different on different computers and is constantly varying. This leads to poor consistency across computers and inaccuracy of the simulation itself.
What happens then (under the hood) is that the simulation updates at a fixed-interval independent of the frame-rate. This is the scene-update. In-between these updates (each frame) the simulation interpolates from the last-position to the new-position. This gives an extremely smooth movement, more smooth on higher frame-rates (as expected).
The problem then happens when an objects position is changed explicitly via the scripts. The only thing the simulation can easily do is move the object immediately to the new position. If the user does this each frame (or simply at a high frequency) then the object is constantly "jumping" to the new position and doesn't interpolate. If you are indeed doing this each frame then the movement will only be as smooth as the frame-rate at that point.
This is why you should try to not constantly set the objects position but instead update its velocity either directly or by applying a force. In this way, the simulation itself updates the position appropriately.
This "jittery" movement caused by setting the position directly at high frequency is very obvious when you attach the camera to the object as the whole frame will appear to jittery.
It would be possible to change the simulation to interpolate to the new position specified by the user but it'd have to make a decision on whether to jump straight to it or interpolate to that new position. Interpolating long distances looks extremely odd. The threshold for this would be dependent upon what the user wanted and couldn't easily be automagically determined. It's okay adding this as a feature, it's quite another trying to explain how to use it. ;)
Hope this helps a little,
Melv.
05/25/2009 (6:29 am)
The problem here is that you shouldn't be setting the position of an object directly if it can be helped. You certainly shouldn't be (trying) to set it 1000 times a second.The reason for this is that the simulation doesn't recalculate every object every frame as the frame-rate itself is different on different computers and is constantly varying. This leads to poor consistency across computers and inaccuracy of the simulation itself.
What happens then (under the hood) is that the simulation updates at a fixed-interval independent of the frame-rate. This is the scene-update. In-between these updates (each frame) the simulation interpolates from the last-position to the new-position. This gives an extremely smooth movement, more smooth on higher frame-rates (as expected).
The problem then happens when an objects position is changed explicitly via the scripts. The only thing the simulation can easily do is move the object immediately to the new position. If the user does this each frame (or simply at a high frequency) then the object is constantly "jumping" to the new position and doesn't interpolate. If you are indeed doing this each frame then the movement will only be as smooth as the frame-rate at that point.
This is why you should try to not constantly set the objects position but instead update its velocity either directly or by applying a force. In this way, the simulation itself updates the position appropriately.
This "jittery" movement caused by setting the position directly at high frequency is very obvious when you attach the camera to the object as the whole frame will appear to jittery.
It would be possible to change the simulation to interpolate to the new position specified by the user but it'd have to make a decision on whether to jump straight to it or interpolate to that new position. Interpolating long distances looks extremely odd. The threshold for this would be dependent upon what the user wanted and couldn't easily be automagically determined. It's okay adding this as a feature, it's quite another trying to explain how to use it. ;)
Hope this helps a little,
Melv.
#4
I had come to the conclusion that it had something to do with making it set it's position every millisecond, but had not quite put together why it would act that way besides it being a fault of the engine (which I'd doubt would have a problem that bad). I had fixed the problem long ago by having movement set the velocity of the camera as well, which as you said works much better and much more smoothly than resetting the position rapidly.
Now I do have a question: for the same reason should I be trying to avoid using schedule functions when possible? As it is I have an update function that checks for various things, then schedules to call itself again in 100 milliseconds.
05/28/2009 (2:05 pm)
Thank you for explaining this in detail. :)I had come to the conclusion that it had something to do with making it set it's position every millisecond, but had not quite put together why it would act that way besides it being a fault of the engine (which I'd doubt would have a problem that bad). I had fixed the problem long ago by having movement set the velocity of the camera as well, which as you said works much better and much more smoothly than resetting the position rapidly.
Now I do have a question: for the same reason should I be trying to avoid using schedule functions when possible? As it is I have an update function that checks for various things, then schedules to call itself again in 100 milliseconds.
#5
If you have hundreds of these things going or a bunch at high frequency and especially if they all land at the same time then you can see performance drops. Of course, bare-bones schedules don't take that much effort but it's generally the slow scripts called in the callbacks that do the "damage".
If you do have to have lots of schedules going, especially at higher frequencies then keep an eye on your frame-rate and try to tune-out large loops in the scripts in the callbacks.
It sounds like you're asking about a single schedule which won't affect anything but always remember that the engine is single-threaded so time spent in callbacks is subtracted from your frame-rate.
Melv.
05/29/2009 (12:49 am)
There's nothing wrong with using schedule at all, it's there to be used but like anything, it's easy to abuse it, especially from the scripts. Each schedule generates an event that is queued and dealt with when the specified period of time has elapsed (or to the closest time step).If you have hundreds of these things going or a bunch at high frequency and especially if they all land at the same time then you can see performance drops. Of course, bare-bones schedules don't take that much effort but it's generally the slow scripts called in the callbacks that do the "damage".
If you do have to have lots of schedules going, especially at higher frequencies then keep an eye on your frame-rate and try to tune-out large loops in the scripts in the callbacks.
It sounds like you're asking about a single schedule which won't affect anything but always remember that the engine is single-threaded so time spent in callbacks is subtracted from your frame-rate.
Melv.
Torque Owner Andrew "Blorf" Hume
MinMax Games