Native Desktop Exporter for Construct 3

michael

What language would you want Construct 3 to be in? I'd like C++ or C# or maybe even Python (That last one is a joke )!

C3 will be what it will be, and I do not think we have a choice in that, nor they have any obligation at all, if C3 is an "upgrade to C2" and that does not convince you, just do not buy it, ashley choice for C2 was html5 only, and while some people see it as a bad choice, they are native engines so buying an html5 one is not something you should have done, ok, there are hiccups in the marketing, but for C3, there should be not the same confusion.

michael

What language would you want Construct 3 to be in? I'd like C++ or C# or maybe even Python!

Nesteris

Well, I come from a .net background, making software for personal use, but don't really consider myself a proficient coder. Hence my use of C2 for games.

I have pledged to FPSC Reloaded, and find scripting interesting, but just starting to play with that. Maybe that could be C3 feature: code with events or script, whatever is your thing.

I would just like to see a game tool with the versatility and ease of use that C2 is renowned for, but doesn't rely on third parties who most likely don't care if their work breaks yours, and if they do, don't put as top priority to fix.

For example the chome jank bug that completely broke html5 games. With the size of Google, that bug should have been fixed within a week, but it took many months and still isn't flawless. The only conclusion is: they couldn't care less!

C3 will be what it will be, and I do not think we have a choice in that, nor they have any obligation at all, if C3 is an "upgrade to C2" and that does not convince you, just do not buy it, ashley choice for C2 was html5 only, and while some people see it as a bad choice, they are native engines so buying an html5 one is not something you should have done, ok, there are hiccups in the marketing, but for C3, there should be not the same confusion.

Aphrodite, again I agree for the most part. I bought C2 knowing exactlty what it is, and certainly do not regret that.

I also agree that Scirra can and should do what they think is the best course for Scirra, and whatever they do end up doing, I will be in it.

But at the same time, there is no harm in voicing our honest opinions about the direction we would like C3 to take - even though I doubt if my rants will be taken into account by scirra.

But all is good, not complaining, just voicing what many are thinking.

michael I realise that here, but I know that this subject is prone to polemic, and most people (not that they stay long on those forums)seem to show it like they were forced to use html5 to C2, and I do not want to see this happening with C3.

C3 will be what it will be, and I do not think we have a choice in that, nor they have any obligation at all, if C3 is an "upgrade to C2" and that does not convince you, just do not buy it, ashley choice for C2 was html5 only, and while some people see it as a bad choice, they are native engines so buying an html5 one is not something you should have done, ok, there are hiccups in the marketing, but for C3, there should be not the same confusion.

As a forum this is very much a place of discussion. You are essentially telling people to shut up, which is hardly ever constructive. Of course Scirra is not obligated by anything requested here or elsewhere.

Like michael also said I never actually had any regret about purchasing Construct 2. However I would like to be so bold to assert that back when C2 was still in its infancy, the majority of the userbase coming from Classic had no real concept of how things would turn out with HTML5. You basically had to decide whether to give it a shot or turn your back, which you were unlikely to do given your previous investment in Construct.

That's why you might be seeing longtime users (and others)now with their pleas for native stuff. Just to give a little perspective here.

Webgl effects

...are run by the GPU and are no faster in a native engine...

[quote:10sef4d2]instance creation/destruction

In this kind of discussion I always repeatedly ask for demonstrations of anything which needs optimising. This kind of thing can be improved, but instead of people showing examples and giving me the opportunity to improve it, they just demand a completely new native engine instead. Can you come up with an example showing some kind of performance problem here so I can profile it and do any necessary optimisation work?

[quote:10sef4d2]as well as resizing/scaling

That is also run by the GPU and no faster in a native engine.

[quote:10sef4d2]Also I'd like to point out that a blacklisted device might have no problem at all with a native engine.

No, instead the game will inexplicably crash on entire model ranges of certain devices. This even happens on desktop, and has been a problem with the Construct 2 editor itself in the past. That's why the browser vendors blacklist the GPU and work around it with a software renderer, since a slow working game is better than a fast one that crashes.

I find this frustrating because this is always the pattern with people asking for a native engine: they talk about performance problems without showing anything I can investigate, and then assume everything will be perfect when in fact you trade off performance for portability and probably reliability. By far, the best solution is to improve C2's engine to resolve any performance deficiencies. That to me is obviously at least worth significant effort before deciding it's hopeless and writing a native port. But we are a long way from determining that it is hopeless, and nobody is showing me any evidence to work with either, so what can I do? We're not about to rewrite our engine five times over in native tech based on a hunch.

It's not necessarily performance or features that make a native exporter desirable, it's the reliability. As stated earlier, NW & Chrome (the most popular platform afaic) often introduce game breaking bugs in-between updates and there's literally nothing anyone here can do about it. We just have to wait. Every time. Frankly it makes people hesitant to use C2..at least for medium/large-scale projects. I know native exporters are not practical though so I stopped asking for them. Makes me wonder how many other people just decided to use a different engine though.

If you want to get picky, then get some numbers, like what's the most profitable platform?

Should they shoot for an exporter to whatever that is?

Pretty sure most are not going to like the answer.

newt http://arstechnica.com/gaming/2014/04/a ... le-gaming/ ? <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz"> Although, even if it was iPhone that was the most profitable (for games, don't count apps or then you would have a tough time calculating PC software sales too <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz"> ), then I'd love a built-in exporter for that. The more exporters that Scirra has full control over the better, even if they just paid someone making an open source thing to work on a C2 plugin full-time so it's always up to date and functional.

