Ashley's Forum Posts

  • The log showed it was using the Chrome 69 browser engine, which was released in 2018. All you should need to do is install app updates so either Chrome or the Android System Webview app updates, and it should work. I've no idea how a device could have gone so long without a routine app update.

  • It looks like the devices have out-of-date software. For example the 7.1 device appears to not have had any update since 2018. Check for app updates and system updates on those devices, and it should start working.

  • I regularly test APKs on different devices, and I've never seen what you describe. Perhaps it's a problem with the emulator, or a specific device. It's hard to help without more details such as the Construct project and details about the specific devices tested.

  • I guess I was hoping there would be a path for a Construct user to implement their own game on a console. But rather you seem to imply that Construct users should just hire third party people to help get their games on consoles. I would rather do this myself, but I literally don't even know where to begin or if it's even feasible - is this something I could do?

    In short, no, it's not feasible for an individual Construct user to do. You'd need a small team of C++ experts with console development experience, an in-depth knowledge of the Construct engine, and probably a year or two of full-time work to develop an engine. The porting companies already have all of that and already spent a couple of years developing existing C++ codebases that are ready to go now. So it's far easier to get them to use their existing codebase and expertise.

    Good games take a long while to make, which may be why you haven't seen much usage.

    It's been supported since 2017, so over 3 years now. I'd expect to have seen results by now. Don't worry, we will definitely have a phase-out period if we do remove it (as we do when removing any feature), but I'd advise to plan on using the porting services instead anyway, which is more or less the de-facto approach now anyway.

  • If it's slow to load, I would guess the server is just slow. I don't know how your server is configured and it depends on your host too, so I'm afraid I can't help you any further with this. Try contacting your host for support.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

  • 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