Native Desktop Exporter for Construct 3

From Scirra's point of view, going with HTML5 is the only logical option. A native exporter would be a terrible idea in terms of return on investment, workload, etc.

From my point of view, I can't risk being reliant on Chrome and NW (and HTML5 in general) being functional. I can't afford to not be able to port to consoles. So I'll move to another engine for my next project.

Scirra can afford to lose people like myself as a customer. Keep in mind that a VERY high percentage of C2 users don't create commercial desktop/console products.

IMO they should just scrap support for large projects and focus on small/midscale projects, and rapid prototyping. It's admirable that they've been supportive of projects like mine for so long, and I'm hugely thankful for that! But in terms of what would be best for this engine, HTML5 is the only option. And at least for the near future, using HTML5 for a commercial-scale project will always be problematic (Except, as always, for special cases like non-performance intensive games, etc)

At the end of the day, for a commercial project, Unity and (apparently) GM are viable alternatives, and Scirra would be crazy to try and compete with those powerhouses directly, at least with the resources they have currently.

Don't use construct if you want native performance. If you want perfect performance write your game in assembly for every cpu architecture + gpu specific optimization.

I will get right on that. But I'm currently still busy replacing Windows with my own operating system, which is going to outperform it easily. The working title is "iCantCode OS".

Using a tool like construct you have to give up a lot of optimizations.

I honestly think people do realize this. But does a tool like Construct automatically have to rely on HTML5?

It is apparent that there is a part of the userbase that doesn't want to develop for mobiles and rather have something not taking too much control out of their hands while most likely performing better. I also don't think this is surprising in the least given the history of Construct.

I cannot quite see the harm in voicing that standpoint.

And yes, it is very understandable from a business perspective for Scirra to stick with HTML5. No doubt about it. This just about wraps up this thread for me personally.

I'd summarise my stance like this:

1. I've shown with benchmarks that JS/WebGL performance can come very close to native. It may not do so in all cases, but I think it is closer than people think.

2. The rate of improvement is incredible. When we started in 2011 there was no option for desktop export, the latest IE didn't run HTML5 games at all, and Chrome and Firefox could just about stagger along at 30 FPS even on a high end machine due to software rendering, and mobile was so far out of the question that we didn't actually have any plans for it at all. It's getting so much better so quickly that I think a native export for any platform could be a waste of time since by the time we finish writing it, the web platform will have caught up.

3. We now list previous versions of NW.js at https://www.scirra.com/nwjs, so nobody will ever be stuck with a particular version if it has bugs any more. We'll stay up to date with NW.js updates and if an update is broken, you can roll back easily from that page. The "jank" issue is just a Chrome bug we inherited, and should be fixed in due course, and is not some fundamental shortcoming of HTML5 (as IE11 demonstrates with its very good v-syncing).

4. I think it is a good thing we do not have to maintain NW.js or Crosswalk. This would be a tremendous burden on us also. Chromium is over 20 million lines of code and can take around a whole day to fully build. Maintaining that over 7+ platforms (Windows 32/64, Mac 32/64, Linux 32/64, Android) is a great deal of work and probably best left to Intel's engineers. Also, this probably would not actually be a big help anyway, since the jank bug came from changes made to Chromium by Google engineers, and we aren't going to watch 20m lines of code for breaking changes which Google can't spot themselves. The best solution is just to make old versions available for rollback, which we now do.

5. Working on native exporters is a colossal project and we probably would not be able to write any other features at all on a timescale of years, or possibly ever again, if the work maintaining so many codebases proves to be time consuming. I am confident C2 today would have a fraction of the features it does if we had the added burden of maintaining multiple codebases. Further, it would end up with ongoing portability headaches forever, and some users from other tools complain bitterly how they can never predict which features are available, or will work correctly, on which platforms. That is something I specifically want to avoid, and I do not believe anyone who says "it will be fine if there's just a few features that work on native", it will be an ongoing cause of pain to users indefinitely.

Given my perspective, I find it difficult to see why writing loads of native exporters is a better idea than improving what we already have to a native-equivalent point, which is definitely possible.

1. I've shown with benchmarks that JS/WebGL performance can come very close to native. It may not do so in all cases, but I think it is closer than people think.

Following from the previous - pure static object tests are all well and good, but games/apps mostly do some calculations as well - as requested I'm attaching the sort of thing where C2 can feel slower than CC would in the same situation.

It's quite amazing how well it runs in a browser already (although the (i3) CPU on this machine goes up like a rocket), but when I had made something similar in CC with several effects on top and sound and more sprites it was a good deal smoother (on a slower CPU). The biggest problem is perhaps not the lack of FPS, but jumps in fps every now and then. A dealbreaker for dynamic action games.

[attachment=0:1d0gffcq][/attachment:1d0gffcq]

Move the mouse around and click (just to see the movement - it lerps the values all the time anyway).

If I wanted to make a Geometry wars style of game in C2 and keep a certain level of graphical fidelity - doesn't seem likely (at least not on average hardware) - while on CC throwing crazy amounts of objects/particles around was the order of the day.

If this is the sort of thing that you talk about being able to analyse and improve - that would be great.

I'll have to agree on all accounts with Ashley on this subject.

Although in regards to console support, I really do hope that both Microsoft and Sony will embrace HTML5 and finally give us web game developers the opportunity to publish our games on next-gen consoles as well.

