Delta

All topics about ZGameEditor goes here.

Moderator: Moderators

User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Delta

Post by Kjell »

Hej,

When a ZApplication is running in a environment with a refresh rate other then 60Hz, I experience a DeltaTime hick-up / offset every second. This only seems to go for windowed / preview mode, as the refresh rate is automatically switched to 60Hz when running a App in fullscreen. I suspect this is due to a incorrectness in the DeltaTime calculation?

Regards,
Kjell
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

I've noticed this sometimes too, however I can't really understand what the source of the problem is. The deltatime-calculation is so simple it can hardly fail. Maybe it is a combination of having ZGE running at the same time as your separate exe? When trying jph's windowed version of "Loose Pixels POW" no hiccups occur for me. Perhaps it is dependent on the content somehow. If you can provide some more info on the problem maybe we can hunt it down.
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hej Ville,

What calculation are you using to determine the DeltaTime? Also, as far as I can see you sync the render frequency to the environment screen frequency, correct? But what about the behavior loop? Is it tied to the framerate or does it have it's own rate ( free / limited )? And this might be unrelated, but why does the App.FPSCounter only update once a second ( probably because it's called FPSecond :P )?

The problem with DeltaTime is that you're always working with data that is one frame old, while ideally you'd want to accurately predict how long the current frame will take to execute .. but that's pretty much impossible :?

One of the things one can do as a user is to calculate a average of the DeltaTime over the last second or so. This can work quite well, but since ZGE has the DeltaTime multiplied in it's Velocity values automatically, you'd have to refrain from using those then ( or dividing the value by the build-in ZGE DeltaTime ).

Determining whether the windowed version of jph's LPP suffers from this artifact as well is a little hard since everything is in motion constantly. Also he could be using Model.Position.X += instead of the Velocity values, and not making use of the Delta Time at all or calculating a average. Perhaps Mr. jph can shed some light on his approach in LPP? ;)

Regards,
Kjell
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

There is a very useful 3d-graphics setting in most graphics card which controls "Vertical Sync". If this setting is on then the graphics driver will force programs using OpenGL or DirectX to use the same setting as the screen vertical refresh rate.

I suggest you find this setting and turn it off. You will notice frame rate will probably double instantly in your ZGE-apps. And yes, I noticed JPH's game actually plays twice as fast with this setting. You need to read up on your deltatime jph ;)

The FPSCounter is only updated once a second because it is easier to read. Otherwise it would flicker wildly between high and low values. Now it displays the number of frames rendered the last whole second which I think is more useful.

I encountered hiccups in framerate when working on Triple-E, but they don't appear now (apart from a slight drop in framerate when the boss appears which is normal).

DeltaTime is calculated with in the standard text-book approach, basically:

Code: Select all

  //Do this every frame to calculate DeltaTime
  Time = GetCurrentTime()
  DeltaTime = Time - LastTime
  LastTime = Time
Many games use this technique so it shouldn't fail here. Perhaps I do not configure the Windows high precision timer correctly in initialization code.
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hej Ville,

My GPU was actually set to "Application Controlled" VSync. When changing it to "Force Off" the framerate went up dramatically as you predicted. However, the hiccups still occurred.

While I'm definitely no expert in this field, I suspect is that by not limiting the behavioral framerate with VSync turned off, and thus requesting the CPU to push out as much frames as possible ( 100% CPU usage ), the app becomes more vulnerable to irregularities when other ( in my case ) Windows tasks request some CPU usage as well.

From my experience PC apps generally run smoothest in framerate / perception when both the frame and behavior rates are synced to the refresh rate of the user environment ( 60Hz / 85Hz / 100Hz etc ) without making use of VSync.

Anyway, it's by no means a urgent problem .. but it might be something easily fixed once you know the cause :)

Kind Regards,
Kjell
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Yes you are right, there is little point for ZGE trying to generate more frames than the display device can handle. It is sometimes useful as a measure of performance though, if the normal fps is 250 and it suddenly drops to 150 then you know you've done something cpu-intensive and may need to test on slower computers that it still works ok. But it should lock to the display refresh rate and sleep instead of using 100% cpu, I might do something about that.
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hej Ville,

Being able to choose what you want to go with as a developer would be the ideal situation. I can imagine having a Mode selection drop-down added to the ZApplication ( similar to how ScreenMode currently works ), from which you can choose between Free / Sync / Limit. And additionally there would then be a FPSLimit property ( int ) which is used when App.Mode is set to Limit.

Regards,
Kjell
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

timing is everything!

Post by jph_wacheski »

ha ha,. yes Ville, I am working on getting up to speed :P on this deltatime buisness,. and I did not take those timing issues into account in LPP so if you have a fast machine you better be a great gamer! lol..

I am working on CCUG now and I think i have implement DeltaTime on all my player control values,. however I am unsure how I can test this??

what I've done;

rotation like this,.

Code: Select all

 if (rot_spd<.01) rot_spd+=0.1*App.DeltaTime;
currentModel.rotation.Z-=rot_spd;
with an anti/control mechanism also on the OnUpdate;

Code: Select all

if (rot_spd>0) rot_spd-=.08*App.DeltaTime; // rot inertia
However my thrust forward is done like this;

Code: Select all

currentModel.velocity.X+=cos(currentModel.rotation.Z*(6.28));
currentModel.velocity.Y+=sin(currentModel.rotation.Z*(6.28));
with the corespondinf friction effect here;

Code: Select all

