Ashley's Forum Posts

  • All the currently supported scripting APIs are documented in the scripting reference. For everything else, see the example on integrating events and script.

  • I would guess there's an issue with using dual-monitors with different refresh rates.

    The timing project showed times of 8.1 and 9.6 seconds, a ratio of about 1.185. The ratio of 75 Hz to 60 Hz is 1.25. It's not super close but the right ballpark, so I'd guess in this specific setup it's possible it ends up using frame times from a different display using a different refresh rate, resulting in the wrong speed. I'd speculate that if it was using frame times from the 75 Hz display (13.3ms frames) on the 60 Hz display (16.7ms frames), it would run slightly too slow.

    I'm sure this is not an issue with Construct since it will always work at the same speed providing it gets the right frame time measurements. I guess it's a Chrome bug, but it's difficult to see how this can be resolved - e.g. if you have the window displaying half-and-half on each display, what framerate should it run at? It's a weird setup and hard to know what it ought to do in that case.

  • That's bizarre, I've never seen anything like it. There must be some kind of hardware fault or maybe a bug with Chrome's frame scheduler or something. Construct uses the time between frames to advance the movement, so it doesn't matter what the framerate is. The only explanation is somehow it's measuring the time between frames incorrectly.

    Is that a dual-monitor setup with each display running at a different framerate? It's an unusual setup and might explain the odd behavior.

  • Moved to C3 scripting forum.

  • According to Apple's stats, 93% of all devices are using iOS 12+. By July 2021 iOS 14 will have been out for some time, so that number will have increased even more. I'd also add that the C3 runtime could have supported iOS 11 if there weren't such terrible iOS bugs in that version, so our inability to support that version of iOS is actually Apple's fault. Anyway with such broad support already and the fact it's only increasing, it's hard for us as a small team to justify keeping around tens of thousands of lines of ancient code just for a small and shrinking percentage of devices. I don't see why publishing a game to "only" 95%+ of devices is a problem; you'll never reach exactly 100% so you have to draw the line somewhere, and this seems reasonable.

    For Android, StatCounter have more up-to-date stats and they show Androd 5-6 support is at 17% and falling. As far as we are aware C3 games still run fine on the vast majority of these devices. They only need to have had a software update any time in the past ~3 years. There are various issues with Android having out-of-date software, buggy drivers, or other misconfiguration problems - this has always been the case, and in some cases they also stop C2 games running too. It's mainly because Android is kind of a mess, especially in the old versions. Again it's the same kind of story: these numbers are falling and will inevitably become irrelevant. Even if you published only for Android 7+ (which shouldn't be necessary), you'd still be covering over 80% of devices. There will always have been and always will be bugs and issues to deal with - once again we can't justify keeping around a huge amount of old code just because a small and shrinking number of old Android devices are misconfigured. Even if you set a fairly high minimum version, you can still cover the vast majority of all devices.

  • Neither of those settings affects the speed objects move at.

    • Post link icon

    The editor also tells you itself in several places you can get more events by logging in when using the free edition.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Well, the problem is you're assigning a number where it expects a string, which is breaking it. Make sure you convert the tickcount to a string and it should work. It looks like it's not reporting the error correctly though.

    You can file bugs here: https://github.com/Scirra/Construct-3-bugs - it would be useful to post this there so it's not lost on the forum.

  • It looks like it might be a bug. Can you post your project?

  • The very first thing to do is: press F12 and look for an error message in the browser console.

  • Most fractional calculations in computers are imprecise like this. It's literally the CPU circuitry that does this, so all software on all computers is affected.

    Does it matter? You're talking about a difference of 0.000004 pixels, which is far too small to be visible.

  • You should share projects, not videos. All I can do with a video is watch it, shrug, and say that shouldn't happen.

    It's a common mistake, so without any further evidence I can only assume it is a mistake in your project and it is doing something framerate-dependent by accident. You can still make behaviors work framerate dependently if you create incorrect events, like setting a speed to 500 * dt, which basically breaks it, since it makes a framerate-independent value become framerate-dependent.

  • I tried the APKs you sent and both ran perfectly smoothly on a Pixel 3.

    This is exactly what I expected. There's no need for these hacks any more with modern devices, they generally work just fine. In particular Crosswalk may well be slower - it was deprecated years ago so it's a years out-of-date browser engine missing loads of optimisations in modern browser engines, and it bloats the APK.

  • You've probably made framerate-dependent movement. See the tutorial delta-time and framerate independence.

  • You can use a folder-based project with source control tools like SVN. This tutorial explains how it works - it's written for C2 but it applies to C3 as well if you use its local folder saves.