Ashley, are you in any kind of discussion with Microsoft at the moment given their recent statements?

Somebody , That's a very nice example!

I am impressed on how Chrome outperforms IE11 and Firefox by far!

On my machine, I get a maximum of 45fps when the mouse isn't moving, 30 fps when mouse is moving/clicked with Chrome.

On IE11 the numbers are 25 and 12. On Firefox is a stop motion show... 6 and 3 respectively.

All of the above on full-screen browsers that are running at 2560x1440.

On my machine, I get a maximum of 45fps

Now this in an interesting figure - in all my recent tests, be it shaders, sprites or whatever - this has been the top fps on chrome the moment something actually starts happening - even with a single sprite at times. It feels like Chrome "decides" it's going to have certain max fps and that's what you get - once again - not that great for action games.

Thanks for trying it, if you have a moment could you try this: https://dl.dropboxusercontent.com/u/132 ... index.html (Press/hold right) - another simple thing I get steady 45 fps on.

1. I've shown with benchmarks that JS/WebGL performance can come very close to native. It may not do so in all cases, but I think it is closer than people think.

It might be able to on your machine, but it entirely can't on mine ( see the bottom of this: for C2 running at 33% of the speed of CC! ). My machine *is* a little older, but it's not much different than the average machine on Steam's recent hardware survey, which means I can't afford to target for higher-end machines.

However, I do understand that it would be very expensive and time consuming for a native exporter on your part, but I think it would be worthwhile if you want to continue advertising Construct as making professional and powerful games for desktop.

Somebody, on the second one (racetrack) I get 59FPS in Firefox and 60FPS in Chrome, can't test the first one because I'm still on 192 (195 breaks my commercial game project )

Somebody

I get very similar results as eli0s (almost exactly). Firefox is a disgrace Which is unfortunate, as it's the browser I always use :/

Your 2nd test gives my steady 60FPS on FF.

can't test the first one because I'm still on 192 (195 breaks my commercial game project <img src="{SMILIES_PATH}/icon_e_sad.gif" alt=":(" title="Sad"> )

I made an exported version and added an fps counter (which should help as get a clearer picture. In my case it cannot top 30 fps in idle state (and it still "feels" a little jerky despite the numbers): https://dl.dropboxusercontent.com/u/132 ... index.html

Here are the actions taking place so you get an idea of how intense (or not) it is:

9017 objects doing some work.

Somebody Your spaceship example on dropbox gives me 60 always, on chrome. The loads of dot example was varying between 50 and 60, but once I clicked it went below 40, and then never could go back above 40 even thought i did nothing, and was varying between 30 and 40. Specs below

I just ran renderperfgl and I have a few interesting results. Keep in mind I'm using dual monitors, so this may have some efect (or not):

First my specs:

Processor: Intel core i7 3820 3.60GHz

Motherboard: Asus P9X79

Memory: 8x 8Gb Quad-channel DDR3 800 MHz (64Gb total)

GPU: NVIDIA GeForce GT 610

GPU Fillrate: 1.6GPixels/s

GPU Memory: 2Gb 8 Gb/s

results in webGL: 3100 objects 1920x1080

results in canvas2d: 3700 objects 1920x1080p

device: Samsung Galaxy Note II

results in webGL (via #ignore-gpu-blacklist): 12700 objects

results in canvas2d: 220 objects

So, yeah, two very weird things happening: first is that canvas2d outperforms webgl in my work computer (AKA desktop). Second is that my smartphone outperforms my desktop in webGL mode. I guess what this means is that my desktop's GPU is utter garbage.

Also, I wasn't expecting that much out of my 2.5 year old device. I don't get the complaints with performance at all, either I'm missing something or you're all running potatophones. <sarcasm> Or maybe the Galaxy Note II is a marvel reverse-engineered from future tech? </sarcasm>

Also Somebody, can you recreate those tests in CC please? I'd love to run them side by side.

I made an exported version and added an fps counter (which should help as get a clearer picture. In my case it cannot top 30 fps in idle state (and it still "feels" a little jerky despite the numbers): https://dl.dropboxusercontent.com/u/132 ... index.html

Firefox FPS with no movement: 11FPS

With movement: 9FPS

Chrome FPS with no movement: 42FPS

With movement: 18FPS

Tested fullscreen on a 1920x1080 display

Somebody Your spaceship example on dropbox gives me 60 always, on chrome. The loads of dot example was varying between 50 and 60, but once I clicked it went below 40, and then never could go back above 40 even thought i did nothing, and was varying between 30 and 40. Specs below

See, that weird fps cap thing again - I feel like Chrome does something to keep the fps "smooth" according to some inner logic - which, as mentioned isn't all that great for games.

Jayjay - wow, you get worse results than I do. It'll probably wreck the Dual core system at home when I run it there.

Also Somebody, can you recreate those tests in CC please? I'd love to run them side by side.

Cannot do the Racetrack as that uses a custom shader I made for C2. Don't currently have CC on this system so if some volunteer is willing to - would be great - maybe it's all just sweet memories of CC's greatness.

[quote:3n60coyh]IMO they should just scrap support for large projects and focus on small/midscale projects, and rapid prototyping.

Yeah get rid of large scale support )

I'm curious... How many of the games showcased on the front page are in fact Mobile games?