The Z-sorting on C2 was definitely much slower than CC and so I've stopped using it, and it did not support scaling along the Z axis like CC did, it'd be cool if C3 did that.

Also with Node-Webkit: We're having issues with changing resolution and monitor refresh rates in-game, which locks the game to a lower Hz for some players, we also have had many performance issues that turned out to be because Node Webkit had an update or because C2 changed version of NW.

As for people not sharing files demonstrating the slowness, it's because the slowness isn't just in one part of the game or something small enough to demonstrate alone. By the time your game gets large enough to really notice you might be nearly done a commercial game that you'd require lawyers and contracts to even think of sending the source code to someone else. Plus, they'll be sending you what they've already optimized and removed elements (that they wanted in the game) by that point as well if their game project is already released. Although it's true that there's a better way to optimize code most of the time, it's not just events that hurt performance.

The bottom line for desktop export is that the fans have often noticed and reported even minor slowdowns or "janks" and you can't tell the customer "Sorry it's a 3rd party exporter" or "We're just waiting for the engine to update version of a third party exporter". They don't care, and that's what sets a bad image for the devs, then C2, and then all of us and Scirra. We're all hurt by this.

[quote:27xutvll]C3 will be what it will be, and I do not think we have a choice in that, nor they have any obligation at all, if C3 is an "upgrade to C2" and that does not convince you, just do not buy it, ashley choice for C2 was html5 only, and while some people see it as a bad choice, they are native engines so buying an html5 one is not something you should have done, ok, there are hiccups in the marketing, but for C3, there should be not the same confusion.

I don't see why you're talking about people complaining about HTML5 here. Personally I have no problem with HTML5, it lets me create games and that's all that matters to me. I just don't see the point in making Construct 3 another HTML5 engine since there's already Construct 2 for that, even if it is going to have major changes, put it in an update, I'd hate to see our purchases rendered moot.

[quote:27xutvll] when in fact you trade off performance for portability and probably reliability. By far, the best solution is to improve C2's engine to resolve any performance deficiencies.

Currently, I don't see any of the games on the Construct 2 front page being made for anything other than PC, with the exception of 'Mortar Mellon'. You can improve C2's engine to resolve all the performance deficiencies all you like, if wrappers like Node-Webkit just release more broken builds like with the jank that's still not fully resolved, that will leave us with a perfectly fine and amazing engine that cannot export any normally functioning games due to non-Scirra companies releasing broken software or possibly even abandoning it.

Ashley, I want to ask you a serious question. What would you have done if, after Google release the Node-Webkit with the jank and all the horrible performance, they shut down and stopped making new Node-Webkit builds and fixes?

We would be left with a broken exporter and basically all C2 users who want to export to computers would be furious, then you'd be forced to make a native exporter either way. We all know how many posts and a couple bug reports were made on just that one "update", imagine if that build was the last we got forever.

I know it didn't happen, but what if it did?

There is a thing as future proofing. In fact, if there was a native Construct 2 .exe exporter or similar, C2 users themselves could probably provide fixes for it just as they provide plugins and effects for the engine.

Construct 2 is great HTML5 game maker, but it gives 0% certainty that your game will work smooth on desktop or mobile. And if you will complain you will hear some random words about waiting for better future, upvoting bug reports and so on. Chromium/Node-Webkit/Crosswalk issues are the best examples. And that's why C2 is just a nice toy for newbies and education projects in primary schools.

> Webgl effects

>

...are run by the GPU and are no faster in a native engine...

[quote:yt09h7m3]instance creation/destruction

In this kind of discussion I always repeatedly ask for demonstrations of anything which needs optimising. This kind of thing can be improved, but instead of people showing examples and giving me the opportunity to improve it, they just demand a completely new native engine instead. Can you come up with an example showing some kind of performance problem here so I can profile it and do any necessary optimisation work?

[quote:yt09h7m3]as well as resizing/scaling

That is also run by the GPU and no faster in a native engine.

I'm sure you are very right about what you are saying in theory here.

However a simple test that creates a sprite with semitransparency at a random angle every tick, which also grows every tick by the factor 1.1 is already down to 30fps for my system when it reaches about 1000 instances. Using the very same sprite and the equivalent events in Classic runs still at a steady 60 fps with 1000 instances and beyond.

I'm not going to hide the fact that my observations are just that, coming from every day use. I didn't scientificly look into the issues to be clear.

I find this frustrating because this is always the pattern with people asking for a native engine: they talk about performance problems without showing anything I can investigate, and then assume everything will be perfect when in fact you trade off performance for portability and probably reliability. By far, the best solution is to improve C2's engine to resolve any performance deficiencies. That to me is obviously at least worth significant effort before deciding it's hopeless and writing a native port. But we are a long way from determining that it is hopeless, and nobody is showing me any evidence to work with either, so what can I do? We're not about to rewrite our engine five times over in native tech based on a hunch.

It is far from my intentions to frustrate you in any way. I do appreciate that you weighed in and replied multiple times in this thread. Please keep in mind that I specifically stated in this very thread that I'm NOT asking a native exporter of Scirra.

What I didn't specifically state though (not in this thread anyway) is the trouble with relying on third parties in general. However others did repeatedly. So yeah, I was merely saying something along the lines of "Wouldn't it be cool if someone made a native Windows exporter?!". And then it blew a little bit up.

What I really got from this though is an ever increasing interest in asm.js.

Gotta agree that Classic was WAY more efficient when it came to sprites - you could easily have, like, 60000 of them bad boys on screen with no slowdown - C2 doesn't come close. So it is a little strange to hear how the playing field is basically level for both of them.

https://developer.mozilla.org/en-US/Fir ... top_client

lol