1.5 1.6 1.7 - Camera Jitter

#141 Pending Melv's official answer, his digging thus far has shown that in my case one of my onUpdate calls (getting done > 32 times a sec) is doing much more than it should be doing. I interpreted this to mean that it is using up more than its fair share of a single tick and the expense of this function can be intermittent in my case which could lead to visible jitter. I will be working tomorrow to change the structure of my onUpdate calls and make the ones that need to be there more efficient and I'll report back here if this smooths things out completely.

I think there may still be an issue with the particles, but it might be the way my emitter is set up.

#142 Melv told me about the OnUpdate calls, I changed mine (even if it wasn't extremely used) and it didn't make any noticeable change on the jittering.
On the particle side, it is not the way you might set these up, particles and triggers do play a role in this but we can't really change that (beside not using these at all, which wouldn't be ideal).

#143 Ben, so fixing the onUpdate calls didn't work for you?... hmmmm maybe I should rethink the idea to go and change everything. Also, when you say particles and triggers do play a role, do you mean that your particles are causing jitter as well?

Not sure where to go from here... you are probably in a worse position because you are nearing release.

#144 Guys,

Again, I would caution against using the word "jitter" to lump together these issues. In Brunos case I saw the juddering effect on the ball and this was on a relatively high-end system. In this case, we've got scene-updates as well as per-object updates going on. There was a specific callback being made which when I examine it had lots of complexity (loops etc). Nothing wrong with what it was doing but when I omitted it, the effect on the ball went away. It's just a case of trying to do everything as fast as possible and per-object callbacks can get expensive quite quickly. The best thing you can do is to spend a consistent time frame-to-frame. The worst is suddenly doing a single expensive call.

I've tried to explain it before but let me do so again. The engine (before any mods) will take an elapsed time since the last game-loop. This time is calculated once and then it is passed to all the sub-systems that are part of the main game loop so you get client and server updates, TGB engine updates and then finally rendering. The problem here is that it takes time between when the elapsed time is calculated and when the engine is updated and finally objects are rendered. If you suddenly have an expensive computational frame then the point at which these objects are actually rendered get further and further away from the current real time. This means that per-frame expenses cause a glitch. If we could stop time then it'd be fine but it marches on in its continuous form whilst the engine tries to handle it discreetly.

One of the final mods I added for Bruno/Benjamin is to add a Windows-only hack to test to see if some of the glitches being experienced here are related to this. What I did was to update the elapsed time just prior to the interpolation/rendering. Now this does solve the problem completely in my tests which do some random bulk processing to cause glitches but still keep the frame-rate at around 80fps.

Unfortunately, I have been unable to duplicate the exact effect which Benjamin is seeing on over a dozen machines which is very frustrating and I'm going on descriptions of it only. I also haven't got any script-code for IceWolf to examine but even if I did I'd more than likely get lost in it all.

So in summary... The mounting tick issues I've been presented with have been fixed until I am given another example of it not working. Bruno gave me his app and the problem here was the juddery ball which I traced and confirmed on two of my machines the culprit expensive callback. I presume that solves the problem here? In Benjamins case I have been unable to reproduce the problem he's seeing on over a dozen machines so I'm pretty much out of options. All my instrumented builds have shown nothing out of the ordinary. I do know that there's alot of expensive overdraw rendering going on but that wouldn't explain it alone unless there's a graphics-driver issue on his side. Besides I believe Benjamin can somehow get this effect on at least two PCs?

