Camera movement not tied to actual frame rate?!?!?

#21 I have almost fixed the issue.
Sometimes the client gets backlogged for several milliseconds (10-30), this causes the internal timer to stop.
But I will dig into this tomorrow.

btw dt in advanceTime() is not the same for interpolateTick()
in advanceTime() dt = 1/fps
in interpolateTick() dt is a linear interpolation coefficient

#22 @Ivan: check processTimeEvent() in mainLoop.cpp. That's the main entry point for the simulation updates, and it receives how many milliseconds have gone since the last update. However, it limits the elapsed to to 1024 milliseconds, to prevent to simulation from having to catch up for long amounts of time.

I don't recommend taking that limiter out, since it's there to prevent the game from falling into a "death spiral" if CPU-constrained (aka: the game's attempts at catching up increase the time between updates, which increase the number of ticks to catch up, which increase the time between updates, which increases the.... well, you get the idea.

#23 iTickable also provides this interface, but I dont think player uses iTickable: (read the iTickable source for some great in-depth description of this interface)

Processtick happens every 32ms (or whatever Tick is defined at), most server sim stuff uses this along with anything else that needs a stable tick, like physics sims. This is a very important function.

Interpolate tick is used client side to do the stepping between ticks at frame rate. This is where rendertransforms can be set. As Ivan points out, dt in interpolatetick is a fraction of TickSec, so any calcs there need to be normalized to that.

Advance time runs client and server at framerate.

#24 I did a small hack in moveList to prevent the backlogging,jittering still presents.
I found that if I load the scene with a terrain,a water block,...etc - I am out of sync.
When I use a simple opcode terrain - everything is smooth and the framerate does not matter.

Also when I call water_object.delete() then T3D crashes,but this is a separate bug.
Everything I am trying to explain is that some of the objects in T3D cause problems. In my case this is the water block. I have been developing my game with the most common objects such as TTStatics, players, items , Sky so far and I haven't got any problems with them. When I decided to add the water block the problems just began to happen.
It is definitely not the framerate that causes the problems. Just like I told before I made some example simulations to make the framerate slow down to 5 using massive debrises' creation for a certain amount of time. When the debrises disappeared and the framerate recovered everything got fine again. So I came up to that the framerate isn't the problem.

#25

Quote:
It is definitely not the framerate that causes the problems. Just like I told before I made some example simulations to make the framerate slow down to 5 using massive debrises' creation for a certain amount of time. When the debrises disappeared and the framerate recovered everything got fine again.

this reasoning is sound but I'd like to know how this is affected by windowed vs. full screen. was this example simulation run in windowed mode as well as full screen?


a fps of around 30, means the frametime is around 33 ms which means interpolate tick should be called only once between every processtick. It's also important to note that interpolatetick is called every frame, including on the frames where processtick is called as well.

#26 To Ivan:

Quote: It is definitely not the framerate that causes the problems. Just like I told before I made some example simulations to make the framerate slow down to 5 using massive debrises' creation for a certain amount of time. When the debrises disappeared and the framerate recovered everything got fine again. So I came up to that the framerate isn't the problem.

I think that rather than talking about "framerate" here (as it has become such a ubiquitous, catch-all term), it might be best to break this into "update rate" which refers to how long the logic not related to actual image rendering takes, and "render rate" which is purely how long the image rendering takes. I think that in my case, I start to see jittering when the render rate gets too large relative to the update rate.

In fact, even render rate can be ambiguous. Again to further clarify my case, I'm seeing the jittering when the GPU-based render rate gets large with respect to the CPU-based update rate.

Just trying to add some clarity to this discussion.

= Ed =

#27 I absolutely agree with you,Edward.
I came to a conclusion - the GPU based load is causing the jittering.
When I have a CPU based load,no problems at all.
I did a massive test on 4 PCs - the same jittering appeared on all of them.
Currently this is an issue number 1 for my project.The GG team should really investigate the problem.

#28 I noticed that if I spawn a water object runtime - no jittering.
If I save the object in a mission file - then I see the jittering.
This sounds like a workaround but I don't understand why this causes the lack in interpolation.
This should be investigated in future.

#29 Any solid leads or luck with this? It's something I've noticed in earlier versions of Torque (in particular the Atlas TGEA demo Barricade). I don't notice it as easily in T3D, but under some circumstances I can get the behavior. The last time I saw it, I was using a long draw distance, high poly terrain, and was getting 95 FPS, with timely jerks. It's something I'd love to see fixed.

#30 I noticed this only when rendering a terrain object. If you don't have a terrain in the render view, you don't have jittering.

#31 "J" said:

Quote:I noticed this only when rendering a terrain object. If you don't have a terrain in the render view, you don't have jittering.

And from a single observation we have created incontrovertible fact! Sounds like some pundits on television.

I am the original poster. We have no terrain in the level in question at all. We have this problem. Ergo - bad assumption based upon too little evidence.

= Ed =

#32 Edward Rotberg, what you are commenting about may be related to an previous complaint I have had.(EDIT: Oh look, i noticed and commented about it almost a year ago.. Hop Hop GarageGames, the sooner you take customer complaints seriously the sooner you will have a quality product...)

The 'timeManagerProcessInterval' setting is to finicky to be considered a fix but if it change the behavior you are experiencing, it just may point out what the real cause of the problem is steaming from.

#33 Caylo,

Thanks for the input. I noticed that you set it to '40' in your post. Any reason for that value? It is current set to '1' in my scripts\client\pref.cs file. However it is defaulted to 5 in constructor for the TimeManager.

This value apparently causes a sleep() of that number of milliseconds minus the elapsed time since the last call in the _updateTime() function of the TimeManager (platformTimer.cpp), assuming that the result is a positive value. The _updateTime() function appears to only be used in the Process::notify() function of the event processor.

So it looks like it could possibly apply to this situation if event processing was an issue and the event queue was getting backed up?? Very interesting. I'll have to do some further testing/logging to find out if this is involved with what I'm experiencing.

That said, it seems like 40 is a pretty high number, and would seem to cause the notify function to do a lot of sleeping. If this is running in another thread from the main game logic, that could be a good thing.

I probably won't get to this right away, but when I have time to check it out fully I'll report back here.

= Ed =

#34 It have been a passing of time from my posting along that line of thought. I expect my setting of 40 was more in tune with the -at the time- my poly load on T3D. I do recall the wish to recant my sentiment as per scene and use of T3D constantly required an ever changing refactoring of the timeManagerProcessInterval setting. In the end I was never happy with the results and instead of waiting for the 'greasy kids' to finish with what playground exercise of 'might and power' = glitter dust in the face; I moved onto an engine and company that was not so obtuse and obnoxious. Torque for me is no more then a quick simple 'BASIC' way to prototype a rudimentary concept. I feel so horribly bad for the aspirating creative computer game genius who stumble afoot into this sick Garage Game crapload of marketing hype.

I am most sure my helpfulness on this specific subject to be exhausted, but be assured once you find not only this subject to be a pain in the ass, and explored exhaustive solutions, you will become aware of even more nefarious ingrained faults.

But I may be wrong, and a true know it all developer could position a solution to the problem that makes every one of us happy to the core...

#35 timeManagerProcessInterval was the first thing that I checked a few days ago - it sets a value that updates the platform timer. This will lead to a better precision on bad framerates, the negative effect is limitting the fps to 1/timeManagerProcessInterval, so values 10+ will result in a nasty jittering when vsync is used .

#36 My apologies for respawning the thread...

Please I know this is a very poor fix, but it works for me... Now I have the camera rotations absolutely smooth, witch was my problem.
And I know that this is a non portable solution. I've posted this message because I want to give a start point to anybody with better acknowledge on Torque.

I realize that there is a problem with timing on the
TimeManager::_updateTime function. Things works better with a more regular timing. And Sleep() is not very regular. What I've done is totally replacing with this function:

void TimeManager::_updateTime()
{
	static HRTimer hrtimer;
	hrtimer.stopTimer();

	while(hrtimer.getElapsedTime()*1000.0<16.667) //60Hz
		hrtimer.stopTimer();

	S32 finalDelta = hrtimer.getElapsedTime()*1000.0;
	hrtimer.startTimer();

	timeEvent.trigger(finalDelta);
}

The HRTimer class can be downloaded from
http://www.cs.up.ac.za/cs/banguelov/blog/HRTimer.h


I don't know if it is important but I'm currently using TickMs = 16.

(sorry for my BAD English)