Colludium's Forum Posts

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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

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

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

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

  • Here you go, I've edited your example and this should work for you.

    You had a small memory leak in there by continually increasing the size of the player position array. I have also changed the way the data is inserted into the array so that each tail sprite obtains its position data from the position array according to its position number and a time delay that you can edit using a local variable.

  • Dropbox error 404 - can't find the file....

    edit to add LittleStain, great signature comment!

  • What you could be experiencing are documented frame drops in Chrome/Firefox (less so in IE) due to GC or other browser processes. Here's a link to the Jerkiness thread in case you've missed it. Short term problem which should get fixed by Google/Mozilla in due course.

  • Same problem - and no complaints!!

  • Yeah - IE is smoother than Chrome by a long way. Pity its interface is so, well, Microsoft...!!

  • How would keeping not help? Wouldn't it smooth the movement so to speak?

    I think that the problem is that during run-time you don't know when a frame is going to be dropped by the browser - so your lerp-ed positions won't always be drawn every tick anyway. And once a frame update is missed then it's too late... Also, lerp-ing everything will just add to the cpu/gpu workload, which is unlikely to help the problem. The only way to have a smooth experience across a broad range of browsers seems to be to have a small and not-zoomed canvas size and to have not much graphical changes taking place (kind of the opposite of what I want to do...).

  • Leandrus, sorry to hear that - it was the only thing I could think of. I started to get other problems with the plugins so I stopped using them... I don't know if austin has frequented the forums here, but I think he does answer direct emails to clay.io if you try that approach.

  • Leandrus, try having the line 6 as a separate event (not on start of layout) - and add a trigger once to the condition. The Clay.io. ready might not trigger on the start of the layout and could get missed...

  • I am from the UK but currently working in the US. I have to say that I really enjoy participating in the C2 community - it somehow 'completes' the editor experience...

  • Telyko, ha! Yes, I was not clear at all. It certainly appears that the driver could be optimised to run external, and perhaps more modern, hardware. Have you tried turning webgl off in the editor and seeing if that makes a difference to the laptop performance? On my older laptop I found even just having webgl on made a huge difference, even with no shader effects.

    That would still not explain why the driver is not running each screen the same. Perhaps it self-allocates more memory to running another monitor and that just happens to be what node requires. If you can manually set how much memory the driver uses then, perhaps, increasing that might also help.

  • Telyko, that sounds a bit weird - I don't know why the monitor size should make any difference, but perhaps the required driver for the external monitor is is newer and better? Also, just out of interest, on the back of the jerky performance threads, was there a resolution change that went with running on the new monitor?