Particles have been raised as having a problem. This isn't directly correct. Stock particles don't do render batching (but I believe there's a resource somewhere for this?) and the effect of this (forgive the pun) is that when you're rendering lots of them 600-1000+ you may find that the graphics pipeline to your GPU isn't exactly running efficiently. That's why I disabled particles in executables I've sent out to ignore that seperate problem.

Guys, if I can reproduce the problem here then I will quite quickly fix it, that's a promise. I know that Benjamin has started trying this but the best way of getting to the root of this is to make a copy of your game and gradually hack-away parts of it. Start with callbacks and end up removing some of the expensive rendering calls. Don't rely on FPS to be a guide to how "good" your game is operating as it's an average. If you experience judder periodically, try to think of stuff in your game that works at that rate. If you can't then just continue removing parts of it. If you find that the effects gradually go away then you've probably got a combination of things going on that are causing it. The best thing you can do is get the effect in as simple a bit of code you can and get it to me ASAP. Even if I can't duplicate the problem, at least I've got a chance of examining every but of script that's running to see if it's the script at fault or something under-the-hood.

Since I starting looking at this I've spent every evening since working on trying to find what the problem is. This has mostly been with Bejamins IceWolf but in all cases I've been unable to reproduce the effect. With what I have been able to reproduce (mounting / Brunos juddery ball) I have fixed. I just had two evenings away from it because of work/family ties.

I'm planning to work on it this evening for a few hours and the better part of Sunday afternoon.

@Ken: I found a bunch of problems and I think I fixed the one you mention but I changed so much that I can't remember if that one I found. Thanks for the heads-up though and I'll double-check this evening.

Melv.

#145 Bruno,

In my previous email I said which call is causing the judder on the ball on my machine. So did you omit the call and the judder go away?

Melv.

#146 Benjamin, would you be willing to send a copy of IceWolf to me? I could try it out on my PC and Mac and see if I can offer any ideas about what's causing your jitterjudders.

#147 Hi Melv, I did as you said and commented the onUpdate call and without particles the juddering goes away pretty much completely. The thing I don't understand is that you initially could not reproduce the problem even on low-end machines. If this was all due to the expensive onUpdate calls wouldn't it show even worse on a slower system?

With particles on it is still juddering, but seems like a seperate issue like you mentioned above, but having 1000 particles in your game happens without even trying. One nice flame effect and you've used up most of that. Is the only way to fix this to batch the particles? Is this something that will be in a future version of TGB? I hate to modify the source code because then it becomes a maintenance nightmare if I want to stay up to the most current build of TGB (which I do).

I've also read a few other posts in the forums which seem to be suffering from the same jitter eventhough they may not describe it exactly the same way. Are we all doing the same thing wrong, or are there different issues here? Are there any generalizations we could make?

#148 Oh wow. I just decided to add a simple screen scrolling today. And yeah... totally borked with even the simplest movement. Code is all of

if(%playerX <= %worldMin || %playerX >= %worldMax)
   return;
   
   if(%playerX > %worldX + %xBounds) 
      sceneWindow2D.setCurrentCameraPosition(%playerX - %xBounds, 0);
      
   if(%playerX < %worldX - %xBounds) 
      sceneWindow2D.setCurrentCameraPosition(%playerX + %xBounds, 0);

Just for a simple bounding box movement test, and the character shakes a bunch when the screen scrolls, along with pretty noticeable tearing. Using .mount on the camera fixes the shaking, but I don't see how it's possible to use with a screen bounds scrolling system. At least it seems like it's being worked on actively at the moment...

#149 And where is that code? Because the way it's written, once you've reached your limit point, you'll be re-setting the position of the camera every single time your code is called, and if you are doing that at 30 times as second (in ::onUpdate() for your player for example) then of course it's going to shudder/jerk/whatever you want to call it.

As always, when doing things with callbacks, it's critical to be aware of the frequency of the callback, and do the appropriate things at the appropriate times. Again, I'm assuming that you are putting your code in an ::onUpdate() callback handler, but that would not be the appropriate frequency (32 milliseconds) to be adjusting your camera manually with setCurrentCameraPosition in my personal opinion.

#150 @Bruno: The low-end system I believe I mentioned was a laptop with a fairly good CPU but a terrible graphics chipset. The thing you have to remember is that the glitch you end up seeing has many variables and it isn't as simple as is it a low-end system. The problem was in your case that the effect was barley noticable on most systems but on one system it was clearly there. So are you okay to exclude your problem from this thread as it seems to be related to an expensive "OnUpdate" callback? If there are other problems then we can continue to include it.

@Paul: Stephens advice is sage. It sounds like you should be mounting the camera to the player and using the camera view limits to restrict it. This is done fast under-the-hood so you don't have to do it as per your example. If you still think there's a fundamental problem with TGB and it isn't what you're doing then please zip-up a demo and send me a simple piece of code that demonstrates the problem. My time is limited though so please do make it as simple as possible. I would highlight that there was a problem in TGB with mounting that I have now fixed and this has been confirmed by many people now.

@Benjamin: I'm still with you bud. :)

@All: Had a in-law visit today (mothers day) and it took an unanticipated all-afternoon. Feeling pretty tired so I've reached for the caffeine drink and am waiting for my brain to engage then I'll spend the rest of the evening looking at this.

Melv.

#151 Ok, I'll just watch :)

#152 I'd love to do that, but as far as I can tell, View Limits simply limits the world range the camera will scroll. It always remains centered on the character, while I need the screen to scroll only when the character reaches the edge of the screen.

I'm figuring there is possibly some way to keep an object in the center of the screen, mount the camera to that, and move the object when the player is at the edge of the screen.

Oh wow, that makes sense, I've been thinking how to do that for a day, and now typing it out, I think that will work.

#153 (I was taken out by my friends yesterday. They were saying something like me not seeing the light of day since months is not good, I had no choice x[] but I'm back, and alive ;))

@Melv
Yeah, I was wondering if it's not real "freezes" rather than object jittering. Which are different matters.
So, I tried this in t2dscenegraph::onUpdateScene:

%this.timenew = %this.getSceneTime();
	%this.time = %this.timenew - %this.timeold ;
	%this.timeold = %this.getSceneTime();
	
	if(%this.time > 0.028)
	echo("slow frame" @ %this.time );

This code does accurately report when there's a freeze in 1.1.3.
But in 1.7, it echoes constantly "slow frame 0.032001", very strange knowing it is OnUpdateScene and not OnUpdate.

#154 Benjamin,

What code are you running this against? If it's one of the updates I sent to you then be aware that I modified where the "onUpdateScene" is called so that I could evaluate the kind of effect going from updates per frame-render to updates per simulation-update.

Personally I don't believe that having the "onUpdateScene" called every frame is a good idea and no matter how fast people think scripts are ... they're script not native code! Indeed, it's only going to hurt the simulation as you're saying "I've calculated where everything is supposed to be as fast as possible but before I do it, run some custom arbitrary process that may take a long time and cause a glitch!".

With a few exceptions, the simulation (t2dSceneObject state) is only updated at 32fps (1/32=0.03125 sec) and so doing something like reading the position of an object and setting another objects position relative to it only changes at this rate. In between this there's the interpolation but this is for rendering only and is only there to smooth-out the simulation jumps. There's no collision-detection or physics.

I'm not sure I can make changes to this permanently as it may affect what people are doing so I'm kinda' caught between a rock and a hard place on that one. I would say that the original intent was to have a per-object "OnUpdate" and per-scene "OnUpdateScene" operating at the same frequency which changed when ticking came along.

Melv.

#155 Just sent an email to Benjamin but I've finally found a condition where I get judder. Benjamin merged the original "JitterDemo" with a level from "IceWolf" but so far any sign of a problem has eluded me. Setting it to run on a very high windowed resolution 1920x1200 causes juddering in certain parts of the level where there's lots of rendering going on even though the FPS is still a relatively high average of 60fps.

There's no scripts running in this demo apart from the players velocity being changed via a keybind.

I have, at last, something I can hopefully track down!

Woot! :)

