Thinking of returning to C2 - some questions

Discussion and feedback on Construct 2

Post » Thu Jan 12, 2017 6:18 pm

@GeometriX Yeah, definitely stick to it if you want the game to grow (consoles, mobile ....someday Hololens? :P ). We love the event system too but have learned to love C# a lot more based on what comes out the other side.

Ashley wrote: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.



Ashley wrote: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.

Ashley wrote: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.
"Construct 4 lets YOU make advanced games! (but not play them)" Construct Classic - Examples Kit Dropbox is a pile of trash and if you need my old files PM me! :)
B
124
S
42
G
17
Posts: 2,225
Reputation: 19,887

Post » Thu Jan 12, 2017 6:35 pm

Just to add, I'm working on a puzzle/platformer game for almost two years now and I've never had any problem. However, I don't use the platform behavior, but a physic engine (Chipmunk physic). The result should be heavier than any work using platform behavior, but nope, it's smooth as hell. My computer is pretty recent, tho.
B
16
S
4
Posts: 86
Reputation: 1,525

Post » Thu Jan 12, 2017 8:14 pm

Ashley wrote:
digitalsoapbox wrote: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.

Ashley wrote:
digitalsoapbox wrote: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.
B
84
S
46
G
25
Posts: 528
Reputation: 21,566

Post » Thu Jan 12, 2017 10:22 pm

@digitalsoapbox

Dude, your game is clearly awesome and is a true showcase for Construct 2, so it is great to hear your views as one of the few are producing serious content.

Looks like you are getting the bad reviews on steam because its a multiplayer and people are having issues with server connection or empty lobbies. Literally people cant play your game.

I don't think steam is the right place for your game. there is just too much going on there.

Personally with something like your game I would do free to play with adds and shove it all over the net through browsers.

also I would wrap into an app (with cocoon for accelerated performance) and put it on NVidia Shield TV , those things are really powerful, you are dealing with consistent hardware , they come with 2 joypads mapped like xbox and there is a lot sold with people sat in front of their tvs desperate for content.

not trying to be an ass , just giving my 2 cents....., just hate seeing good games not selling.......

Anyway your game is inspiring me to continue with my lowly endeavours

cheers..
...
B
46
S
24
G
7
Posts: 319
Reputation: 8,201

Post » Thu Jan 12, 2017 11:02 pm

Not to go off ops topic too much
It's been awhile since there was a C2 game jam.
Maybe a platformer jam would help figure out any issues.
Image ImageImage
B
170
S
50
G
179
Posts: 8,378
Reputation: 113,425

Post » Thu Jan 12, 2017 11:28 pm

newt wrote:Not to go off ops topic too much
It's been awhile since there was a C2 game jam.
Maybe a platformer jam would help figure out any issues.


I love this guy.
B
84
S
27
G
9
Posts: 89
Reputation: 9,613

Post » Fri Jan 13, 2017 12:22 pm

Jayjay wrote: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.

OK, but that's more of a feature, not an inherent limitation of WebGL. We could do something like that, because we can do everything a native app can do with OpenGL ES 2 (soon 3). WebGL does not prevent that.

The problem here is that it's really more than just Construct 2 being so frame-dependent (despite use of dT like crazy)

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.

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.

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. The situation is so bad it can even ruin major game releases. The GPU driver situation is totally awful and that affects the whole industry, not just WebGL, HTML5, or Construct 2. I know people get annoyed when I point the finger at other companies like those responsible for the terrible GPU drivers, but it really is that bad and everyone in this industry is dealing with it.

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/

Despite the title, that blog appears to mainly be testing CPU performance with Unity's WebGL exporter, which means it's basically running asm.js and WebAssembly vs. native code. Their own analysis says: "When you are mostly GPU-bound, you can expect WebGL to perform very similar to native code."

digitalsoapbox wrote: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)

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.

If you have a CPU-bound game, as I always offer, send it to me and I'll profile it and see if the C2 engine can be improved.
Scirra Founder
B
399
S
236
G
89
Posts: 24,519
Reputation: 195,361

Post » Fri Jan 13, 2017 1:12 pm

Ashley wrote:
Jayjay wrote: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.

OK, but that's more of a feature, not an inherent limitation of WebGL. We could do something like that, because we can do everything a native app can do with OpenGL ES 2 (soon 3). WebGL does not prevent that.

Oooh okay then. Can we have it? :) As far as I can tell resolution is the one big GPU-bottleneck for integrated chips, and as others have pointed out, intel integrateds are fairly widespread outside the hardcore gamer segment.
B
39
S
16
G
6
Posts: 543
Reputation: 7,619

Post » Sat Jan 14, 2017 6:43 pm

Ashley wrote:
Jayjay wrote: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).


Ashley wrote: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.

Ashley wrote: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.

Ashley wrote: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 :P ) 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.
"Construct 4 lets YOU make advanced games! (but not play them)" Construct Classic - Examples Kit Dropbox is a pile of trash and if you need my old files PM me! :)
B
124
S
42
G
17
Posts: 2,225
Reputation: 19,887

Post » Sun Jan 15, 2017 6:21 pm

Jayjay wrote:
GeometriX wrote: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).



I've always wondered why I've ran into that issue when making my games. I'll have to remember that in the future.
Image
B
15
S
4
G
3
Posts: 121
Reputation: 3,791

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: zenox98 and 5 guests