PC browser games only 5%,should Construct change?

If you think Construct 2 can't handle graphically intensive games, then as ever, rendering is bottlenecked on the GPU. So if you switch tool because of that, the hardware isn't going to be any faster, and the performance won't be any better.

I think some people switching tools have hardware-bottlenecked games and are eventually going to realise it was never C2's fault. I do see a lot of games bottlenecked on the GPU, and everyone knee-jerk blames C2, HTML5, Chrome, or anyone or anything else. I don't know why it's so hard for people to believe they've fully utilised the hardware? The engine is designed to let you do just that. I'm happy to be proven wrong, please send me your projects and all that, but it usually only confirms the point. I imagine some people will wander from tool to tool always thinking everyone's engine is awfully slow, never recognising that hardware is a limited resource.

Just to pre-empt how this discussion usually goes: now someone's going to shift the goalposts and talk about some random bug or some quirk that we fixed, or some other problem they had at some point, or start listing their personal laundry list of things they want changed. That has nothing to do with GPU performance. On this specific point, C2 is as good as a native engine, and I stand by that.

I shouldn't be running into bottlenecks on a 970. Or a 1070. Even the low-end target of a 750 (which should be lower, but can't be because of issues with C2) for Sombrero. If I'm running into fillrate issues in C2, that I don't run into elsewhere? That's a C2 issue. Period. Maybe the F2B renderer would have helped, but it was abandoned quickly and hasn't been brought up since. No point in waffling about on it - C2 is slower than the competition in getting things on screen. The reasons aren't especially relevant in the end.

So, no. No shifting goalposts. C2 simply isn't as fast as native, or whatever you want to call what other tools are doing. This is aside from issues with getting games running on as many of the platforms people buy games on as possible, which is also less of an issue with other engines, aside from the frankly embarrassing "support" for the Wii U, which was anything but, or the longstanding (years?) mentions of XBox One support that are still nowhere to be seen in terms of actually being able to RELEASE a game on the platform, with the features gamers expect. If I had to hazard a guess, we may end up relying on third-party support for that platform as well, much like Steam4C2 is much better than the support Scirra provides for Steam features, despite both being based on Greenworks.

I'm not talking about issues with HTML5, either; I'm talking about C2 specifically, and I suppose C3 considering it's basically just C2 with a different IDE, higher costs, more complex plugin development, and less flexibility for developers to do their own local builds with their own toolchains for NWjs on desktop & mobile.

You'd think that every dev that's made anything of scale in Construct having to move on to other game creation tools would be enough of a hint, but stand by your point as much as you'd like I suppose. The people buying games don't care about a game's tech, as long as it works as expected and provides good performance. It doesn't matter how easy C2 may be to use to make games if they have far higher hardware requirements, and are limited to less platforms than similar games based on different tech, limiting their market.

Anyone who ever got their hands on the WiiU + dev kit had learned quickly that C2 games weren't going to run well on it (especially anything non-turn-based/action oriented)

Jayjay

If memory serves, since I've long ago returned my WiiU devkit, this was due to Scirra's stubborn refusal to support the way the Nintendo Web Framework handled hardware acceleration, which was available for HTML5-based games. And didn't a third party actually have to finish implementing the framework, since what Scirra provided was the bare minimum of feature support, and not what NWF was capable of, even outside of hardware acceleration?

The biggest bottleneck I've seen is from going fullscreen with too much content.

So my view here is not due to naivety, it's actually based on working with these very large projects.

Only two projects?

There you go, there can be no other problems. It is always user error.

All I know is that c3 keeps running out of memory whenever I'm trying to preview my games. Those same games run just fine in c2. And needing to do things like download and use Canary is annoying when I should be able to just run c3 and it work.

I honestly feel like I just paid to beta test c3 which is not a good feeling at all.

How hard would it be to add a 'GPU bandwidth gauge' to warn the user there will be GPU bottlenecks....?

If this is almost always the main performance problem and the users aren't aware of it, a system to automatically check and warn the user might be very helpful

