Construct3 should export to native.

Hi! i know its going to be long since we can hear anything regarding C3, but i wanted to make this post so the team behind Scirra understand how important is to export games to native, i understand that working with html5 is great because people are going to be like "oh is that html5? wow" but come on guys, we need things running at 60fps without having to do tons and tons of effort for the perfomance of a simple platformer game (thats was an example)

This issue has been gone over extensively, and in short Ashley has said that adding native exporting would be a whole lot of work for much less benefit than people tend to assume. It wouldn't necessarily fix the performance problems you're talking about.

Hi! i know its going to be long since we can hear anything regarding C3, but i wanted to make this post so the team behind Scirra understand how important is to export games to native, i understand that working with html5 is great because people are going to be like "oh is that html5? wow" but come on guys, we need things running at 60fps without having to do tons and tons of effort for the perfomance of a simple platformer game (thats was an example)

hi

1 - there is no team is just one guy (and sometimes 2 guy) making c3

2 - there is no native export, why ?

native export means they have to change all html5 engine to native engain and for native they must support each platform

and since there is no team so there is no native performance !

Not this again.

Nope, no, not again. There has been tons of posts about this request and it always comes back to this: Construct 3 WILL NOT have native export. Ashley expained it well why they'll stick with HTML5. If you want native export, you'll have to use a different engine.

I'd love native exporters too, but as everyone said, it is outside of the possibilities.

I've written a lot of reasons for this in the past which you can go look up (really tired of repeating it all). But since you mention performance, I will bring up again that a lot of reported performance issues are hardware limitations. Those cases will be no faster with a native engine. Example: a game is slow on a laptop with a weak integrated Intel HD graphics chip. I investigate, and it's hitting the GPU fillrate hard, so the bottleneck is in hardware. A native app would have exactly the same performance problem, because it's the same hardware. Then the user asks for native exporters without understanding it won't help at all. I see a lot of this.

Ashley

I do agree with your points, most of them.

However, any focus on a functional export option for the market market of games? ie. Consoles like Xbone/PS4.

As for the Intel HD graphics situation, in my game test cases, it's not specifically a fill-rate or hardware performance issue. It's a WebGL issue, or rather, Intel's poor performance with many of the shader effects within C2. Removing those effects, game performance is FINE. Same game, with and without a few shader effects, goes from stutter mess to smooth performance on a HD4000.

From what I read, it seems likely Xbox One could support independently published Windows 10 apps in the near future, which would solve that. The recent Xbox system update means C2 games run well in the Edge browser on the Xbox which is very promising. So I think there's no need for a native exporter to cover Xbox. PS4 is trickier, I'm not sure what will happen there. I've read the main menu uses WebGL so it seems they have the browser tech there! But so far there has been no indications of it being supported. Given the huge engineering challenge, ongoing maintenance difficulties, and incompatibility problems, if we did it at all, it would be extremely expensive. I'd rather see an Xbox-style solution on the PS4, which means we could provide it cheaply and easily.

As for the Intel HD graphics situation, in my game test cases, it's not specifically a fill-rate or hardware performance issue. It's a WebGL issue, or rather, Intel's poor performance with many of the shader effects within C2. Removing those effects, game performance is FINE. Same game, with and without a few shader effects, goes from stutter mess to smooth performance on a HD4000.

That's not WebGL's fault, it's exactly what I was talking about, just weak hardware. You'd see exactly the same performance characteristics with those effects in a native app. You can assume WebGL performance is identical to a native app using OpenGL.

I dont want to promote this thread really as it has been done to death. Just one point i would like to make is this. At the moment we rely on NW.js for the desktop. Now i know the latest version 13. whatever is still in beta so we can expect problems, however it would be really positive if Scirra could somehow create a Fork or even produce their own wrapper. Exports would still be HTML but at least we wouldnt be tied to a third party for the desktop. NW.js has been in beta for ages and who knows it could be dropped at any time then where would we be?

As far as i see this is not a request for a native export, rather a Scirra controlled wrapper.

> As for the Intel HD graphics situation, in my game test cases, it's not specifically a fill-rate or hardware performance issue. It's a WebGL issue, or rather, Intel's poor performance with many of the shader effects within C2. Removing those effects, game performance is FINE. Same game, with and without a few shader effects, goes from stutter mess to smooth performance on a HD4000.

>

That's not WebGL's fault, it's exactly what I was talking about, just weak hardware. You'd see exactly the same performance characteristics with those effects in a native app. You can assume WebGL performance is identical to a native app using OpenGL.

I'm not saying that it's WebGL's fault.

I'm saying it's Intel's fault, either hardware or drivers, but its very slow at processing shaders that are based on OpenGL.

It's nothing to do with fill-rate, it's specifically WebGL shader limited and if people who use C2 knows this, then they should design their game to not use effects or do not target Intel HD graphics at all. It's a limitation regardless of who's at fault.

I dont want to promote this thread really as it has been done to death. Just one point i would like to make is this. At the moment we rely on NW.js for the desktop. Now i know the latest version 13. whatever is still in beta so we can expect problems, however it would be really positive if Scirra could somehow create a Fork or even produce their own wrapper. Exports would still be HTML but at least we wouldnt be tied to a third party for the desktop. NW.js has been in beta for ages and who knows it could be dropped at any time then where would we be?

As far as i see this is not a request for a native export, rather a Scirra controlled wrapper.

I'd love to see a comment on this as well. Maybe I'm naive and don't understand how much work goes in to NW.js but Scirra making their own wrapper seems like a good idea...

Ashley has answered to this before. It seems to be a common request.

There are other wrappers than nw.js that serve as native wrappers. Some html5 games engines have switched to electron:

http://tangiblejs.com/posts/nw-js-electron-compared

The field is very dynamic and at some point a technology might become outdated. I think that the current strategy is good- to keep construct compatible with a wrapper, however not make it depend on it in order to work.

What I would love to see is some sort of a script that automatically downloads and installs the wrapper for the user when it has been selected for an export option for the first time.

I wish native previewing wasnt dependent on a localhost server too.

blurymind

There are indeed other wrappers. My point was that none of them are created or controlled by Scirra.