1.5 1.6 1.7 - Camera Jitter
by Benjamin L. Grauer · in Torque Game Builder · 07/16/2007 (5:59 pm) · 194 replies
When the camera is mounted to a moving sprite, the sprite and the background are trembling (when moving).
Especially visible when there's multiple parallax backgrounds. I have the sprite moving using setlinearvelocity at about 50 and the camera mounted with a force set to 0 or higher than 5, the design screen size is 100*75 on a game resolution of 1024*768. Also, it is clearly more visible with vertical sync (and vertical sync is more than necessary for high resolution). The shaking is not something constant, but it is happening very often. When it happen, it seems like the camera go in the wrong direction then catch up back for the time of 2 frames (so, the lower is the framerate, the more remarkable is the issue).
I just tried a workaround by not mounting the camera. For that, I updated the camera position at the player position in updatescene callaback, using getrenderposition to get the exact drawn sprite position... With no success, everything is still trembling a lot.
It could be many things causing it : something with drawn sprite interpolation or camera interpolation or some updating no more happening precisely on each frame. If someone could take a look at it, I would appreciate the help.
Especially visible when there's multiple parallax backgrounds. I have the sprite moving using setlinearvelocity at about 50 and the camera mounted with a force set to 0 or higher than 5, the design screen size is 100*75 on a game resolution of 1024*768. Also, it is clearly more visible with vertical sync (and vertical sync is more than necessary for high resolution). The shaking is not something constant, but it is happening very often. When it happen, it seems like the camera go in the wrong direction then catch up back for the time of 2 frames (so, the lower is the framerate, the more remarkable is the issue).
I just tried a workaround by not mounting the camera. For that, I updated the camera position at the player position in updatescene callaback, using getrenderposition to get the exact drawn sprite position... With no success, everything is still trembling a lot.
It could be many things causing it : something with drawn sprite interpolation or camera interpolation or some updating no more happening precisely on each frame. If someone could take a look at it, I would appreciate the help.
#22
When can we expect this bug being taken care of ? I can't release anything as long as it is here :/
10/22/2007 (9:13 am)
Working without ticked physics for an action game is suicide (1.1.3)... and working with a jittery camera (which eat your eyes and brain in minutes) is even worse (1.5.1).When can we expect this bug being taken care of ? I can't release anything as long as it is here :/
#24
I do have one project with a mounted camera on a player and it's not totally smooth, but it's also not horrible either. Although, if I recall, I increased the player's speed and turn rate as that seemed to smooth things out.
11/08/2007 (1:00 pm)
This is a good question for the Ask Garage Games thread. I think that thread may get more notice from GG employees. I am interested in this issue as well, although my only experience with the problem is through reading this thread. Maybe I will try out your examples tonight.I do have one project with a mounted camera on a player and it's not totally smooth, but it's also not horrible either. Although, if I recall, I increased the player's speed and turn rate as that seemed to smooth things out.
#25
I think I can begin to assume for sure that they're voluntarily ignoring it, and ignoring me at the same time.
Damn... if somebody from GG could just say "we're not gonna take a look at it anymore" at least I'd know I'm not taken seriously.
11/15/2007 (4:15 am)
This is a 4 month old topic (which was often on top of the Report Bugs forum) for a 7 month old issue. And yet GarageGames didn't answer if they could reproduce it and/or identify the cause. Neither here or in any other topic, including the "Ask Garage Games thread" you suggested me, Steven.I think I can begin to assume for sure that they're voluntarily ignoring it, and ignoring me at the same time.
Damn... if somebody from GG could just say "we're not gonna take a look at it anymore" at least I'd know I'm not taken seriously.
#26
11/15/2007 (7:37 am)
I know. I was just thinking last night how there was no response in the Ask Garage Games thread. It seemed to be followed closely by a GG employee. 
#27
11/15/2007 (10:11 am)
Sorry for the lack of communication back (we're always busy here :). We have registered the issue since you first mentioned it Ben. We are working on a possible fix, though don't want to promise anything until we actually have a fix.
#28
Sorry I lost my temper, but this issue is really killing me since a long time. Hope you get rid of it for good.
Thanks for the news Matthew :)
11/15/2007 (9:35 pm)
Ah, that's great \o/Sorry I lost my temper, but this issue is really killing me since a long time. Hope you get rid of it for good.
Thanks for the news Matthew :)
#29
At the first run, I first thought it was gone as the camera getposition was improved (and so my parallax backgrounds were improved), but the jittering is still here and breaking the game flow...
The patch did decreased the time of the jitters, it's now almost invisible in the little "camerabug" demo. But, in a full fledged action game, it's here.
I updated the demo to reflect that, I simply added some particle emitter to slightly reduce the FPS (which is still far from a true game situation), and you can see the camera jittering again and/or giving the false impression that the FPS is lower than it is really (but don't look at the emitters, they're caped at 32fps since ticked physics).
dragon.six.free.fr/deviantgames/camerajittering.rar
On my project the difference between 1.6 and 1.1.3 is (less than 1.5, but still) disastrous :/
I don't want to discourage you (GG guys) but I'm myself feeling discouraged by that, it's like I will never be able to release anything public :/
12/16/2007 (7:43 am)
I tested extensively 1.6 and... the camera jittering is still here :/At the first run, I first thought it was gone as the camera getposition was improved (and so my parallax backgrounds were improved), but the jittering is still here and breaking the game flow...
The patch did decreased the time of the jitters, it's now almost invisible in the little "camerabug" demo. But, in a full fledged action game, it's here.
I updated the demo to reflect that, I simply added some particle emitter to slightly reduce the FPS (which is still far from a true game situation), and you can see the camera jittering again and/or giving the false impression that the FPS is lower than it is really (but don't look at the emitters, they're caped at 32fps since ticked physics).
dragon.six.free.fr/deviantgames/camerajittering.rar
On my project the difference between 1.6 and 1.1.3 is (less than 1.5, but still) disastrous :/
I don't want to discourage you (GG guys) but I'm myself feeling discouraged by that, it's like I will never be able to release anything public :/
#30
12/16/2007 (4:15 pm)
Thanks for posting a prompt response and an updated test case. Seems we found one aspect of the problem (thanks goes to Melv for spending time on digging into it) but not all. Obviously I don't want to promise anything, though getting the camera jitter fixed was a very important aspect to us and was the reason the release was delayed as long as it has been... unfortunately our test cases weren't complex enough to truly put it to the test. Fixing issues like this is important to us, if/when we approach fixing this issue more I will be sure to include you on testing it against your game which seems to be one of the best tests we could have.
#31
So keep up your awesome work, GG! :)
12/16/2007 (9:58 pm)
First of all, I didn't get around to get my hands on TGB1.6 yet. But I want to make a suggestion here.. from the point of view of a client who doesn't have inside view of GG it seems that the Quality Management system of GG needs improvements to satisfy the discontent of its client. Benjamin waited certainly a long time for this issue to get fixed. Now the new version is out, he eagerly tried it out, just to be let down again. And in regard to the long wait he probably asks himself "This has been a REAL issue for many TGB users, why didn't they cover this airtight in their tests?". My suggestion is, that if a real brainteaser like this bug appears, GG should leverage that client to get it fixed.. that's a win-win situation and hey.. we're a _community_! :)So keep up your awesome work, GG! :)
#32
You bring up some very good points and I would be the first one to admit we haven't done the best in that area, though in certain cases we have done well. Though I will make a couple notes that make this circumstance a bit different... for example, Benjamin himself said:
"The patch did decreased the time of the jitters, it's now almost invisible in the little "camerabug" demo. But, in a full fledged action game, it's here."
So in the test case provided this issue was greatly improved, very deceptively to the point that we thought it was solved. As we all know a game engine is a very complex thing and with an update like 1.5 that introduced tick based physics there were a lot of fundamental areas that were changed. We had in fact solved part of the issue, though based on his game it is apparently not all the areas in which some tuning and changing needs to be made.
So though I can understand the frustration, based on the situation one could understand the complications.
I do think you make a great point that leveraging dedicated users like Benjamin would be invaluable and in fact that is our future plan... when we get test cases to distribute them to the relevant person who probably has a test case that is the most appropriate, a true use of the tech separate of us.
You bring up some very good points, though I wanted to make sure that several aspects were represented... we did in fact have a test case posted and the issue in this test case did appear to be solved... though I agree leveraging him specifically will not only benefit him getting the fix sooner, but us in providing the best test base while also saving resources on our end trying to reproduce a test case that won't be as beneficial as a truly used one.
12/16/2007 (10:24 pm)
@Oliver:You bring up some very good points and I would be the first one to admit we haven't done the best in that area, though in certain cases we have done well. Though I will make a couple notes that make this circumstance a bit different... for example, Benjamin himself said:
"The patch did decreased the time of the jitters, it's now almost invisible in the little "camerabug" demo. But, in a full fledged action game, it's here."
So in the test case provided this issue was greatly improved, very deceptively to the point that we thought it was solved. As we all know a game engine is a very complex thing and with an update like 1.5 that introduced tick based physics there were a lot of fundamental areas that were changed. We had in fact solved part of the issue, though based on his game it is apparently not all the areas in which some tuning and changing needs to be made.
So though I can understand the frustration, based on the situation one could understand the complications.
I do think you make a great point that leveraging dedicated users like Benjamin would be invaluable and in fact that is our future plan... when we get test cases to distribute them to the relevant person who probably has a test case that is the most appropriate, a true use of the tech separate of us.
You bring up some very good points, though I wanted to make sure that several aspects were represented... we did in fact have a test case posted and the issue in this test case did appear to be solved... though I agree leveraging him specifically will not only benefit him getting the fix sooner, but us in providing the best test base while also saving resources on our end trying to reproduce a test case that won't be as beneficial as a truly used one.
#33
12/16/2007 (11:00 pm)
Sorry, I didn't mean to sound like you didn't do anything at all.. I sincerely apologize for that. I love TGB and although it already blasted past other 2D engines it seems to become more and more difficult to maintain and I would hate to see this community fall apart because of very talented people turning their backs in frustration. :) I think GarageGames did a very important step with Torque2 and its open development. It's what I like about most asian restaurants.. they prepare your food right before your eyes. The client wins trusts, thus grows more loyal AND learns. :)
#34
I'm going to make a clean build of IceWolf in both 1.1.3 and 1.6, and send you a mail as soon as possible. Please take a look at it.
01/02/2008 (9:39 pm)
@MatthewQuote:unfortunately our test cases weren't complex enough to truly put it to the test.How did the QA took this long if it wasn't to thoughtfully test the issue? It took me only minutes to see it. What a disappointment, I was expecting better from the new QA team :/
I'm going to make a clean build of IceWolf in both 1.1.3 and 1.6, and send you a mail as soon as possible. Please take a look at it.
#35
01/08/2008 (1:28 am)
I sended the mail to mattl [ at ] garagegames.com yesterday, titled "TGB - Camera Jittering Test Demo" with two demo so you can see the difference between 1.1.3 and 1.6, hope this will help.
#36
01/14/2008 (1:03 pm)
Well? What's going to happen about this issue? Will you try again to resolve it?
#37
So out of curiosity, if anyone who has the source is having this problem, try changing this in iTickable.cc, line13:
01/24/2008 (7:28 am)
I finally switched over from 1.1.3 and noticed that although camera jitters are probably a lot more obvious, everything moves with a jitter. Digging a bit I notice that the Physics engine only runs every 32ms or so. Huh?? Isn't Physics supposed to be updated faster than the screen refresh at the very least?So out of curiosity, if anyone who has the source is having this problem, try changing this in iTickable.cc, line13:
const U32 ITickable::smTickShift = 5;to
const U32 ITickable::smTickShift = 3;This will have the physics engine update approximately every 8ms, or about 125fps. I don't have any camera movement, but this makes the jitters go away for me so it's worth a try.
#38
Beside, faster thicks is something I would want to have anyway (cause particle limited to 32ms update looks like crap too).
01/24/2008 (2:39 pm)
Thanks a lot Ken, if you or somebody could confirm that it does resolve the camera jitter, it would be perfect. Beside, faster thicks is something I would want to have anyway (cause particle limited to 32ms update looks like crap too).
#39
01/24/2008 (3:34 pm)
Once I get a chance I'll try and grab the test case you sent me with changing the tick shift. Also wanted to thank you again for sending us a test case. We are definitely aware of the issue, the fixes that were implemented in the last release actually looked to solve the original test case, though apparently a lot more is going on. So even though the issue you are encountering isn't fixed, an issue that is part of that has been, hopefully we can find adequate solutions to solve your issue... your full test cases definitely help contribute to that, the next step will be isolating that issue outside of your test case (since a lot is going on in your test case that may or may not be contributing to the issue).
#40
Good to know you're still working on it ^^
For the test case, you're welcome, as I hope it'll help me getting the game finally done or at least a good demo to be released soon.
So, did you had the time to see if the tick shift did some good effect?
Can we expect a patch soon?
02/11/2008 (11:07 am)
@MatthewGood to know you're still working on it ^^
For the test case, you're welcome, as I hope it'll help me getting the game finally done or at least a good demo to be released soon.
So, did you had the time to see if the tick shift did some good effect?
Can we expect a patch soon?
Torque 3D Owner Jay Barnson
So this was a bug introduced in 1.5 (not surprising considering the scope of changes in 1.5).
For now, I'm going to stick with 1.1.3.