Ashley's Forum Posts

  • Probably not - if you're using Brute image recompression that's probably 99% of the export time. If you want a quick export, skip minify and recompression.

  • There's a million third party services we could potentially integrate, but there's no way we'd ever have time to cover them all. It's best to get them to write their own plugin, which is what our Javascript SDK is for.

  • It's hard to address such a long article but some key points are:

    • it was written in 2013 and there *have* been big improvements since then anyway - such as just one improvement being the new FTL JIT in Safari based on native compiler technology
    • mobiles are always getting faster and more memory - 2GB devices are now common
    • modern browser GC is incremental, parallel and generational, designed not to cause frameskips
    • the C2 engine is GC optimised anyway: it tends to allocate what it needs, then continuously recycle the same objects, so there is never much garbage to clean up
    • very carefully written JS code can approach native speed within the body of a function. JS has overhead in between method calls and lookups on dynamic objects, but if you have a function body with local variables, fixed types and tight loops, there's no reason the JS engine can't JIT that nearly as well as if it were C code.
    • even performance-demanding games are often not actually CPU-bound at all, and bottlenecked on GPU rendering which happens at exactly the same performance as a native app, so faster JS execution would not actually help.

    I don't disagree with all of it - I don't really like garbage collectors and would prefer to write an engine with explicit control over memory and completely eliminate the possibility of pauses - but I don't think it's as bad as it makes it sound. Just the improvement since the article was written alone is cause to rethink it.

  • Closing, please follow the bug report guidelines. There is very little we can do without steps to reproduce.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • G-sync sounds interesting - it does sound more sensible to have the monitor to wait for a frame than to have the system rush to produce a frame on schedule!

  • I can't do the math to prove it properly, but FWIW I've found a proof by counter-example that A = lerp(A, B, dt) is not correct! It's a very good approximation, and in practice probably works OK, but consider this:

    In this case the remaining distance m after one frame is (1 - dt). The remaining distance after N frames is (1 - dt)^n.

    At N frames per second, dt is 1 / N. Therefore over one second at N frames per second, the remaining distance is (1 - (1/n))^n.

    You can prove this isn't exactly correct just by substituting n = 30 and n = 60 for 30 FPS and 60 FPS:

    (1 - (1/30)) ^ 30 ~= 0.36166

    (1 - (1/60)) ^ 60 ~= 0.36479 (different!)

    So there you go. It's a tiny difference and would probably never be at all noticable. But I think this proves the correct form is lerp(a, b, 1 - f ^ dt). Maybe this deserves a blog post...

  • I've no idea either. I don't think I can help without a code example.

  • Is this affecting your own plugin? Are you sure the code works with the minifier?

  • they don't give the same results on the same occuring times

    What do you mean by that? What did you test and what results did you get?

    I am gradually remembering that A = lerp(A, B, 1 - x ^ dt) was in fact a correct form. I think the maths was something like:

    Instead of considering how far you've gone, think about how far you have left to go. So if you want to jump 10% of the way there, that's the same as saying there's 90% of the way left to go after the jump, which is the same as multiplying the distance remaining by 0.9. Let's call that 'm'.

    So if you make multiple jumps, that's the same as multiplying the remaining distance by m multiple times, which is m^n.

    Remember that multiplying powers adds the power, i.e. m^a * m^b = m^(a+b). If we raise m to the power dt, then whatever number of multiplications happen over one second (i.e. the number of frames) always add up to 1. E.g.:

    At 4 FPS, dt will be 0.25, so the distance remaining is m^0.25 * m^0.25 * m^0.25 * m^0.25 = m^1.

    At 10 FPS, dt will be 0.1, so the distance remaining is m^0.1 * m^0.1 * m^0.1 * ... (10 times) = m^1.

    Both times, despite there being a different number of frames (multiplications), the distance remaining was reduced by the same factor m after one second.

    Therefore a formula like A = lerp(A, B, 1 - 0.5^dt) means "cover half the remaining distance every 1 second regardless of the framerate".

    Without doing the actual maths to prove it, I think Colludium has shown A = lerp(A, B, n * dt) is also correct. But I think the raise-to-power way is more predictable - the example I gave demonstrates how you can easily set it to cover half the distance every 1 second, but with just using n * dt, how do you choose n such that it covers half the distance every 1 second?

  • Mathematically speaking dt has no relation to specific framerates. A game correctly using dt will work the same (or at least very similarly) at any framerate. Nothing in the C2 engine hard-codes an assumed 60 Hz rate. If your game works twice as fast (or even just differently) at 120 Hz, that strongly suggests you are not using dt when you should be!

    I'd point out 'Every X seconds' should not use dt in its parameter. This has exactly the opposite effect of what you want. It is already framerate independent, and adding dt makes it framerate dependent, since:

    Every 5 * dt seconds

    10 FPS, dt = 0.1, runs every 0.5 seconds

    100 FPS, dt = 0.01, runs every 0.05 seconds

    It's broken! It now depends on the framerate. On the other hand "Every 5 seconds" runs every 5 seconds at any framerate. So it's simply wrong to use dt in 'Every'.

    An easy way to test your game for correct use of dt is to set the timescale to 0.1 and look for anything that is still running at the normal rate. In other words everything should be super-slo-mo, but if you missed dt somewhere then something will be happening way too quickly. It's exactly the same principle that keeps the game running at the same rate at 120 FPS as well (or even higher).

    I think A = lerp(A, B, x*dt) is correct, even with A changing every frame. I vaguely remember an alternative from the Construct Classic days of A = lerp(A, B, 1 - x ^ dt), but I can't remember the maths behind it, and some quick experimenting shows that both ways appear to compensate correctly for changes in the framerate although they provide slightly different interpolation curves.

  • Have you read the section on OS X in Exporting desktop apps with node-webkit?

  • Have you tried r195? We recently fixed a memory leak causing the editor to slow down over time.

  • MultipleChoice - I don't think your issue is related to this thread. This thread is basically about the v-sync quality of browsers, whereas your issue looks like it's to do with rounding in the C2 engine. You already posted a report for it here so it will be handled from there instead of this thread.

  • Closing, please follow the bug report guidelines (attach a .capx, etc)

  • I've never seen that, so I can't reproduce the problem, so I can't do anything to investigate. Try to find some particular action that causes it.