Disappointed over bad communications!!!

Discussion and feedback on Construct 2

Post » Tue Apr 14, 2015 9:49 am

Blacksmith wrote:Unfortunately I've been hearing the same old excuses week after week... month after month, since I started using C2 some 3.5 years ago. And for a while I kept hoping the improvements we needed were just around the corner (as promised). But the same problems I experienced when I began using C2 (poor performance, lack of robust 3rd party wrappers etc.), still persist. Despite the many assurances we constantly see in the forum.


Well, recently @Ashley said that in about 1 year situation should be better.

And even if there are possibilities for better performance (like Cocos2d-JS):

Cocos2d-x JSB for C/C++ is the wrapper code that sits between the native code and the JavaScript code. JSB enables calls to the native code using JavaScript and vice-versa.


http://cocos2d-x.org/wiki/Cocos2d-JS

Ashley always says that he will do nothing to improve situation on his own. Because browsers are better. And we can wait. And everyone everywhere depends on 3rd parties. And so on.
B
18
S
6
G
1
Posts: 783
Reputation: 4,187

Post » Tue Apr 14, 2015 11:06 am

If you have concerns about mobile performance, please, please, please:

- make a .capx
- make performance measurements
- share the .capx and measurements

It is incredibly frustrating to read long threads about supposedly poor performance and yet not be able to do anything at all about it. On page 4 of this thread, all I can do is shrug and say I don't see what you're seeing, apart from maybe acknowledging that Chrome has had a rough patch of bugs which has affected smoothness and performance (and NW.js and Crosswalk inherited that), which is Google's responsibility, and not to do with Construct 2 or its engine. I saw another thread like this, something like 20 pages long, and I got a single .capx out of it. I profiled it and managed to make some improvements for the next build. That was a useful improvement. But I cannot make performance measurements and code optimisation improvements from complaints on the forum alone. If you really want to make a difference, the conversation about performance needs to be focused on real examples with actual measurements, not just talking about it.

Often the next argument is "you depend too much on third parties like Chrome", followed by a suggestion to use a different third party engine like HAXE or some other library, which could equally cause problems, and IMO is more likely to since few of them have the backing of a billion dollar corporation with thousands of engineers. No software is perfect; everything has its issues; the fact one platform has issues is not an argument to go through an incredibly disruptive technology shift to another platform that has fewer development resources going in to it.

Often then people send us .capx projects which clearly hit hardware limits, for example they hammer the GPU fillrate incredibly hard, or use tons of intensive shader effects. Native apps use the same GPU, so a native engine won't save you: it's still the same hardware, and will still be just as slow. A native engine will only help if your game is CPU-bottlenecked. Of the CPU-bottlenecked projects we see, often they do crazy things in clear contravention of our performance tips to an extreme extent. Badly designed games will still run badly no matter which technology you use. I don't mean to blame everyone here for designing their games badly, but of the .capx files I am actually sent, this is frequently true; if you think this is the case even with a well-designed game, see my request at the top!

I had the opportunity to profile The Next Penelope - one of the most ambitious games developed with C2 - and look for any performance bottlenecks. It was running very well and the engine was holding up great: it had a very even spread of CPU load across lots of small functions, with no obvious bottlenecks, and good overall performance. I think that at least proves that well-performing ambitious-scaled games are possible, and that there are no obvious performance deficiencies in our engine (as in the JS code we've written).

The asm.js version of Box2d should run within 1.5x as fast as native C code according to Mozilla's benchmarks, and it's still improving. Performance issues in physics games using asm.js physics are probably either due to maxing out the CPU due to too intense use of physics, or it's not actually physics which is causing the performance problem at all.

When people run in to hardware limits that native engines would also face, or even come up with some crazy game that does something like hammer pathfinding across a huge map every tick and find it eventually chokes and dies, the impulse seems to be to immediately blame HTML5 or the browsers or our engine. Of the projects I see, this is frequently unjustified. Again, please, send me real examples so I can examine them and make any necessary improvements. Make this about .capx files and measurements, not just long forum threads.
Scirra Founder
B
386
S
229
G
87
Posts: 24,207
Reputation: 191,602

Post » Tue Apr 14, 2015 11:23 am

Ashley wrote:Make this about .capx files and measurements, not just long forum threads.


But then everyone will see how bad a game maker I am. Its easier to just blame you... :lol:

There are some serious games being developed with C2... the difference between flappy xyz and these developers - these guys have mastered the software.
You think you can do these things, but you can't, Nemo!
Just keep reading.
Just keep learning.
B
65
S
16
G
9
Posts: 1,429
Reputation: 12,708

Post » Tue Apr 14, 2015 12:17 pm

@Ashley If I had the time to put 1.5 years into a game made just to demonstrate areas of slowness in C2 so you can be able to check it out then I'd really love to, but right now I don't, and I can't recreate the issues on smaller scale. In the end, if a customer with way better hardware specifications and latest drivers has issues (that I don't with a 5 year old PC) then I think the issue is not in reaching the limits of the system.

The Next Penelope does appear to run pretty good, and I'm starting to wonder if that's because there is no platform behaviour. In our game almost all the enemies and player objects have platform behaviour, and based on discussions on the forums that is where others find slowness too. It seems like TNP is heavier on GPU usage than CPU usage as well, so that's probably another reason why it runs better than most big C2 games. Racing games in general seem to perform and look better than other games though too.

