Ashley's Forum Posts

  • That demo does a CPU-side throttling, it just wastes CPU time to hit 45 FPS. It's a bit weird, it looks juddery but relatively smooth in Chrome stable, but in Canary when throttled it seems to look even worse.

    20-24ms isn't a very big range in dt, it's probably normal. The Airscape log had a much bigger variation (19-41ms).

  • File a bug report following all the guidelines.

  • The Intel Graphics driver is from 2010, which probably means it's been blacklisted. In dual GPU systems you need to update the driver for both GPUs, so you have two drivers. Try heading to Intel's site and installing the latest Intel graphics driver from there as well as the latest nVidia one.

  • What does chrome://gpu say?

  • No, it doesn't matter whether anything is in a family, it only matters what is drawn and in which order. For more information see this blog post on the WebGL renderer.

  • Actually maybe I was wrong:

    http://www.scirra.com/labs/bugs/fpstest.html

    In this minimal demo on my laptop dt is still pretty stable even after throttling it to ~45FPS. There was a bigger variation on Android though. Maybe it's system specific.

  • Upload a .capx

  • I think the Airscape log confirms my theory. Part of it has a dt sequence with these measurements:

    31ms, 25ms, 41ms, 20ms, 31ms, 19ms, 35ms

    There is variation from 19ms to 41ms - over double. This is really uneven frame scheduling and probably explains why it looks so bad, it's a totally unpredictable framerate frequency. I would expect frame-by-frame the actual CPU/GPU workloads are almost identical, unless you have significantly intensive events coded to run every other frame or every N frames. Assuming even workloads for each frame, this is probably bad scheduling by the browser.

    At 37 FPS each frame is probably taking about 27ms to process, while the screen is drawn every 16.7 ms. If I write out how this is being scheduled...

    Vsync 1: 16.7ms (skip)

    Vsync 2: 33.3ms (render frame 1)

    Vsync 3: 50ms (skip)

    Vsync 4: 66.7ms (render frame 2)

    Vsync 5: 83.3ms (skip)

    Vsync 6: 100ms (render frame 3)

    Vsync 7: 116.7ms (render frame 4)

    Vsync 8: 133.3ms (skip)

    Vsync 9: 150ms (render frame 5)

    Vsync 10: 166.7ms (render frame 6)

    Vsync 11: 183.3ms (skip)

    Vsync 12: 200ms (skip)

    Vsync 13: 216.7ms (render frame 7)

    See how it's alternating between rendering two adjacent frames 16ms apart (e.g. render frames 3 + 4) and skipping two adjacent frames (e.g. render frames 6 and 7, which end up falling about 50ms apart!). No wonder it looks bad, that's like switching between 60 FPS and 20 FPS every few frames.

    This needs to be solved on the browser side, I think. It looks like when each frame takes longer than a Vsync period to process then it starts aliasing really badly against the refresh rate. The only sensible alternative is to have the browser drop it right down to 30 FPS, which is a lower rate but at least looks predictable. I'll see if I can make a demo and file a bug report for Chrome...

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • Arne - yes, you can install betas next to stable releases, just choose a different install directory and don't uninstall when given the option.

  • "On Start of Layout > Set BackGround Image to WindowWidth /2, WindowHeight /2

    That's a classic mistake. If your intent is to place it in the middle of the viewport, then the correct expressions are:

    (ViewportLeft("layer") + ViewportRight("layer")) / 2

    (ViewportTop("layer") + ViewportBottom("layer")) / 2

    OzairP - the quickest way to get help is to share your .capx so we can directly see what you've done. Otherwise all we can do is speculate. There are a great many ways you could get the result you've shown.

  • Checked mode has a performance overhead, so it's deliberately turned off for stable releases. You should just make sure you test with beta releases.

  • I wouldn't expect the bandwidth use to be deterministic. Expect variations even for identical runs.

    Retransmissions happen at the OS layer and won't be counted by C2's stats. That just tells you how much it tried to send and how much it finally received, not counting whether one of those packets had to be retransmitted 10 times, or even if it got lost completely (it still will have counted the outbound bandwidth because it passed it to the OS network layer).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads