Seems like a spiritual successor to OpenPandora, but yeah I don't expect it to perform better at HTML5 games than the average cell phone based on those specs.

It probably means the "life" of Construct 2 itself, so any patches that come for it ever will still be available to you. It also means you can use Construct 2 for the rest of your life (as long as it runs on the operating system/computer of the future of course).

Construct 3 (I think) is going to be a separate product you can pay to upgrade to.

Nice track!

> it could also be described as a top-down FZERO, which the SNES could handle

>

Obligitory "my SNES could run this", obligitory reminder that as far as I can find the highest resolution mode of the SNES was 512x239 8bpp which is 122kb per layer vs. a modern 32-bit 1080p game which is 8mb per layer or about 68x more bandwidth. Assuming you have the background and four own-texture layers, that's 340x as much bandwidth, not including higher-resolution textures, plus rotation and scaling, plus no sprites-per-line restrictions, plus transparency and alpha blending, etc.

Nice cropping of what I had said.

which the SNES could handle if it wasn't in HD

And you are right, it is a weak Intel GPU, but it's the majority of my (/Steams) customer base and it has been designed to work very well with the existing graphic APIs like DirectX and OpenGL to run some fairly high-end games with little to no problems on low and medium quality modes.

Maybe all we need is an option to force desktop resolution in fullscreen to something lower to cope with weaker fillrates, but that's not an option for me yet and this render-then-scale idea didn't help either:

It would require modifying NW.js/Node-Webkit 's code to add that feature right? Great, more waiting on NW.js for a feature that is available already to every DirectX and OpenGL programmer.

I'm not trying to aggravate or imply that hardware can "magically increase", but there is overhead in HTML5, JavaScript, web browsers, etc. I'm saying that I notice that difference, and even worse my customers notice.

If I didn't care I would probably be more than happy to just directly quote you saying "Intel GPUs really suck. That's not our fault" every time my customers are running hardware like that and complain of jank, collision glitches caused by low FPS (set minimum fps does help stop this, so sharing our issues leads to results?), and general slowness even though they have better specs than me (but older GPU/CPU that wasn't designed for WebGL).

But I don't, I believe in you and your great editor, and have done so since the beta days of Construct Classic. You may be 100% right about the future of HTML5, but some more control or investment into these exporters would make a difference.

Also, saiyadjin I had some really funky things happening when I tried in Chrome (froze my laptop, text was cut in half on my desktop), but I'll try again and post specs for you.

Thanks for the detailed reply I wasn't trying to shut down the conversation, only trying to understand and propose some elements of answers to other previous posts as well.

Refeuh I really appreciate that, and I agree that it's important to look at the different layers. There are so many variables that can form together to make the game not run on one computer and run fine on another that it is unfair to blame entirely one part of the chain.

Often there are people who are very unlike you though, and reply to threads/comments like this with a simple statement that the developer has simply not tried "hard enough", or has "dreamt to big without putting the effort", or that they should reveal their entire source code or try re-coding the whole thing in another engine to prove it's C2/NW/HTML5/WebGL causing the majority of issues instead of the game itself.

These don't apply to every developer though, especially in our case given that our title actually was finished and released on Steam, with every possible effort put into improving it.

Most importantly to me is that I think there is a big difference between giving up, and migrating tools. Migration is a warning sign that something isn't quite working as Scirra customers expect, especially if the game does end up working better in the new engine.

Fair point ! Though we don't necessarily have to use Adobe, Oracle or Microsoft tools to create content for their platforms. I guess one of the issues is that nobody really "owns" HTML5, and big companies are stiring things in multiple directions (google v8, ms typescript, etc.) and it's not yet a fully mature technology

Definitely agree, Chrome has made some major pushes that seem to establish dominance for now, but it's more chaotic than even OpenGL was.

Isn't that true for all tools and platforms ? Maybe what C2 would need would be "platform presets" ; e.g. targetting iPad2 ? fine, let's disable all fancy stuff that we know won't run well. And so on.

In general yes, I would say so, and that I like that idea as well. The only extra parts I would add is that the NW export does not run the same on Windows, Mac OSX, and Linux even if the machines running those OS's have the exact same specs otherwise.

This is again an issue with NW and maybe not C2, but it should have a warning for the developers before they get a beta working fine on all platforms, and then promise Win/Mac/Linux (because the engine they use promised them the same thing) for the final game after getting some crowdfunding or Steam Early Access sales. It's a great way to annoy customers when you start cancelling ports.

Refeuh I can assure you that after multiple delays to do re-designs, re-codes and profiling of each of the mechanics in our game, we did not find much else that could boost the performance.

Work-arounds are something that we have specialized in since Construct Classic, so although your points are true that sometimes it is the games fault, it is also true that sometimes it's a fault in the engine.

As for changing the scope of the game to something smaller, I would, if our game wasn't something that basically could have been on 1980's arcade machines (https://en.wikipedia.org/wiki/Black_Tiger_%28video_game%29). The Next Penelope is an awesome game, but it could also be described as a top-down FZERO, which the SNES could handle if it wasn't in HD (Black Tiger ran a 4MHz Z80 CPU, while SNES had a 3.58MHz Ricoh 5A22 CPU, I know that direct CPU comparison doesn't count, but it's not entirely a "high expectation" that my game should run as well as these systems).

Ultimately the arguments of "think/dream/try smaller" and "are you sure/double sure/triple sure that you coded it right?" are not actually good methods of shutting down this conversation. Maybe native isn't the solution to the real concern which is poor performance on desktops and consoles, which we can see is not happening in Construct Classic, Unity, Godot, and many other tools that export to native/rely on existing OpenGL and DirectX runtimes.

As mahdi71 jokes, I actually would buy a Construct-style interface for 2D game dev that runs on the Unity runtime, even though I know how to program (in C#, Java, etc). I like the speed that C2 has editor-side for putting things together. That is why I'm moving on with future retail titles to use Unity instead of Construct, but still care so much about the future of Construct.

> Using HTML5 wrappers bloats the size of the project

>

It does - but no more than, say, deploying a software made in Java (requires JRE), C# (requires .NET), Flash (requires Adobe player), Unity web (requires Unity webplayer), etc. Even pure C++ has some dependencies (requires CRT libs, typically the msvcrt.dll variants people get when installing games on Windows). People install all these without complaining.

I don't see this as a very significant point when choosing a technology.

The real issue is that these wrappers don't just add a bit of bloat, but they are middleware unlike the Unity Web Player (which Unity can control), Flash (which Adobe can control), Java (which Oracle can control), and .NET/DirectX (which Microsoft can control).

Instead we're using NW which is based on Chromium, so it's Scirra having no control over NW.js, and who themselves have very little to no control over Chromium. So we're stuck when it comes to a Scirra-specific fix to hope that NW pays attention, and if they can't fix that (jank) that Google pays attention.

For example one shouldn't create a game and THEN decide to target the WiiU and the iPad2. These have so strong (and conflicting !) requirements they need to be factored in from the beginning (especially regarding art assets and use of alpha blending). Using native solutions doesn't remove this constraint. Just an example.

True, but Construct 2 should live up to its advertisements or have some small print like "WiiU as long as you don't use WebGL, complex coding, or expect real-time gameplay". Native does fix the issue of needing GPU support over Canvas2D as well.

saiyadjin can you tag the people you're responding to?

Ashley As for where and why native would be preferred, mainly desktop and console! The systems where big "advanced" games actually mean games newer and more complex than the 1980's arcade machines or SNES titles with newer graphic effects.

Construct 2 games fail hard on Mac OSX and Linux with games over 500MB, and most of that size is soundtracks. We can't update to newer NW.JS so we're using NW 10.5 (which is great because it seems that's one of the only ones that supports Greenworks now!).

Mobile and web set lower demands for game complexity and detail, but desktop and console is an area where games get larger and sometimes need that extra content and CPU power that JavaScript loves to consume (almost all graphics in our game are less than 128x128, but there are lots of items and enemies) and WiiU doesn't even support WebGL.

The Steam hardware survey is a great way to know what systems to aim for on average ( http://store.steampowered.com/hwsurvey ), and it's roughly a 2.4GHz dual-core Intel CPU with Intel HD Graphics 4000 GPU. Do you use a device with these specs when you test the examples people send?

If making a game that's meant to reach a wide audience, such as a more casual experience, I would say we even have to aim for lower specs than that. Since lag, jank, and other issues that happen at low FPS (falling through floors, etc) look bad on us!

We get the negative reviews, not Scirra and Construct 2, yet it's generally an engine issue that does not happen on far-above-average machines.

In 10 years, when everyone has a huge gaming computer for the price of today's average laptop, I won't care about native support since the devices will actually be designed for HTML5+ and WebGL or whatever other standards appear.

But our team bought business licenses roughly two years ago, to make a game we released roughly last year, to explain to our customers that they just need to upgrade their hardware to play an 1980's-inspired arcade game? They don't buy it, and it makes me wish I didn't buy into the HTML5 dream that keeps being pushed here.

Haha newt I love that comparison

newt I think that's over-simplifying it though, because it's many layers of "a subset of C" when it comes to HTML5

JavaScript doesn't compile, so it is interpreted at runtime by the browser/JavaScript engine, which probably turns it into bytecode, which then is run by another interpreter at OS level (like .NET) which is running within the operating system made in C and compiled into assembly.

C++/C games skip a lot of those layers (and do have more dangers since you manually clean memory, but if you know what you're doing this is a performance increase over generic garbage collection). C# skips the first few layers that HTML5/JavaScript has, starting from the bytecode level.

Layers/encapsulation is a performance hit (no matter how tiny), this applies in software, network traffic, shipping, and more.

In a (possibly a bit over-) simplified way, this is how C2 and CC games layer:

Pretty sure there are no CC games on Steam.

Then again they haven't shown how they did the "snappy" comparisons to get to those conclusions.

Yes there is, and it runs better than the majority of (desktop) C2 games I've ever played (including my own): http://store.steampowered.com/app/396640/

megatronx Might or might not have been mine, but I remember some examples of it too in a thread about people wanting native export. Not saying I demand native export, that has been discussed enough to know it's not happening but Vulkan GL, Emscripten, and ASM.JS are all things that might really help Construct games run smoothly in HTML5 (plus the improving support of new hardware over time too).

megatronx I'm insanely glad I'm not the only one to notice that

Anytime! and Kickstarter is a crowdfunding site where you can raise money to finish or make your game/movie/tool/toy/clothing/etc haha. Other ones like it are IndieGoGo and Go Fund Me I think.