It's not too bad, only 56 current issues with WebGL across all platforms:

7 specifically related to Construct 2:

Notable is the one on switching tabs freezing multiplayer games, and the slow/janky scrolling

Edit: Actually digging into this with the search term "Scirra" proves interesting too:

https://bugs.chromium.org/p/chromium/issues/detail?id=666710&q=scirra&sort=-modified&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

[quote:29wntyds](Scirra)What is the expected behavior?

Animations should always finish playing. There should be 0 boxes left in "pending" state after pressing stop.

What went wrong?

Animations get stuck in "pending" state and don't finish. There are some boxes left in "pending" state after pressing stop.

https://bugs.chromium.org/p/chromium/issues/detail?id=650594&q=scirra&sort=-modified&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

[quote:29wntyds](Scirra)Please also treat tabs with active WebRTC DataChannel connections as exempt. We've already run in to trouble with hosting multiplayer games in background tabs, as described in issue 676036, and from what it sounds the proposed CPU budget will be far too small to keep processing a game.

https://bugs.chromium.org/p/chromium/issues/detail?id=353072&q=scirra&sort=-modified&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

[quote:29wntyds](Chromium)We don't have any plans currently to try and make <video> or <audio> loop seamlessly.

https://bugs.chromium.org/p/chromium/issues/detail?id=79180&q=scirra&sort=-modified&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

[quote:29wntyds](Scirra)Recently CSS grid layout performance has become extremely poor in Canary - even just 40-50 elements can take 500ms to layout.

There's bugs in any software though, let alone one as massive as Chromium (which is compounded by the now even-more-massive reliance on Chromium by Construct 3)

The truth is many of us here come from Fusion and have been using construct2 for the similarities of the event sheet

Not just that, but Construct itself exists because a young Ashley decided he could do it better, and for the interface he has 100% done it better in my opinion.

But, I wouldn't be too upset if Fusion 3 borrowed back from Construct, especially with including event sheets and the event sheet editor in general (as well as the way animations are handled in C2). After the struggles of releasing a game on Steam that most 2D game players can't run on their devices properly, I realized the export/runtime matters more than how nice the editor is.

There's no reason Construct made games can't be as popular as the big hits from other engines, we think it's only a matter of time.

We see developers using Construct all the time who obviously have the talent and creativity, just a bit more luck is needed!

True, there's already a few great games made in Construct 2, and people really start to recognize them once the developers switch engines/the games have been ported to consoles using other engines

Despite all the ranting and raving I might be (or am?) known for about the performance and export options of Construct post-Classic, I actually agree with this thread.

Construct 3 is known to be an editor-only change, since it was specified as using the same runtime as Construct 2. Considering plugins in Construct 3 (as well as the whole engine, and now editor) are all JavaScript, it effectively means the whole thing is possible to port forwards and backwards to C2 or C3 anyway.