I shouldn't be running into bottlenecks on a 970. Or a 1070.

Those cards have insane amounts of bandwidth. So it's unlikely to be fillrate. So you probably have a CPU-bound game. So you can then use tools like the profiler to investigate why that is and optimise your events.

So no, still nothing to do with rendering performance.

The Next Penelope in particular had some issues with using too much fillrate early on, but Aurelien made some game design changes to reduce excessive layers, effects etc. and then it fit much better within GPU hardware limitations.

Has there been more details about this posted somewhere? I'd be keen to learn from their mistakes so I don't repeat them, incase they've encountered things I hadn't thought about. Obviously you've clarified to avoid using "force own texture" at least, and to minimize effects as often as possible, but what's meant by excessive layers is unclear.

It is a problem designing and marketing a product for non programers and the like yet expecting them to know all about fillrates and things.

We probably do need dedicated documentation on this, but the basic principle is simple enough: if you have 3 sprites stacked on top of each other, then each pixel is drawn to 3 times, because C2 renders back-to-front. That's overdraw (filling pixels more than once), and it wastes fillrate. Using a force-own-texture layer (which includes options like opacity which implicitly turn it on) causes the entire layer to be overdrawn since it has to draw the layer's own texture to the screen.

We probably do need dedicated documentation on this...

I would like to see that happen, I would like to read in depth article/documentation about fill rate, back to front, front to back, how Construct 2/3 deals with fill rate and about tips how to get max performance with minimum sacrification.

As I see it now: Construct is back-to-front, so opaque object won't prevent rendering the objects behind it.

"Force own texture" is a fillrate-greedy option that should be avoided if possible.

Having many layers is not a bad unless you forcing them own textures.

Nothing is rendered outside the canvas borders.

Correct me if I'm wrong.

We probably do need dedicated documentation on this..

That's a great idea, just please include it in the manual because tutorials and blog posts get lost/forgotten over time.

How hard would it be to add a 'GPU bandwidth gauge' to warn the user there will be GPU bottlenecks....?

If this is almost always the main performance problem and the users aren't aware of it, a system to automatically check and warn the user might be very helpful

This is a great idea! Similar to several music programs I use, I want to know when I am pushing the GPU meter into the red. It is sounding like the performance issues relate to GPU.

And ... overlapping textures?

> I have a hard time understanding how Asphalt 8, Modern Combat, Titan Quest etc. can all run on my device yet somehow a simple 2D game is maxing it out

>

3D games in particular have a very different rendering approach. Many GPUs have limited bandwidth, and the fact 3D games have depth allow them to use a front-to-back approach that more or less ensures every pixel is only drawn to once, at least for the basic color pass.

Ashley

Thank you for pointing this out. Using the Q3D plugin with C2 to make 3D games, I have wondered why I have been CPU-limited instead of GPU-limited, even though there are potentially many occluded surfaces for every screen pixel. Using the integrated Intel graphics on my 2013 MacBook Air, I have not even begun to stress my GPU, while I have been way overloading the CPU. I have had to go through every event sheet with a fine-toothed comb to minimize CPU cycles.

In 3D games, I have been using small textures, and the GPU has never been a bottleneck.

Just for kicks I have been tooling around with Unreal Engine 4 and Unity for the past few weeks. Unreal Engine 4 crashes every 15 minutes, completely overwhelming both my GPU and CPU. Unity is stable, but I don't try to push it. Three.js (a webGL 3D framework) is totally stable on my MacBook Air. After experimenting with all of these options, I concur that WebGL doesn't have a fundamental disadvantage for GPU-limited games. We still need to be careful about the CPU though. I think there is still a native performance advantage for CPU-limited games.

> We probably do need dedicated documentation on this..

>

That's a great idea, just please include it in the manual because tutorials and blog posts get lost/forgotten over time.

I would like to understand this better too. Please create some documentation on it.

The basic idea is add stuff till it stops working.

That's when you know the limit.

Thats why its good to develop on a slow machine.