About the jerkiness on the movement...

Discussion and feedback on Construct 2

Post » Sun Nov 02, 2014 12:49 am

So, I thought I would produce a test that drew a graphical representation of dt with respect to time.

Try this demo. I didn't get the results I was expecting, for sure.... A new sprite dot is drawn every tick and its y value depends on dt. My min/max values, after a few seconds to let the browsers settle down, were:

Chrome: 15 - 18 ms,
Chrome Canary 15 - 18 ms (visually slightly smoother)
Firefox 15 - 21 ms (relatively poor performance)
IE 16.7 +/- 0.2 (appeared to be the only browser that tries to target the vsync dt)

There is clearly a different philosophy between IE and the other browsers - IE clearly tries to target vsync whereas the others seem to hit slightly above or slightly below the target. Let me know what you think, but it doesn't look like Canary Chrome has sorted itself out yet....
You do not have the required permissions to view the files attached to this post.
A big fan of JavaScript.
B
74
S
20
G
71
Posts: 2,230
Reputation: 44,892

Post » Sun Nov 02, 2014 2:28 am

My results.

@colludium Also, I would love the capX
Currently your project does not support 120hz / 144hz displays. Had to manually put them at 60hz.

Chrome version: 38.0.2125.111 (Official Build 290379) m
You do not have the required permissions to view the files attached to this post.
B
28
S
8
G
1
Posts: 226
Reputation: 2,865

Post » Sun Nov 02, 2014 3:09 am

I was just doing some tidying up; version 1 was a bit of a rush-job...

Here you go - here's the capx (set up for a 60 Hz monitor - I don't have anything else to test against...)
You do not have the required permissions to view the files attached to this post.
A big fan of JavaScript.
B
74
S
20
G
71
Posts: 2,230
Reputation: 44,892

Post » Sun Nov 02, 2014 3:10 am

Interesting that - I presume your image is from Chrome @Tylermon - it seems to target a whole number of dt (in ms) rather than accurate vsync....
A big fan of JavaScript.
B
74
S
20
G
71
Posts: 2,230
Reputation: 44,892

Post » Sun Nov 02, 2014 4:44 am

@colludium

Not sure what you mean.
My dt is measured to the millionths place. And fluctuates.
My vsync/refresh rate was manually set to 60hz on my monitors. Thats why you see 60fps and not 120fps/144fps or more.

Your capx was admittedly a little strange to follow so I made a spin-off to do the same thing. I added in a way to control the accuracy which is great to see which browsers are more stable.
https://dl.dropboxusercontent.com/u/583 ... index.html

I found chrome to be stable up to the 10,000th decimal.
IE was stable up to the 1,000th decimal.

I also found IE to disregard my refresh rate. (ran around 68fps) Should have stayed at 60.

Chrome held a solid 60.
You do not have the required permissions to view the files attached to this post.
B
28
S
8
G
1
Posts: 226
Reputation: 2,865

Post » Sun Nov 02, 2014 5:01 am

Something I find interesting, is dt is directly proportionate to fps.

High fps = low dt = more frequent ticks = lower fps = higher dt = less ticks = go to beginning.

What does the above do? Cause a speed up/ slow down.
For me, I can only get this effect above 60hz. And the pattern looks pretty consistent between dt/fps graph.

Unless a browser maintains a solid vsync/refresh and a machine can provide the fps to match you get jitter.

Attached picture shows the DT spikes correlate with FPS drops. Which causes DT to drop/stabilize. And Repeat.

Image



Still though. This effect is not the same as the OP. This has more to do with my creating an object every tick. But it could contribute to the effect in some projects. It also shows some issues with fps/browser vysnc.

IE at 121hz lowers to 60fps. As a result it is stable, does not have that effect nearly as much as chrome.
Chrome however performed amazing at 60hz where IE then went above the 60hz refresh.





And one more picture.

Please note: in this image the blue fps graph is still technically higher than the red dt graph. The red graph is essentially enlarged/zoomed in.

Image

The dt spikes still correlate to the fps drops.
It also really shows how unstable dt is. Where we would ideally want dt to be constant.
B
28
S
8
G
1
Posts: 226
Reputation: 2,865

Post » Sun Nov 02, 2014 5:51 am

@Tylermon, I think you're missing the point of my example.

According to the image you posted, your dt tended to be either 16 ms or 17 ms (whole ms numbers) rather than 16.7 ms (true for 60 hz).... I'm sorry to say that your example capx didn't seem to show how much dt varies per tick with any calibrated fidelity. It's worth noting that none of the objects you create get destroyed, so your capx contains a form of memory leak that will tend to skew the data over time.
A big fan of JavaScript.
B
74
S
20
G
71
Posts: 2,230
Reputation: 44,892

Post » Sun Nov 02, 2014 8:17 am

@Colludium
The picture you keep talking about clearly said I had a max dt of 17.03 and a min dt of 15.96 using your capx. Last I checked...not solid numbers. The bottom left yellow numbers, 17.0, 16.7 and 16.0 are the exact same numbers your pictures have.
I'm not certain of everything your capx was trying to show. It confused me which is why I asked for the capx. I didnt fully understand your capx so I made my own.. personally, I wanted a line for fps, and a line for dt. Those are the things that i care about and believe are important. I also wanted to test 60hz, 120hz and 144hz.

Objects are destroyed when they leave the layout ;)
No data to skew there, I promise! (if they didn't get destroyed your fps would never be stable. It would always drop.)

The red line shows dt's direct reading(depends on decimal place chosen). When dt changes, the red line changes.

Small dt is a low line, high dt is a high line.

The drop down on the left changes the scale of dt to "magnify" it so to speak. Exaggerates what can visually be seen to hopefully make it very easy to see correlation with dt and fps.
Essentially, it allows for dt to directly translate to a pixel location. The value is the same. The Accuracy/level of graph detail is all that changes.
B
28
S
8
G
1
Posts: 226
Reputation: 2,865

Post » Sun Nov 02, 2014 12:20 pm

@Colludium have you tried your graph with GPU throttling? Any results?
B
92
S
31
G
24
Posts: 3,191
Reputation: 32,689

Post » Sun Nov 02, 2014 6:07 pm

@sqiddster and all,

I put together a more robust dt test. This gathers data on dt values over a 40 sec period - one sprite is created every tick (to fade out after 1 sec) and the background scrolls slowly. The results are drawn in a graph so you can compare the rates that different dt values occur against the ideal vsync dt for your monitor. You can also change the fps for different screens. I'm still tinkering with it in C2 and will post a capx shortly....

You can use This Link to give it a try.

As you can see in the image below, Chrome does not achieve a true vsync compliant dt, but rather its dt changes and seems to bracket the required 16.67 ms for 60 fps (the blue line is drawn at the ideal position for the entered fps); it appears that Chrome dt seems to target whole millisecond values for dt - at least on my computer. The x axis shows the different values of dt that occurred and the y axis shows number of times a particular dt value occurred during the data gathering.

no throttle Chrome.png



Contrast this with my result from IE:

no throttle IE.png


As you can clearly see, IE is much better behaved with regard to achieving vsync compliant dt values.


You can also select a gpu throttle option, which creates lots of fading sprites to try and achieve 45 fps. Here are my results below (quite messy, and I'm not sure if there's any good data here...):

gpu throttle Chrome.png
You do not have the required permissions to view the files attached to this post.
A big fan of JavaScript.
B
74
S
20
G
71
Posts: 2,230
Reputation: 44,892

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: dand, db3344, Tombas and 8 guests