Ashley's Forum Posts

  • BB and Windows Phone are defunct platforms. The Windows Store exporter covers UWP and Xbox Live and is still supported.

  • > Regarding the polygon object suggestion. Didn't Construct Classic support pixel based collisions, couldn't the code for that be ported?

    >

    > I know it was more of a "hack" back then but I guess if it works, it works.

    That's why we have polygon, per point is way too slow for html5.

    I don't think that's the case any more, especially with WebAssembly. The main reasons for polygon collisions are:

    • it's simpler
    • easier for user to edit
    • likely faster than per-pixel checks (regardless of implementation)
    • other parts of the engine need a polygon e.g. Physics & ShadowLight, so you need a polygon anyway. So you may as well use the polygon for collisions too.
    • per-pixel collision was extremely difficult to get right in Classic - lots of difficult bugs, even years down the line when we thought it was mature, and often the bugs crashed the game or corrupted memory
    • if there are N collision systems, you need N^2 algorithms, because every type of collision has to be able to collide with every other type of collision. Adding new collision types becomes exponentially more work, which is a very good reason to only support one, or the very fewest possible. (E.g. if you add per pixel collisions, we'll also need poly-pixel intersection tests, which means rasterising polygons to a bitmap... lots of tough code to write there, and carries opportunity cost accordingly)
    • I've always asked for, but never seen, a convincing case where something really definitely needs per-pixel collisions and just can't be done with polygon collisions. So as far as I can tell polygon collisions are perfectly sufficient for game design purposes.

    As is typical with designing complex software, there's a lot more to it than performance or "just port the old one".

  • There was an issue with the TURN server that iOS devices have to use. It should now be fixed and working again. Apologies for the inconvenience.

  • The new C3 runtime has huge performance boosts over the old C2 runtime. See this blog for more information.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Non-square images have always been OK. I think you're getting confused by power-of-two size restrictions. Those basically don't matter any more either.

  • Why do you want them? They're all defunct platforms.

  • Construct 2 project have cli-6.2

    Construct 2 projects don't specify a version. They will use the default, unless you edit config.xml to specify a specific Cordova version.

  • Please file a bug following all the guidelines. If you don't want to share the project send it to ashleyhpl@scirra.com and I'll take a look.

  • If you make all the layers transparent then the canvas will have transparent areas that can show elements beneath it.

  • It's not currently supported in the offline editor. You can save your project as a .c3p and keep working in the browser version though.

  • The main reason is the forum is perpetually receiving a colossal amount of spam and the moderation process allows us to block almost all the spam posts from actually reaching the forum.

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