> I'll add to this and say high resolution platformers are definitely an issue in C2 and I haven't seen any real movement to look into why HD performance isn't all that great.
>
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...
I didn't say Intel GPUs - I've had performance issues on a number of mid and high-range nVidia GPUs when running C2 games at 1080p or higher. While the "Intel GPUs are crappy" theory may have worked in the past - when they were very, very crappy indeed - more modern Intel GPUs tend to perform much better (including those in their new Skull Canyon NUCs), so I'm not sure that holds water any more. Even then, other games, both 2D and 3D, made in other engines, perform significantly better on Intel embedded GPUs than games made in C2. Whether that's due to usage of WebGL or not is debatable (I say probably not), but saying other games don't perform any better on the same hardware - call them "native" if you like, but that's somewhat irrelevant to overall rendering performance not affected by the overall CPU usage of the codebase - is provably untrue with absolutely no effort required to do so past picking out another 2D game made in something other than C2 on Steam and launching it.
There's probably an argument to be made about whether they're "true" 2D engines or 3D engines that allow 2D games, but at a certain point that just becomes a distraction, and for developers & end users, performance is performance. The technicalities only matter to those to shrugging off such concerns. Frankly, the suggestion that it must all be the GPU's fault is as ludicrous as the idea that rendering performance shouldn't, doesn't need to, or can't be improved.
>
> 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.
>
Low res platformers are easier to get a steady, higher frame rate in than high res platformers. Fill rate isn't awesome in most C2 games if there's a lot going on, on multiple (say, 7 to 10) layers. Add a few shaders - even if just the included shaders, so that issues can't be blamed once again on 3rd parties - and performance is shot, exponentially decreasing as resolution increases. While this is an expected consequence of higher resolutions, the degree to which it happens in C2, on mid and high-end GPUs, cannot be overstated.
Based on comparisons to other game engines, performance is much lower in C2. This cannot be blamed solely on the GPU, and based on the performance of other software which uses WebGL, it would be hard to blame WebGL for the performance issues either.
As I said earlier in this thread, C2's event system is pretty nifty, and I think overall performance of it v more traditional programming is good with room to get better. On the rendering performance front, Construct is behind the curve. That's just the way it is. Whether that's to be blamed on WebGL, C2's implementation of it, Chromium, NW.js or anything else I'll leave to others, since placement of blame doesn't change the end experience - the part that matters most when making a product to sell.
Fingers crossed there are continued improvements to Construct, in 2 or 3. But some of this passing the buck is a pretty dismissive response to issues repeated time and time again. Sometimes the users of a product DO know what they're talking about when it comes to more technical concerns, which may be something to keep in mind.