Ashley's Forum Posts

  • That dropdown only chooses the minimum version. It automatically sets the target version to Android 8 as required by the Play Store. So there should not be a problem publishing for Android 8, all exports already target it regardless of what minimum version you set.

  • In a windowed game, dropping a single frame isn't really unusual - the OS might have just scheduled a background thread or otherwise done something to take CPU time away from the game thread so it misses the 16ms v-sync deadline. Not much to be done about that and affects pretty much everything on the system. So a single missing frame probably isn't anything notable. However some other profiles have shown longer janks, e.g. the 68ms frame in an earlier profile is about 4 frames, which is probably something else, but I've not been able to observe that yet myself.

    For those affected, is it fixed in Canary? If so it's probably best just to wait it out...

  • Ashley Why would GC do any work at all?

    It's the normal operation of a GC. As long as the program is allocating any memory at all, there are things to clean up.

    Overall I just find it really ironic that the reason we left the native realm was to avoid driver issues

    Can we not do the kneejerk blame-HTML5-for-everything again? No technology is perfect, and I'm super glad we don't have to deal with native driver issues, where the issues are far worse and you can't even file a bug because they have no public trackers. Having Google accepting bug reports and being willing to help is a huge advantage of the platform, and we should use it. It's just another bug, and like other bugs, it'll get fixed.

    I created a bug report with Chrome here:

    https://bugs.chromium.org/p/chromium/issues/detail?id=881174

    This bug report only mentions the Android webview, so Google will only investigate it for the Android webview. If anyone is experiencing jank issues on other platforms, another issue should be filed.

    I spent a while profiling the Endless Runner template on a Win10 x64 system with a GTX 1060 card and couldn't see anything out of the ordinary. A profile showed it did occasionally skip a single frame, but that could just be something in background scheduling in the OS or driver.

  • In short, the answers are no and no. If something doesn't work, please file a bug report following all the guidelines. If you get a JavaScript error it should be straightforward to fix. If it doesn't show an error but just doesn't work the same, it can be harder to work out what's going on. If you follow the guide in the bug report information about reducing it to a minimal project for the bug report, that is a huge help.

  • The runtime has to run behaviors in some order. There's no fundamental way around this. The order you are getting is either:

    1) move 8direction

    2) bound to layout

    This means it bounds it to the layout after moving 8direction, which works as you want it to. Otherwise it's

    1) bound to layout (before it's moved)

    2) move 8direction (which could then move it outside the layout)

    This means the object can temporarily be left outside the layout, because 8direction moved it after it checked the bounds.

    The workaround is to change the order the behaviors run in, which you can do by rearranging the list.

  • I would rather choose a fix for this than awesome new C3 features.

    I must reiterate that our engine does not directly control things like v-sync scheduling, so there is probably nothing we can change in the engine to address it. You will get better results pursuing a good bug report with browser vendors.

  • I think everyone's jumped to conclusions on this. The profiles actually show that GC is not the cause. The profiles show a long frame, and only a tiny amount of time taken up by GC. For example the profile posted by TheRealDannyyy shows a frame taking 68ms, but GC only taking 8ms of that. Why didn't it schedule another frame in the remaining 60 ms? It looks like it could have done, because it wasn't busy doing GC, but it didn't. Right now we don't know why, but it is too early to blame GC, especially since it looks like GC finished quickly with plenty of time to spare.

    At 60 FPS there is 16ms per frame. A demo like 'endless runner' does a tiny amount of work per frame - let's be pessimistic and say it takes 4ms of time per frame. This leaves another 12ms idle while it waits for v-sync. The browser knows it has 12ms idle, so it does increments of GC work in that time, since it essentially hides the work in otherwise idle time so it doesn't affect performance. So an 8ms period of GC could be the GC working exactly as intended, doing increments of work in the idle time between frames. I don't think there's reason to be suspicious of any GC times under, say, 14ms.

    We don't know what's causing the jank yet, but it won't help anything to prematurely accusing GC without sufficient evidence. It could indeed end up being GC, but the evidence doesn't suggest anything out of the ordinary yet. This also means it's also definitely too early to insist on changes to the engine - especially since I've seen browser engineers specifically advising not to try to keep objects statically allocated, since it can actually prevent JavaScript engines better optimising code.

    Identifying the cause of issues is surprisingly complicated, which is alluded to in this blog post.

    As ever the best approach is to find a way to reliably reproduce the issue (to the best extent possible anyway), and the fact I can't reproduce it suggests it's a device or system specific issue, so we should probably start collecting system specs and look for patterns in specs where the issue can be reproduced.

  • I can't reproduce any issue on my system with Chrome 69 - it's perfectly smooth even in fullscreen, and there is no GC coming up in the profile at all. In the past jank issues have been more to do with the OS, graphics driver, or browser v-sync schedulers or compositors anyway. You could prove GC by using the performance timeline in Chrome and looking for what it's doing in the time periods when it janks - the sawtooth shape graph is normal for a garbage-collected language and doesn't itself prove anything.

    Citing articles from 2013 will be missing the past five year's worth of GC improvements in browsers: most of them are now generational, incremental and concurrent - specifically designed to avoid more than a few milliseconds of pause at any one time, specifically to guarantee a smooth uninterrupted 60FPS framerate. If they can't do that, it's probably a bug with the browser's GC.

    Either way - v-sync scheduling or GC - it's not something we directly control, so your best bet is to collect evidence identifying the GC (if it is), and file a clear bug report at crbug.com. There seems to be a tendency to post long, complaining forum threads on our forum when there's nothing much we can do about it - if you're actually serious about sorting it out, reporting issues to browser vendors is the way to go. In the past they've fixed similar issues quite promptly (e.g. this issue which they first submitted a patch for within 2 days).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It's best to file website issues here now: github.com/Scirra/Construct.net-website-bugs

  • The engine does it for you automatically.

  • Have you tried it? You could just make a quick test and check.

  • I'm not convinced the idea of "easy as Construct but with 3D" makes sense. For 2D, most people can draw some basic images and do a bit of simple math to help things interact. With 3D, how many people can quickly throw together a 3D model? How's your math for things like vectors, matrices and quaternions? The bar is higher, and I'm not sure there's much an easy-to-use tool can do to hide that, without turning in to a bit of a disappointing cookie-cutter engine.

  • That version of Chrome is over two years old. It's the last version for XP and Vista, both of which are now out of support - they're not even getting security updates any more, so will be getting less and less secure to use. Nobody supports them any more, and I'm afraid neither will we.

  • The Custom Movement behavior does expose the various tools used for the algorithm, hence using it as a workaround.

  • Which browser and version are you using? It correctly detects support for me in the latest Chrome, Firefox and Edge.