Sprite Movement Problem - Jitter
by Bruno Campolo · in Torque Game Builder · 02/22/2008 (7:40 am) · 15 replies
Hi I'm fairly new to TGB, but not to game development.
I am porting our breakout game from an old c++/directX engine to TGB 1.6.
I am having a problem where the ball does not smoothly move across the screen. It jitters slightly and sometimes more abruptly. I remember having similar problems in my old engine but then changed the timing/movement code and the problem was corrected. I'm not sure what TGB uses for its timing/movement methodology, but it seems that none of the objects on the screen move perfectly smooth. This is most noticable with the ball because it is small and moves quickly. I tried fullscreen vs window and D3D vs OpenGL, but no noticable improvements. I am getting between 100 and 200 fps so I don't think thats the problem.
Has anyone else encountered this issue with TGB and have a solution?
Thanks,
Bruno
I am porting our breakout game from an old c++/directX engine to TGB 1.6.
I am having a problem where the ball does not smoothly move across the screen. It jitters slightly and sometimes more abruptly. I remember having similar problems in my old engine but then changed the timing/movement code and the problem was corrected. I'm not sure what TGB uses for its timing/movement methodology, but it seems that none of the objects on the screen move perfectly smooth. This is most noticable with the ball because it is small and moves quickly. I tried fullscreen vs window and D3D vs OpenGL, but no noticable improvements. I am getting between 100 and 200 fps so I don't think thats the problem.
Has anyone else encountered this issue with TGB and have a solution?
Thanks,
Bruno
About the author
Creator of Bantam City Games, a one-man independent game development studio. To learn more, check out 'A Game Developer's Saga', a game development blog at: http://www.bantamcity.com/blog
#2
%this.setLinearVelocityX(%this.vx);
%this.setLinearVelocityY(%this.vy);
where %this is the ballClass in this case.
and I'm using the onCollision method for collisions detection.
Does this sound appropriate?
02/22/2008 (11:23 am)
Hi Dan, I am using:%this.setLinearVelocityX(%this.vx);
%this.setLinearVelocityY(%this.vy);
where %this is the ballClass in this case.
and I'm using the onCollision method for collisions detection.
Does this sound appropriate?
#3
02/22/2008 (11:28 am)
@Bruno - Yes, that sounds right. Some people try to control their movement by doing lots of setPosition calls, which can cause the symptom you describe. I'm not sure what else the problem might be.
#4
I started disabling certain enemies and other objects and I think I may have tracked down the problem, but I need advice on the best way to solve this.
I am doing enableUpdateCallback for every enemy (and there can be upto 80 on the screen at once). So I now realize that I shouldn't necessarily be doing this because the onUpdate callback gets called 32 times/sec * 80ish objects... yikes!
So any suggestions on a more efficient way to check the state of these objects? These objects sometimes need to change directions/states mid-stream and so I am checking for all the different things that can happen within the onUpdate call for these objects.
02/22/2008 (1:19 pm)
I just tried to run the BehaviorPlayground project because I remembered that it has a breakout type section with a ball moving at fast speeds. There is no jitter so that got me thinking it is definitely something in my project/scripts.I started disabling certain enemies and other objects and I think I may have tracked down the problem, but I need advice on the best way to solve this.
I am doing enableUpdateCallback for every enemy (and there can be upto 80 on the screen at once). So I now realize that I shouldn't necessarily be doing this because the onUpdate callback gets called 32 times/sec * 80ish objects... yikes!
So any suggestions on a more efficient way to check the state of these objects? These objects sometimes need to change directions/states mid-stream and so I am checking for all the different things that can happen within the onUpdate call for these objects.
#5
02/22/2008 (1:36 pm)
It might help if you described some of the effects you were trying to achieve, and what kind of constraints you're working with (e.g. is it important for every object to check every tick, or just every once in a while? Some but not others? etc.).
#6
I just have to get the right mentality of using TGB without exclusively using the onUpdate method.
Dan, Thanks for taking the time to read through all this :)
02/22/2008 (1:53 pm)
For this specific case the enemies are Space Invaders enemies proceeding across then down the screen in normal fashion. The problem is they are not supposed to move at a constant rate. They move for a second, then stop for a second, so you get the nostalgic Space Invaders marching movement. I am checking in the onUpdate function for how many "beats" have passed and then when they are moving I check to see how many "beats" they have moved. There are also other cases where when the bottom row of invaders is killed a new row swoops in from above.I just have to get the right mentality of using TGB without exclusively using the onUpdate method.
Dan, Thanks for taking the time to read through all this :)
#7
02/22/2008 (2:00 pm)
You may want to look into the schedule function. From what you describe, you may be able to think in terms of "after x milliseconds, do y" instead of "keep checking until you've passed n ticks, then do y". Depending on what you're doing, you may also be able to think in terms of world limits or collisions too, i.e. "do y when you hit this point on the screen" rather than in terms of time.
#8
02/22/2008 (2:28 pm)
Thanks for the tips Dan!
#9
Bit of a long read, but this is the first thing I thought of when I read you post.
02/23/2008 (11:37 am)
Check this thread out.Bit of a long read, but this is the first thing I thought of when I read you post.
#10
02/23/2008 (2:08 pm)
Thanks Kevin, it does sound like the same problem and it looks like Melv is still trying to figure it out so I guess I'll be patient :)
#11
Yes, interesting discussion about jittering, trembling, shaking....
I think "The Jitter Problem" will not be solved in extra long discussions with answers like "try this, try that...", "have you checked ...?",.. "blah....blah".
Strange sprite movement can be noticed on very simple TGB project with no extra scripting. It doesn't look like "classic" rough movement in 3D games because of lack of fps. Sprites just don't move at a constant rate as Bruno C. said. A lot of TGB game demos I've downloaded run very smooth or shaking isn't very noticeable. I don't know why. But as I tested, the problem can be very annoying in fast breakout/arkanoid style games.
So, people at GG, try with the very simple project. Put only a few objects on scenegraph: background tile, animated ball with constant X/Y velocity and some static non animated sprites. Run the project! Yes, it's running smooth on your graphic cards. On my GF 6600GT runs smooth too ;) and probably on every other machine armed with powerful graphic card. But what about other 90% computers with poorer 3D graphic cards or those with onboard graphics. That 90% computers is our selling market - we're not making top 3D games for gaming machines.
Can someone explain to me why a few years old machine with nv440-64M runs above test project only at about 50fps with terrible ball movement? Even new machine with onboard graphics runs 150+ fps and ball still shaking. On the other side, a few years old Macbook runs same project very smooth.
I wasn't concerned about the problem when I started with TGB. I thought I was doing something wrong or I just have to wait for a new TGB version. Which version ?
03/06/2008 (12:59 pm)
www.garagegames.com/mg/forums/result.thread.php?qt=64825Yes, interesting discussion about jittering, trembling, shaking....
I think "The Jitter Problem" will not be solved in extra long discussions with answers like "try this, try that...", "have you checked ...?",.. "blah....blah".
Strange sprite movement can be noticed on very simple TGB project with no extra scripting. It doesn't look like "classic" rough movement in 3D games because of lack of fps. Sprites just don't move at a constant rate as Bruno C. said. A lot of TGB game demos I've downloaded run very smooth or shaking isn't very noticeable. I don't know why. But as I tested, the problem can be very annoying in fast breakout/arkanoid style games.
So, people at GG, try with the very simple project. Put only a few objects on scenegraph: background tile, animated ball with constant X/Y velocity and some static non animated sprites. Run the project! Yes, it's running smooth on your graphic cards. On my GF 6600GT runs smooth too ;) and probably on every other machine armed with powerful graphic card. But what about other 90% computers with poorer 3D graphic cards or those with onboard graphics. That 90% computers is our selling market - we're not making top 3D games for gaming machines.
Can someone explain to me why a few years old machine with nv440-64M runs above test project only at about 50fps with terrible ball movement? Even new machine with onboard graphics runs 150+ fps and ball still shaking. On the other side, a few years old Macbook runs same project very smooth.
I wasn't concerned about the problem when I started with TGB. I thought I was doing something wrong or I just have to wait for a new TGB version. Which version ?
#12
05/21/2011 (9:34 am)
Not that this fixes the problem, but I noticed that when you run the game in fullscreen mode the performance seems to be a little better. Might want to try this and see if this is an option.
#13
Solution - Instead of using the OpenGL device as your display device use the D3D device.
This can be done by either:
1) Editing the defaultPrefs.cs file and changing:
// Default to OpenGL
$pref::Video::displayDevice = "OpenGL";
$pref::Video::preferOpenGL = 1;
to
$pref::Video::displayDevice = "D3D";
$pref::Video::preferOpenGL = 0;
OR
2) Calling the set display device command (ie setDisplayDevice("D3D"))
Also, you can call the following function to compare performance. You should see an increase in FPS
the function is: setDebugOn(0) - and setDebugOff(0) disables it. BTW, this function must be called from your t2dSceneGraph object. IE the call is actually $mySceneGraph.setDebugOn(0).
Cheers! Hope this will help you. =)
05/22/2011 (8:07 pm)
FOUND A FIX!!!!! Well, its not really a fix, but it is a performance enhancer, and will make the game run faster! And, the increased speed fixed my Jitters on my machine, hopefully it will do the same for yoursSolution - Instead of using the OpenGL device as your display device use the D3D device.
This can be done by either:
1) Editing the defaultPrefs.cs file and changing:
// Default to OpenGL
$pref::Video::displayDevice = "OpenGL";
$pref::Video::preferOpenGL = 1;
to
$pref::Video::displayDevice = "D3D";
$pref::Video::preferOpenGL = 0;
OR
2) Calling the set display device command (ie setDisplayDevice("D3D"))
Also, you can call the following function to compare performance. You should see an increase in FPS
the function is: setDebugOn(0) - and setDebugOff(0) disables it. BTW, this function must be called from your t2dSceneGraph object. IE the call is actually $mySceneGraph.setDebugOn(0).
Cheers! Hope this will help you. =)
#14
Canvas.setContent(mainScreenGui);
Canvas.setCursor(DefaultCursor);
// ADD THIS
mainScreenGui.addGuiControl(OptionsDlg);
new ActionMap(moveMap);
moveMap.push();
Then you will get an options screen where you can set your device
05/23/2011 (8:40 am)
Also, there's another way to set display device (and more). If you add the following line to "function startGame(%level)" in "game.cs":Canvas.setContent(mainScreenGui);
Canvas.setCursor(DefaultCursor);
// ADD THIS
mainScreenGui.addGuiControl(OptionsDlg);
new ActionMap(moveMap);
moveMap.push();
Then you will get an options screen where you can set your device
#15
For example, with the background at (-10.0, -10.0) and a sprite at ( 5.3, 2.7 ) will result in the sprite jittering unless its moved to ( 5.0, 3.0 ).
06/20/2011 (8:39 pm)
I'm not sure if this helps, but if I set my background image to a position where the x/y values are whole numbers, all objects displaying on top of the background must have whole number x/y values or they will "jitter" or "shake". For example, with the background at (-10.0, -10.0) and a sprite at ( 5.3, 2.7 ) will result in the sprite jittering unless its moved to ( 5.0, 3.0 ).
Torque Owner Dan Maruschak