currentModel.velocity.x*=51*App.DeltaTime;  // friction
currentModel.velocity.y*=51*App.DeltaTime;
This all workes fine on my machine and hopefully it will at other speeds ,. have I done this right ? I could not figure if the forward thrusting will be effected by frame rate as the trig. just converts direction to vector,. and the friction controls the speed,.

My next question is about the timers; do these need to have DeltaTime adjustments as well? or is that automatic ? this would be for my spawn timers of the badguys, etc. Oh, and how about repeat delay for key events? as the shot speed should be fair to all players as well,. Thnaks!
Attachments
CandyCorn_UnderGrowth_013_deltaTime.zip
1024x768 windowed,.
(39.76 KiB) Downloaded 423 times
iterationGAMES.com
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

First of all, no you do not need to think about deltatime in Timers, they take care of it automatically. All component properties which are "time in seconds" (like repeatdelay) take deltatime into account.

In your attached exe, the rotation is too fast and thrust/reverse movement is too slow. If you want to try on your own computer I suggest your find the "Vertical Sync" setting in your graphicsdriver and set it to "force off". The frame rate will then be at least doubled depending on how powerful your graphiccard is. By toggling that setting you can easily try your game as it would run both on a slow and fast computer. Use a rendertext to display the FPS at least while developing your game.

And you need to be aware in your code that deltatime can be anywhere in the range of 0.001 to 0.1.

For instance in this code:

currentModel.velocity.x*=51*App.DeltaTime;

If DeltaTime is 0.1 (10 fps) then it will be multipled with 5.1 which is no friction :)

Protect it with the clamp function

//highest factor 1.0
currentModel.velocity.x*=clamp(51*App.DeltaTime, 0, 1.0 );
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hi jph,

I'm afraid it's a little more complicated then that. When calculating de- / ac-celleration velocity while using forces like friction, you cannot just multiply with the DeltaTime. Let me give you an example.

Let's say we have 2 computers, computer A is twice as fast as computer B. Let's say A renders at a DeltaTime of 0.25 while B doesn't get higher then 0.5 ( both quite shitty :P ). Now let's accelerate a stationary object with the DeltaTime value as Thrust, and a Friction influence of Velocity/4*DeltaTime, for 1 second.

A: After 1 frame ( 0.25 second ) the added velocity is 0.25, which becomes 0.234375 after the friction influence is subtracted. The next frame another 0.25 is added to the 0.234375 which results in 0.484375 .. which becomes 0.4541015625 after the friction. When the full 1 second has passed, the velocity on computer A is approximately 0.85321426 ...

B: After 1 frame ( 0.5 second ) the added velocity is 0.5, which becomes 0.4375 after the friction influence is subtracted. When you compare this to the Velocity after half a second on computer A, there is a noticeable difference. After the full second the Velocity on computer B is 0.8203125 ...

This inaccuracy might seem small, it will make quite a difference over time. Anyway, hopefully you understand why this is not correct. And the solution? Use exponential calculations :wink:

Good luck~
Kjell
Last edited by Kjell on Sat Apr 12, 2008 3:45 pm, edited 1 time in total.
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Kjell, you are correct, I just want to add that DeltaTime is capped to never become larger than 0.1 (FPS 10) just to make it easier to have robust zexpressions using deltatime.
User avatar
jph_wacheski
Posts: 1005
Joined: Sat Feb 16, 2008 8:10 pm
Location: Canada
Contact:

I knew iteration thirteen was not lucky,. .

Post by jph_wacheski »

DRAT ! just when I thought i may be getting close to hacking out this simple gameplay with the deltatime funk workin',. Kjell has gota go and get all exponetial on my pea brain ass,.

Oh well. more google searches, and expression hackin' to be done then,. as no I really don't see how exponetial math will help here,. . or perhaps you guys could post a working exaple that can b understood by mear mortals,. I envy you scandinavian math heads,. you must have better schoolin' than we get here in the dumbed down american systems,. perhaps the controling powers here don't really want us to understand math, as if we could, we would see how indebted this place is,. oh well that's another thread!

peace,. . till underverse comes.
iterationGAMES.com
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Jph, I'm really not good at math at all. The little I've learned I've had to struggle to understand.

I think deltatime becomes easier to handle if you think in terms "per second":

//Accelerate with 2 units per second
currentmodel.velocity.x += 2.0 * App.DeltaTime;

//Friction is 1 unit per second
currentmodel.velocity.x -= 1.0 * App.DeltaTime;

The above expressions will give the right amount of acceleration and friction regardless of frame rate. This in my opinion is easier to get right compared to calculating a multiplication factor.
User avatar
Kjell
Posts: 1876
Joined: Sat Feb 23, 2008 11:15 pm

Post by Kjell »

Hello,

The formula's that Ville prescribed work correctly on any framerate, but won't reach a natural equilibrium. Let me share one of my favorite simple pieces of math with you guys ( in ZScript ) which I use in cases where there are not a range of variable forces in play.

Velocity += (Input-Velocity)*(1-exp(DeltaTime*-1000/Inertia));

And for the record, I'm not Scandinavian ;)

Have fun~
Kjell
User avatar
VilleK
Site Admin
Posts: 2274
Joined: Mon Jan 15, 2007 4:50 pm
Location: Stockholm, Sweden
Contact:

Post by VilleK »

Woa suddenly we have avatars guys, nice! :)

That's is a pretty elegant expression, Kjell. I won't pretend to fully understand it, so I'm going to ask you a couple of questions:

"Input" is desired velocity?
Can you explain the -1000 constant?
How would this expression be used in a scenario where there are Keypress-expressions for accelerate/decelerate like in jph's game?

Also I'm getting more and more curious on what projects you are using ZGE for, Kjell :)
Post Reply