Melv.

#156 Any progress on this?

#157 All reported direct cases of tick-physics bugs have been solved e.g. mounting issues etc.

What's left is a curious situation of full-screen juddering which has been isolated as simply too much work going on sporadically. In this case a more powerful PC doesn't show the problem whereas a lower-spec one does. Sometimes this is rendering and sometimes it's too much script etc. Because it can be easy to get into this situation, particularly if you don't profile or monitor what's going on in your scene regularly, I'm looking at ways of either highlighting this or potentially smoothing it out somehow.

There are a number of ways you can undermine the tick-physics and so making this more obvious is another piece of work.

Problems like the "glFinish" command have raised their ugly heads as well.

I recently did a fairly in-depth analysis of a particular demo that exhibited juddering. I've also had several chats with some of the GG guys about ways to solve some of these problems. So far I've spent over a hundred hours working on this and I'll continue to work on it until I am satisfied that everything that can be done, has been done.

I'd just like to mention that Benjamin has been a real trooper in helping me bullseye some of the root causes here. I think I must've sent him over 20+ executables and some seriously long emails. Thanks Mr B.

And let's not forget that I had to lug a 21" CRT from work so that I could run the demo @ 100hz which was when it showed most judder. Having on 60Hz LCD here at home I had no choice. I forgot how damn big CRT's are!

Anyway, all fixes have been submitted to the GG repo and I'm now working on this final "performance smoothing" case.

Melv.

#158 Hehe, me like .exes, me want tehm al =3
100+ emails about this, I can't believe it when I look back at it ^^'
Melv is really tenacious, even when I looked discouraged sometimes.

But now the issue has been cornered ^^

#159 Melv,
Last night, I came across a case of camera jitterring not described in this thread. The camera will jitter if you mount the camera to a moving object and call setScenePause. I am working in 1.7.2 and have a very simple project that demonstrates it on a high and low end machine. There's an easy work around (dismount the camera while the game is paused) but do you think your recently submitted changes will fix this too?

#160 Patrick,

Yes, that case is fixed. Previously, the "t2dSceneWindow" dealt with the mounting and this was a problem because the objects didn't update during tick/interpolation but the window did hence the problem.

The modifications I've made fix that because the mounted camera is driven positionally by the object it's mounted to and all is then well in the world.

I have got a note to check camera-moves with this modification but I've not yet got around to doing that. I'll do that as part of my quick QA testing clean-up. Hopefully it should be okay though.

If you want to send me the demo anyway so I can test your use-case then that'd be helpful.

Melv.