Ashley's Forum Posts

  • Thanks. So as things stand:

    Broken

    • Honor 9 Lite: Mali-T830 MP2
    • Alcatel A5 LED: Mali-T720MP3
    • LG K10 (2017): Mali-T860MP2
    • Samsung Galaxy Tab S2 (SM-T710): Mali-T760 MP6

    Working

    • OnePlus 5T: Adreno 540
    • Oneplus 6: Adreno 630
    • Motorola G6: Adreno 506
    • Pixel 3: Adreno 630

    The Mali theory is looking good. Can someone make a minimal project that demonstrates the problem on a Mali device?

    (edited to add new device results)

  • Crosswalk was retired 2 years ago. The Intel XDK build service was retired over a year ago too.

  • TheScythe - do you have a specific model number to identify the variant of the K10? I looked up the stats and the GPU it uses depends on the variant (which presumably depends on the market region).

    So judging by the information in this thread and looking up device GPUs on gsmarena, we have results something like this:

    Honor 9 Lite: Mali-T830 MP2 - broken

    Alcatel A5 LED: Mali-T720MP3 - broken

    OnePlus 5T: Adreno 540 - working

    LG K10 (2016): Adreno 306 - K420N; Mali-T720MP3 - K430DS, K430DSF, K430DSY

    LG K10 (2017): Mali-T860MP2

    At least one of the K10 variants above broken

    It's not a lot of data to go on, but it would make sense if this is a GPU driver bug in Mali GPUs affecting OpenGL ES 3 (WebGL 2). The more devices we can test and get results on, the better. So if anyone else can test on additional devices and let us know if it works or not, that would be helpful. Then we can look up the specs and see if there's a correlation with the GPU.

    We have data indicating ~50% of Android devices use Mali GPUs, so blacklisting anything with "Mali" in the GPU name from using WebGL 2 would have a high impact. I think the best approach would be if someone can produce the most minimal project possible that demonstrates the issue and then file a bug with Google with our device testing results and see if they can get to the bottom of it.

    For the record I edited the thread title to better reflect what we're trying to do here.

  • Hmm, it's a shame but the only thing I can think to do is disable WebGL 2 in Cordova apps on Android (again). Previously we had WebGL 2 always disabled on Android (including in web exports), but I don't think there have been any reports of issues in browsers, only Cordova (i.e. Android webview). So at least we could narrow down the WebGL 2 disabled to only affecting Cordova instead of all Android. But I can't see any way we can narrow this down any more - I thought it might only affect specific plugins (particularly admob), but that seems not to be the case, and I really don't want us to have to maintain our own WebGL 2 device blacklist, so I think that's the best we can do...

    I can't see anything that would meaningfully change the Android Webview WebGL 2 support in the long term either, so this may become effectively a permanent workaround. I guess we could try again in say a year, and hope drivers have been updated (when Android famously never gets updated); or if Chrome ever moves to a Vulkan-backed WebGL 2 implementation we could try again with that.

  • Please file a bug report following all the guidelines - we need all that information to be able to help.

  • Does it work OK if you remove Mobile Advert?

  • boulerzzz - does the project use Mobile Advert (admob ads)?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • To be able to diagnose this problem it's very important to have comprehensive information: the device model, device manufacturer, Android version, and the type of export (Cordova or web) are all essential. Without this we can only guess what to do about this.

  • When exporting with 135.2, the project worked as expected. But on 137, I got black screens when changing layouts.

    Could you check r136? The WebGL 2 change was made after that release for r137, so this would help narrow it down to that.

  • I don't know, I don't speak Serbian. It's up to your judgement how to translate terms. However the purpose of translations is so that somebody with no knowledge of English at all can still reasonably use the software, so in general I think it's best to translate, except where there is a de-facto English term that is still used as-is.

    Also expression translations require that there is no space, as described in the translation guidelines.

  • Sorry, looks like an omission from the current docs. I'll try get the documentation on this finished soon.

  • This is covered in the manual entry on Pathfinding:

    Note all cells outside the layout area are always obstacles. Areas outside the layout area cannot be included in the pathfinding grid, since doing so would require an infinite amount of memory.

  • I think it's logical to conclude that the fault lies with nw.js - the screen recorder works with the vast majority of programs but not nw.js

    Nope. It's the job of screen recording software to be able to record the screen.

  • It's absolutely, 100% a problem with the screen recording software. It's not Construct's or NW.js's fault. If screen recording software can't record the screen, it's not doing what it says on the tin. Their software is broken. If they claim it's not their fault, they are being negligent.

  • Electron uses the same browser engine as NW.js. I don't know why it would work differently with screen recorders - perhaps they disable the GPU process, which might degrade performance. You can do that with NW.js anyway if you pass the --in-process-gpu flag. Still, as I said before, it's a bug in the screen recording software if it can't record your screen.

    BTW the latest C3 releases include the Game Recorder object which has a built-in screen recording feature... which always works!