Would it be possible for you to add an export mode in C2 that embeds debug controls and data capturing? This way people who can't replicate issues in a small capx, and who can't give their source code away freely, are able to produce information you can use.
"Construct 4 lets YOU make advanced games! (but not play them)" Construct Classic - Examples Kit
B
111
S
38
G
17
Posts: 2,175
Reputation: 19,045

Post » Tue Apr 14, 2015 12:47 pm

I'm sad to hear that a custom exporter is not on the drawing board, even for C3. :(
I don't want to use months or years of optimizing my games, and then suddenly a 3rd party destroys it all, anyway.

I know for a fact that unity runs super smooth with all the latest small game ideas i've been doing. So something is definitely wrong with C2. And i don't think any amount of Capx files will help, when there is no control over the exporters.

But i think its time for me to learn other tools, and in the meantime i will drop by every month to check up on C2/C3.

But i still have huge respect for the Scirra team, they developed a great editor, that is easy to learn and understand. That is your biggest plus in my book.

I don't think something simple like this would even be possible in C2 for mobiles:
https://www.youtube.com/watch?list=PL9B ... tDaDgb6dhU

But yet, Unity runs wit no problems whatsoever, with many collisions, and not lag..
B
37
S
9
G
8
Posts: 541
Reputation: 8,554

Post » Tue Apr 14, 2015 1:33 pm

@Ashley

On page 4 of this thread, all I can do is shrug and say I don't see what you're seeing, apart from maybe acknowledging that Chrome has had a rough patch of bugs which has affected smoothness and performance (and NW.js and Crosswalk inherited that), which is Google's responsibility, and not to do with Construct 2 or its engine.


so we should contact Google and blame them that we paid for Construct 2 and we can't have smooth games on Android?

Even crappybird clones?

crosswalk-performance-mega-thread_p901687?#p901687

@Jayjay

I'm starting to wonder if that's because there is no platform behaviour. In our game almost all the enemies and player objects have platform behaviour, and based on discussions on the forums that is where others find slowness too. It seems like TNP is heavier on GPU usage than CPU usage as well, so that's probably another reason why it runs better than most big C2 games.


You might be right.
B
18
S
6
G
1
Posts: 783
Reputation: 4,187

Post » Tue Apr 14, 2015 2:32 pm

Jayjay wrote:@Ashley If I had the time to put 1.5 years into a game made just to demonstrate areas of slowness in C2 so you can be able to check it out then I'd really love to, but right now I don't, and I can't recreate the issues on smaller scale.

Minimal .capxs is just for bug reports. For performance testing I will happily profile an entire project. If you can't send it over then there are a couple of options:
- signing an NDA (this is a pain in the ass, but I will do it for special cases if say the publisher requires it)
- just run the Chrome Javascript profiler yourself, which is what I would do with your project to examine its performance. This should show up any bottlenecks in the C2 engine. I think it also lets you export results so they can be shared, or failing that, just print screen the top results and send them over.
- For a high-level view of event usage the C2 profiler gives a good indication of any performance bottlenecks in the events, but remember events are yours and up to you to optimise. A super fast engine will only help so much with inefficient events. I'd only use this to give some general advice on which of your events are the slowest.
Scirra Founder
B
386
S
229
G
87
Posts: 24,207
Reputation: 191,602

Post » Tue Apr 14, 2015 5:00 pm

Hello;

95% of the people who buy C2 never get close to finishing a game. Sad, but this is even true of Game Maker. We all have big dreams. I think C2 caters to the right audiance when they make it very easy to get up and started.

I think C2s great, but I'm not close to finishing the 8 or 9 games I've started.

yours
Winkr7
B
32
S
8
G
3
Posts: 166
Reputation: 3,249

Post » Tue Apr 14, 2015 5:29 pm

Well, but depends....I mean, so much people need more performance...sometime is true, but in the most case is because people made bad process and use a bad way to make their games... in the forum I see a lot of mistake in the examples, I see a lot of bad ways to reach something...

Actually I never finish a game, I made different prototipe of some games, and they works great, my problem is how to make the gameplay/level....

I had to quit just one game because of the performance, but because I was using a lot of graphics in HD,

in the mobile, is crazy to think "I want a perfect performance..." if you want the perfect performance, you have to programm everything with the native code, that is the easiest way to make your game better, HTML5 isn't ready now the mobile game if you want to make a fancy game...

anyway, in the future will be easier to make games in html5, and the hardware can be ready for that
B
21
S
9
Posts: 298
Reputation: 2,967

Post » Tue Apr 14, 2015 5:35 pm

Ribis wrote:I had to quit just one game because of the performance, but because I was using a lot of graphics in HD

Lots of HD graphics is a classic case of hitting the GPU fillrate limit, which is a hardware limitation. This is exactly what I was talking about: you seem to think it's HTML5's fault and that a native engine would be faster, but it would still have the same hardware limitations. It's entirely possible this type of game would perform exactly the same in a native engine - no faster at all. This adds to my skepticism when people ask that we develop a native engine. It is not a magic bullet that makes existing hardware any better than it is.
Scirra Founder
B
386
S
229
G
87
Posts: 24,207
Reputation: 191,602

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: giangnd, Tokinsom and 1 guest