Is C2/C3 good for large 2D desktop games?

Discussion and feedback on Construct 2

Post » Fri May 12, 2017 5:09 pm

As far as I've ever been able to tell, every case of significant performance issues in a browser, NW.js or on mobile, is GPU blacklisting. That is approximately 4% of devices in the world which have such terrible GPU drivers the browser won't use it (since it causes crashes/severe glitches) and reverts to software rendering.

I have seen scant evidence of any other significant performance issues for a long time now, despite always asking and investigating.

The irony is graphics drivers are native technology. Using different technologies just makes you vulnerable to the crashes/severe glitches on those 4% of devices with poor quality drivers.

For the 96% of devices, WebGL is native performance. It's bottlenecked on the hardware.
Scirra Founder
B
387
S
230
G
88
Posts: 24,251
Reputation: 192,454

Post » Fri May 12, 2017 8:43 pm

Ashley wrote:For the 96% of devices, WebGL is native performance. It's bottlenecked on the hardware.


This is 100% untrue blaming-shifting nonsense. Performance on even powerful desktop GPUs is around half of what native provides for larger desktop games, and saying half is being generous, and reaching only around 50% of native performance involved a LOT more work than it would using other game development tools; hell, there's not even a way to set the canvas resolution easily in a way that takes into account object positioning, because you've somehow convinced yourself it isn't necessary (even though native apps support this with switching monitor resolution out of the box), and only offer "low" or "high" settings. Blame drivers all you'd like, but it's what literally every PC uses, so complaining about and/or blaming them is pointless navel-gazing. Blaming the only ways to export games for poor performance is highly disingenuous, since they're the only way to export and sell C2 games. I can't even imagine the gaps in logic that allow someone to arrive at your performance comparison conclusions.

You've hitched Scirra's wagon to HTML5, and that's fine. But let's not pretend it's even close to a mature technology, from a software/development standpoint all the way through hardware support, for the creation of medium-large games. The performance simply isn't there, and you're flat-out wrong to suggest it's remotely close to performance of native with anything more than a very, very simple game with absolutely no bells & whistles.
B
70
S
40
G
24
Posts: 518
Reputation: 20,070

Post » Mon May 15, 2017 3:07 am

digitalsoapbox wrote:Blaming the only ways to export games for poor performance is highly disingenuous, since they're the only way to export and sell C2 games. I can't even imagine the gaps in logic that allow someone to arrive at your performance comparison conclusions.

You've hitched Scirra's wagon to HTML5, and that's fine. But let's not pretend it's even close to a mature technology, from a software/development standpoint all the way through hardware support, for the creation of medium-large games. The performance simply isn't there, and you're flat-out wrong to suggest it's remotely close to performance of native with anything more than a very, very simple game with absolutely no bells & whistles.


This response seems pretty harsh. So you think Ashley is being purposefully deceitful in order to sell more product? If so, to what end?
B
88
S
29
G
14
Posts: 1,154
Reputation: 15,003

Post » Mon May 15, 2017 7:15 am

@Ashley has a point, investing to a young technology which has potential to improve in time. But currently, within this decade, I'm with @digitalsoapbox on this one, HTML5 is too young, javascript so slow... Even making a small Flappy Bird game is far more stable making in Unity for an Android Jellybean phone from 2012 than making on C2.

As far as I remember, my tests back then has a performance of 60fps stable no significant spike for the game made on Unity and 24fps unstable, frequent lag spikes and unplayable for the one made on Construct 2.

Theoretical FPSs or hypothetical speeds between native and html5 doesn't matter anymore when real life benchmarks are so significantly bad.

In conclusion: Ashley you're so wrong ... :roll:
Image



The Things you can create is only limited by your imagination. If you don't have the skills then use your motivation as a natural force to exceed all expectations. Chadori RebornXD
B
55
S
17
G
90
Posts: 1,112
Reputation: 59,151

Post » Mon May 15, 2017 10:48 am

chadorireborn wrote:@Ashley has a point, investing to a young technology which has potential to improve in time. But currently, within this decade, I'm with @digitalsoapbox on this one, HTML5 is too young, javascript so slow... Even making a small Flappy Bird game is far more stable making in Unity for an Android Jellybean phone from 2012 than making on C2. ...

Could one of your guys please provide something which actually has some sort of valuable information in it?
I mean I'm always biased towards native but these sorts of claims are what Ashley has been criticizing several times in this forum already.


chadorireborn wrote:...As far as I remember, my tests back then has a performance of 60fps stable no significant spike for the game made on Unity and 24fps unstable, frequent lag spikes and unplayable for the one made on Construct 2.

Theoretical FPSs or hypothetical speeds between native and html5 doesn't matter anymore when real life benchmarks are so significantly bad.

In conclusion: Ashley you're so wrong ... :roll:

This is simply not enough and can in my opinion, also easily be faked.
I would be nice if either you, @chadorireborn or @digitalsoapbox could provide the following to prove your claims:
  • Re-created C2 in-house example with export + source files (e.g. in Unity)
  • Description of your benchmark test (details on how you did it and on what kind of machine)
  • Precise performance comparison (FPS, CPU and Memory Use)
Upload all those files and provide all the necessary information so that everyone is able to reproduce and do performance comparisons by themselves.


Please keep in mind that this has nothing to do with me, desperately trying to defend web technology or Ashley.
I just think that every claim needs, clear and reproducible evidence to go with it (just like when reporting a bug).
ImageImageImageImage
B
56
S
21
G
77
Posts: 637
Reputation: 43,963

