About the jerkiness on the movement...

Oh cool. This does happen pretty often though. Yeah it always gets fixed but not without an entire campaign by the community -w-;

I can confirm this, tested with win8, chrome canary on my gaming pc the issues are gone! this is so awesome! now we play the waiting game till its implemented everywhere but i am so happy and motivated right now! thank you so much Ashley and everyone else and of course the chromium dev team!

Okay, so I finally got around to installing canary and just did an initial test...wow. No random janks and, overall, much smoother performance. Even when the framerate drops, canary seems to be handling it much more gracefully than before. Almost as well as IE. Color me happy <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

Ashley

OK, well, if you're creating/destroying 100 objects per tick then the CPU overhead of the create/destroy actions comes in to play. These need to do things like update object instance lists, families, containers, initialise the default state, initialise behaviors and so on. Most people don't create hundreds of objects per tick so it's not a significant overhead, but in this case it is measurable. I still don't think it's anything to do with garbage collection. The engine still recycles objects when it creates them, but creating an object just involves more work than re-positioning it. So in this specific kind of use case (you're basically recreating particle effects with sprites) repositioning is cheaper, but this does not prove garbage collection has any involvement at all.

First off: I'm not arguing that this is a bug with construct. Nor is recycling my idea...I got it from you (wish I could find that thread; you advised someone to reposition rain drops instead of destroying them).

However, the discrepency doesn't require 'hundreds of objects per tick' to be created and destroyed. Here's a modification of the DestroyVsMove test that only creates/destroys aprox 20 objects per tick. Jank is still visible, even on IE and Canary.

https://www.dropbox.com/s/glmtne23yud75 ... .capx?dl=0

Your comparison with particles is apt; however, particles can't collide, which is why I use sprites for bullets. The object count in the above test may be high, but the results I'm seeing are courtesy of an Intel i5 3570k. Lower power systems (most pc's/tablets/phones) will have lower thresholds.

tl;dr: If you are creating/destroying more than ~20 objects per tick, recycling may provide much stabler performance.

Here are updated benchmarks. Take note of the cpu readout:

Low Flo: https://www.dropbox.com/s/vild3og8h4j6n ... .capx?dl=0

Generates 20 objects per tick. Speed is 110.

High Flo: https://www.dropbox.com/s/61jtxzcbsbtg1 ... .capx?dl=0

Generates 60 objects per tick. Speed is 330.

I personally don't know many instances where I need 1200+ objects constantly being created every second.

That's what you are describing. Your 20+objects a tick is 1200+ objects a second being created and similarly destroyed only to be created again.

I would still be interested to see said 20 a tick improved. But I also want to see how that performs realistically. Creating worst case scenario projects isn't helping with making real games.

We are not talking about using 1200+ objects. This is creating and destroying this many, objects on top of trying to use them on top of any other game logic.

The OP was about a single sprite moving and seeming jittery/stuttering. This new scenario is one of insanity in my opinion, a non issue. I would love to see objects rendered more smoothly though.

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....

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

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...)

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....

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.

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.

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.

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.

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.

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.

Colludium have you tried your graph with GPU throttling? Any results?

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.

[attachment=2:5w6bsovz][/attachment:5w6bsovz]

Contrast this with my result from IE:

[attachment=1:5w6bsovz][/attachment:5w6bsovz]

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...):

[attachment=0:5w6bsovz][/attachment:5w6bsovz]