Ashley's Forum Posts

    • Post link icon

    For any issues with payment please contact supportzio@scirra.com.

  • Last I checked Sony did not release a gamepad driver for Windows, essentially deliberately not supporting PS4 controllers on Windows. So to support it out of the box I think the browser would need to reverse-engineer the controller driver, which might be a big job.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Updated links in original post with an update for Chromium 69.

  • That's fine, but can we at least get some support by Scirra team, confirming similar finds and raising issues in other places, about this?

    We can't be held responsible for the entire technology ecosystem. I discuss this in detail in my blog post Blame in technology, and the aardvark case.

    For example if nVidia's graphics driver crashes the system when playing a game, it's not our responsibility to investigate or diagnose the issue. It's nVidia's problem with nVidia's technology and the issue should be reported directly to them.

    Similarly, I'm afraid we are not responsibile for the way power management technology works in certain devices.

    Much larger companies might have the resources to investigate other company's technology for them - for example Google can afford to assign developers to investigate other company's driver bugs to help make sure the wider ecosystem is working as expected. They have mind-boggling budgets and thousands of engineers. Unfortunately we simply do not have the equivalent resources. We have three developers, and spending weeks researching other company's technologies will directly delay new features and bug fixes. Even if we still did it, there is likely nothing we could do about it anyway - we can't fix other company's technology for them. Sometimes this is just the nature of the beast, as I wrote about in that blog.

  • Ashley Do you have any suggestions on how to deal with this?

    This isn't anything to do with the Construct engine, so I don't think I can offer any advice. It seems like a similar problem to dual-GPU laptops generally defaulting to the weak GPU. The graphics vendor forces the user to choose.

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

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

  • The engine does it for you automatically.