Ashley's Forum Posts

  • We had already established that some specific devices seemed to have performance issues, so this does not seem to be anything new. Since we don't have every Android device ever made it's difficult for us to test, which is why we advise to file an issue at crbug.com describing the device and the performance measurements.

    gpuultilization showing NaN means the device does not support GPU profiling, not that it doesn't support GPU rendering at all.

  • I'm not really clear what the problem is from your post, but I tried loading the web link and it appeared to load and run OK in Chrome. However if you press F12 and check the browser console, some resources are failing to load with a 403 Forbidden error from the server, which suggests a configuration problem with the server, or perhaps you didn't upload all the files.

  • I ran both demos on a Pixel 3 and both cases appeared to perform identically. The test does not do anything performance intensive, so it's probably not really useful for testing performance differences anyway.

  • I think it´s sad that it requires complicated porting in the first place, rather than a modern console simply supporting HTML5 with perhaps some sort of wrapper.

    Well, that's exactly what the built-in Xbox exporter does, and as I said it seems nobody uses it...

  • As I noted here, the C3 runtime does not work on older versions of iOS, and iOS 12+ covers almost all devices anyway.

  • The C3 runtime does not support iOS 11 and older. (We could have actually supported iOS 11, but bugs in iOS prevented that.)

    Apple's official stats show that iOS 12+ covers the vast majority of devices, and as time passes this will of course cover an increasing share of devices as old ones are replaced.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Construct does have a built-in export to Xbox One. And, as far as I can tell, virtually nobody uses it. Posts like this are always a little mystifying to me: we do actually support this for Xbox One, but it's not mentioned at all by anyone - everyone acts as if there's no console support whatsoever.

    My best guess is everyone already uses third-party porting services. And if you're using a porting service for, say, PS4 and Switch support, it's probably actually easier to get them to cover Xbox while they're at it. Hence, nobody is using the built-in option.

    I'm greatly concerned that we could do months or even years of extremely costly work and then still nobody would use the console option at all, because people have basically found a workaround in the porting services and will just carry on using them. I think the console makers are also fine with high barriers to entry: they want to make sure only high-quality content that can jump the hurdles gets on to their stores. Also if consoles don't have built-in support for HTML5 games, then given our dependence on browser technology, creating a highly compatible engine port is borderline infeasible, amounting to writing a significant chunk of a browser, which is normally done by huge corporations with thousands of staff. AFAIK, the third-party porting companies are just maintaining compatible subsets of the engine, and do bespoke work per-project to adapt them to work.

    The existing Xbox One support is based on JavaScript UWP apps, and as far as I can tell Microsoft are actually trying to slowly phase those out. So with such little usage, an apparent lack of on-going support, and the apparent failure for this option to even enter the conversation, I'm more inclined to remove this option and allow everyone to use third-party porting services instead. I would guess our efforts would be much better spent helping make life easier for the porting services - but so far they seem to be getting along fine without needing much from us.

  • It's just a normal class, you can do anything you like with it.

    The only reason it's written like that normally is to avoid duplicating code. By privately forwarding all calls to the main instance class, you can easily share methods between ACEs, script interfaces, the debugger, etc.

  • You do not have permission to view this post

  • I'd point out that, much like with our own bug reports, it will be much easier for the issue to be dealt with if you can share a public demo. A bug report may be handed off between multiple developers and teams before it's even assigned to someone - that works smoothly with public details, but if it's private, that process can become slow and complicated.

  • It seems to run perfectly smoothly for me on a Pixel 3.

    Usually if you have device-specific performance issues, it's something involving the system GPU driver. The best way to investigate that would be to file an issue to Google at crbug.com so they can investigate.

  • The console is showing connection lost errors. I tried another build and it worked fine with no connection lost errors. This suggests there's some kind of problem with the internet connection between you and the build server.

  • I had a quick look at this and there is actually a bug in Chrome that causes a problem in playable ads when using module scripts. I reported it to Google and they'll need to fix it. In the mean time it's best to switch the scripts type back to "Classic".

    I tried to work around this for the next release, but the restrictions on playable ads is so extreme, we basically have no good options to explore. I think playable ads can actually work with a zip of a HTML5 export, so you could try that as an alternative. The Facebook playable ad preview tool also seems pretty broken, so it's really hard to test this. I previously repeatedly tried to get them to fix it and they completely ignored me, so I'm not sure if the preview tool will ever really work...

  • I just tried an Xcode export and it worked fine. Maybe check your Internet connection is working.