Post » Mon May 15, 2017 11:41 am

I havn't done any significant testing, only some small ones for personal curiosity. But when it comes to rendering I didn't find any issues.

If you have a simple test scene running at 160 fps in native, but 60fps in WebGL, it doesn't mean native is double performance, as WebGL is capped at 60fps, so you can't really compare.
Only when you start adding loads of stuff to you can start to compare.

Set a target fps of 30, and start spawning rotating sprites, (like in the C3 example), then you can tell the difference. The one who spawns more sprites is the winner.

The only thing I noticed in C2/C3, is picking and loops that sometimes feels like it's using more CPU or has more overhead than it should have, and would probably be faster in javascript, or native code, but I don't have anything to compare with, so often it seems like behaviours are a lot faster for these kind of things.

Another thing is draw calls.... I'm not sure if this is faster on native or not, but it scales with how many sprites on screen. This will use more CPU the more sprites you have on screen.

As picking/loops and draw calls scales with # of sprites, maybe this the only bottleneck in C2? A badly optimized game, would have less resources for draw calls, so slower rendering?

So my conclusion is that the only thing that could probably be faster in native, is draw calls and loops, but the actual rendering is just about as fast. More sprites & effects in C2, would have more overhead maybe?

I could be wrong but that's just my observations from my own testing, and I havn't done any cross engine testing of this.
Last edited by tunepunk on Mon May 15, 2017 2:03 pm, edited 1 time in total.
Follow my progress on Twitter
or in this thread Archer Devlog
B
35
S
15
G
17
Posts: 944
Reputation: 12,210

Post » Mon May 15, 2017 12:31 pm

tunepunk wrote:I havn't done any significant testing, only some small ones for personal curiosity. But when it comes to rendering I didn't many any issues.

If you have a simple test scene running at 160 fps in native, but 60fps in WebGL, it doesn't mean native is double performance, as WebGL is capped at 60fps, so you can't really compare.

Disable V-sync in Chrome or in NW.js using the chromium arg/flag, to go above 60fps. That should really not stop anyone from providing good performance benchmarks.
Last edited by TheRealDannyyy on Sat May 20, 2017 4:59 pm, edited 1 time in total.
ImageImageImageImage
B
56
S
21
G
77
Posts: 637
Reputation: 43,963

Post » Mon May 15, 2017 1:28 pm

digitalsoapbox wrote:This is 100% untrue blaming-shifting nonsense.

Citation needed.

My statement is based on three things:
1) webglstats.com measures a wide range of devices and produces an overall support number of 96% (notwithstanding a minor recent bump). This matches data I've seen from our own measurements, and also matches what is implied from browser vendors talking about it.
2) The architecture of WebGL is basically a thin layer on top of OpenGL calls. So it works the same as a native engine. Once the calls reach hardware the GPU performance is identical. I am strictly talking about GPU performance here; if you have a game which is slow due to CPU performance, that is unrelated to what I am stating here. To work out if your game is CPU or GPU bound, you will need to make measurements and consider the data carefully, which I've not seen any evidence of many people doing before they start complaining about what they have assumed the problem is.
3) Many, many times I have been shouted down by someone who claims HTML5 is slow and doesn't believe this technical matter of poor quality drivers and GPU blacklisting, sometimes even accusing me of being deliberately deceptive. Then I ask for their game or some kind of evidence of why it's slow. Then I investigate. Then it turns out it was GPU blacklisting all along. If you are in the unlucky 4% it sucks, but that's not a fair representation of the wider hardware ecosystem.

Again, the irony is it's not HTML5 that is immature - it's the graphics drivers, which are native technology. As I repeatedly have to say to people who don't seem to believe this, graphics drivers are widely accepted to be terrible and can even completely ruin game launches. Here's two links to back this up:
Batman: Arkham Knight had such poor PC performance it virtually ruined the launch - it ran fine on console, where the drivers are good quality and predictable
"How to delay your indie game" specifically calls out struggling with GPU drivers: "Despite claiming to, their drivers just don’t properly implement the OpenGL specifications... Then a new OSX update will hit and everything will change again, yet at the same time I will need to still cater for the previous releases and older machines... it’s unbearable... Would I support Mac again? No."

In technology, knowing who to really blame is a surprisingly difficult and nuanced problem. It's rarely as obvious as it seems. For example lots of people, even engineers, blame the browser for bloated web pages.

I am so tired of this that unless you produce any evidence to the contrary, I will just ignore any further complaints. I would actually be super interested to see any evidence to the contrary, because I never do. And if you don't provide any, I would kindly ask that you take a less accusatory approach to the issue.
Scirra Founder
B
387
S
230
G
88
Posts: 24,251
Reputation: 192,454

Post » Mon May 15, 2017 4:22 pm

@Ashley - I'm just curious; how are you finding the GPU's that are blacklisted? When I search Chrome blacklist into google the only thing I can find is this:

https://www.khronos.org/webgl/wiki/BlacklistsAndWhitelists

Assuming this is correct, it seems to be only if you have drivers that haven't been updated in 8 years (or a couple cards I've not even heard of).
B
38
S
12
G
1
Posts: 526
Reputation: 4,085

Post » Mon May 15, 2017 4:41 pm

Just go to chrome://gpu and see what it says. WebGL 1 or 2 should say "hardware accelerated" in green. Construct will pick whichever one is hardware accelerated.
Scirra Founder
B
387
S
230
G
88
Posts: 24,251
Reputation: 192,454

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: zenox98 and 2 guests