The cloud services, and potential for a Google Docs-like real-time collaboration system, is what could be really powerful, in addition to the added control over the interface that plugins have (because it's in a canvas already).

Selling those services as a subscription "Construct Cloud Services", and maybe even giving priority/premium support to users of that (since Scirra can literally download and run/check out the projects stored on those cloud servers, assuming the client allows it) would be a professional service sold at a professional price.

Otherwise, I don't see it being a long time before other engines do "what C2 does" and have the added benefit of native export to:

PC (Win/MacOSX/Linux)

Consoles (Xbox One, PS4, Switch, WiiU, New Nintendo 3DS, PS Vita)

Mobile (Android/iOS)

On top of WebGL export, which is the only one Construct actually "has" (without wrappers)

Guys, you criticize something before even seeing it. Come on. Yes, nobody likes subscription model, but if the tool is like C2 but better (don't talk about browser-based issues, we don't know yet how it'll perform) and is very efficient, if somebody wants to do it professionally it's ok to pay a sub fee. Otherwise, stick with the free version or with C2.

Wait and see.

Before seeing it? It's literally the same runtime as Construct 2. The "all export platforms" that they boast about in the C3 news means just HTML5, because it's all HTML5 no matter how you wrap it.

We have and are seeing Construct 3 every time we open up Construct 2. The editor might get fancy new plugins (which, aside from editor interface specifics, can be back-ported to Construct 2's runtime, due to both using the same runtime) and ease of use, but considering that its entire purpose is to make games the net result will be the same.

(Ashley has confirmed multiple times C3 is same runtime as C2, search the forums and news posts for the evidence)

I wouldn't trust those fake news sites, especially not today of all days:

Ashley Ah yes, our game did take advantage of that mode, which helped a bit.

Not sure of which specific effects now, as we've retired the game and moved its source off our storage system into archives, but the GPU, aside from upscaling, was doing very little beyond sprites with possibly a few blur shader or glow effects here and there.

The low-res graphics and "native" resolution (somewhere around original NES resolution) of the game meant GPU should not have been a big issue (aside from blacklisted or underpowered GPUs on integrated chipsets).

> In native-based engines you have much more control over resolution, so we can render the effects and things on a smaller screen space, then use one clean up-scale render-to-texture to make that "HD" using a simple one-pass shader.

>

We could do something like that, because we can do everything a native app can do with OpenGL ES 2 (soon 3).

That would be incredibly helpful, especially if later on we get the control to actively resize the resolution of the desktop (which is a dying trend, but is sometimes the only hope for the many gamers on older hardware on Steam).

You can turn off framerate dependence if you want, or adjust the dt cap to limit frame skipping, by changing the minimum framerate. But if you disable it completely then you have to deal with the game running at different rates depending on the display refresh rate, e.g. it will go twice as fast on a 120Hz gaming monitor, which I've always thought was a worse result.

The gamers who leave the most negative reviews on my title on Steam are not the 120Hz monitor gamers. I do like the minimum framerate option that was finally added (as slowing the game down with accurate collisions is 100% more useful in a platformer, it lets us say "Hey if it's slow, that's your computer!" rather than "The magic box we bought and built our game on decided you don't need to stand on that ground", to which we will of course still receive some angry reviews saying that a "retro game should run on a toaster", but that's again the issues of GPU-blacklisting + CPUs that really can't run JavaScript.

Do not assume native DirectX or OpenGL are perfect for everyone either. I've done a lot of native coding with both DirectX 9 (Construct Classic) and OpenGL (C2 editor) and there is a total minefield of horrible driver bugs, crashes, and even poor performance.

I agree native can be the root of the problem in many situations, but this current "SEGA tower of power" kind of workflow (C2 engine > HTML5 > Node-Webkit/NW.js > Chromium > OS > Graphics Driver > GPU) could really stand with something more dedicated as a game engine coming in and replacing the NW.js and Chromium steps, even if it doesn't come from Scirra specifically. I guess we'll have to wait and see how the tech goes there.

Maybe you're actually testing CPU-bound games where the GPU performance doesn't matter. That explains why you could see differing performance even on a system with a super-powerful GPU. CPU performance is another topic entirely. My point is that since there is a 1:1 mapping between WebGL calls and OpenGL calls, the GPU performance should be identical to a native app making the same calls. There's no reason for it not to be. Maybe different engines do some special optimisations or something, but there's nothing stopping us doing that in WebGL as well, since the same features are there. So it's not actually WebGL's fault or some fundamental limitation of HTML5.

Agreed, there are likely many situations (aside from GPU-blacklisting) where CPU bottleneck is the entire issue. However, I would argue that could still be seen as a limitation of HTML5, simply due to the overhead and memory management issues inherent in JavaScript. If you had performed the optimizations you have done to C2 (which are pretty amazing considering again that it's JavaScript ) to CC then you would have much different results than the latest benchmarks comparing against "native Construct Classic". Even 10% less CPU performance could be the difference between the customers with low hardware on Steam complaining of falling through floors, or merely having a few lag spikes at intense moments.

That said, I can only imagine something like *maybe* asm.js coming in to save the day there, as you've already done many optimizations to C2 these past couple years.

GeometriX Yeah, definitely stick to it if you want the game to grow (consoles, mobile ....someday Hololens? <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz"> ). We love the event system too but have learned to love C# a lot more based on what comes out the other side.

This is a classic case of blaming GPU performance on Construct 2. If a game runs OK in SD, but is slow in HD, that's 100% down to the performance of the GPU hardware. A native engine would perform identically, because it's the same hardware. I have looked in to this in the past, and it usually comes down to crappy integrated Intel GPUs. There isn't much any game developer anywhere can do about that...

In native-based engines you have much more control over resolution, so we can render the effects and things on a smaller screen space, then use one clean up-scale render-to-texture to make that "HD" using a simple one-pass shader. It's used in emulators and many other popular games to make things look nice on much more hardware than WebGL supports.

I'm not aware of any performance issues relating to platform movements - collision cells should ensure that's fast. I'd be happy to review a .capx if someone made something demonstrating a performance problem.

The problem here is that it's really more than just Construct 2 being so frame-dependent (despite use of dT like crazy), JavaScript is really terrible and things fall through the cracks on anything less than gamer-hardware (which becomes worse as you enter the Intel CPU market which just happens to be the biggest customers of 2D games).

I really wish there was more free time/staff at Scirra to actually make a few full-sized games to prove the people who *are* making full-sized games wrong if everything is an event-only issue.

According to webglstats.com 95% of users have WebGL support now. Problems for the 5% may be tricky, but firstly it's a pretty small segment, and secondly there's still not much that can be done about it - Chrome does a lot to work around driver bugs, and if it can't run WebGL, it's likely that the drivers have severe stability issues. So those users are likely to be a problem anyhow.

Support doesn't mean it's fully working. A laptop from 2006 might have a version of Chrome that "supports" WebGL, but it'll run DirectX 9 faster than it every time.

I love Construct, ever since CC's early buggy alphas/betas and even now I still love it, but I can't afford the negative reviews and hate caused by it when someone with low-end hardware pays their hard-earned cash to have a broken game that I paid my hard-earned cash (and time) to have an engine that's perpetually broken (due to JavaScript + Chromium + NodeWebkit issues + GPU blacklisting and WebGL issues) to make it with.

Unity has the funds and staff to do extreme optimization on both native and WebGL, and here's their results:

https://blogs.unity3d.com/2014/10/07/be ... -in-webgl/

Native is nearly double Chrome overall, that's a big difference.

in the form of a side-scrolling 2D platformer

2D platformers seems to be the weakest point of C2, especially if making a game where the enemies are also using platforming behaviors and if there are many (eg: 5+) enemies alive at a time/on screen. Eats up the JavaScript performance and leads to missing collisions on average or lesser machines (which feels like a large portion of audiences who purchase 2D games on the desktop/Steam).

Also, screen capture software still tends to wreak total havoc in the games, causing further missed collisions and engine issues you won't easily avoid, so social spread of the game might be negatively impacted.

But as a side project? I agree with glerikud that it should work alright on desktop aside from the above (Windows specifically, never had much luck with Mac/Linux for our game).

Something like Sprite Lamp effect as an behavior sounds good? As a 2D tool, texture is not Our priority, but making it easy to implement could be very nice.

Think about creating a player or enemy sprite and then setting the Sprite Lamp behavior, opening a new window where you're able to place at least 4 shadow textures, also, being affected by any source of light and making its shadow and depth visual like the original Sprite Lamp did.

Sprite Lamp is cool, it gives manual control over each light direction, but I like Sprite Dlight myself since it auto-generates the normal map to be lit up: http://www.2deegameart.com/p/sprite-dlight.html

But yeah, some simple hook to open up another "tool" or plugin, like Photoshop filters, would be really cool.

Hmm, could also be graphics card related.

Working fine from here though!

Specs:

Windows 10 Education 64bit

1920x1080p 60hz dual monitors

Intel i7 6700k

NVIDIA GTX 1070

16GB Ram