C2 Performance, let's be honest...

Discussion and feedback on Construct 2

Post » Tue Feb 18, 2014 3:23 pm

Warning: mega-post to follow:

There are two aspects to performance in C2: rendering, and event speed. Usually, the rendering's at fault. Be sure to CHECK THE DEBUGGER. Look at 'draw time'; if it's eating up a bunch of cpu, you are software rendering (chromes WebGL issue, blacklisted card, drivers...). If your cpu usage is low, but your fps is dipping, then your gpu -- for whatever reason -- is simply not up to the task.

OTOH, if you are getting slowdown from event logic -- and don't have a weak cpu -- chances are there's a glitch in your code, unless:

1. You have a few thousand moving sprites looking to collide with each other or a few thousand other sprites. If they are very spread out, the collision cells optimization should help a lot with this, but if they are all clustered in a small area, your speed won't be much better than brute force (and possibly worse). There no way around this; it's a limitation that all developers have to deal with. Try checking for cols less often, or just bring your object count down.

2. You are being irresponsible with demanding behaviors like line-of-sight, pathfinding, and physics. Again, these are demanding for all developers, whether hand coding or using a higher level tool like construct. Line of sight in particular can bring a game to it's knees if used foolishly. Like, for example, adding it to every enemy to look for the player, leaving range at default (10,000), and updating every tick (try putting it on the player, bringing range down to width-height of screen /2, only updating every 0.1 second).

Continuing on event logic speed:

All event logic is outputted as javascript. Javascript was not built to be a smooth, realtime language. It's proliferation has lead to it being developed into one, but it's been a long and arduous process. The two main drivers now are google(chrome) and mozilla(firefox), who have improved javascript performance dramatically. Without their efforts over the last 5-6 years, construct 2 would not even exist.

That being said, there are some inherent limitations to javascript:

1. It must be compiled and/or interpreted on-the-fly. This adds a greatly variable overhead, depending on what the particular javascript engine is doing with incoming code.

2. It can only run on one thread at a time (excepting web-workers, which are reletively new and very limited). Some modern cpu's have as many as 8 cores, with two threads each. In that case, your game would only have access to 1/16 of the cpu's actual capacity. That being said, most high core/thread count cpu's are either server cpu's(not suited for general use) or performance cpu's(crazy fast to begin with), and many multicore cpu's can clock up for demanding single core usage, so this is less of an issue than it might appear.

3. It has to perform garbage collection. (along with dynamic compilation, the main cause of 'jittering' in games). Asm.js can get around this, but only for asm.js code, and only when run in firefox(for now).

4. It cannot take advantage of many of the low-level processor optimizations -- ex., SSE2, SSE3, AVX -- that are available to traditional C++/assembly based applications. For certain kinds of proccesing, these can speed up execution by 10-20 times. In theory this is possible with JIT(just in time) compilers, but no one has implemented it in a JIT javascript engine. These may also be accessible at some point thru asm.js implementations...or it may be impossible. I don't know enough about this subject to have a valid opinion on usefulness or feasability.

--------------------------------

Bottom line: javascript is slower than native, but the gap has narrowed dramatically in the last few years...and with time, things will only get better.

...and on that note, here's some fresh news on the subject:

http://www.zdnet.com/google-revs-chromes-v8-javascript-engine-to-drive-high-performance-web-apps-7000026409/

Okay...need sleep...

Cheers,
Tim
Don't lose your work. Backup your game with Dropbox.
B
44
S
10
G
10
Posts: 1,106
Reputation: 9,202

Post » Tue Feb 18, 2014 4:10 pm

As another person posted. Calculating angle per tick is costly. The code in quest for mine was very similar.

Per tick angle towards touch/xy or mouse/xy(i stored touch/mouse xy into a var xy depending on which was activated). I then figured out the angle to the xy per tick. I then also changed the bullet speed of the player based on distance by use of a lerp(). Overall this pretty much hitting my performance. The think is only the player box used this math.

So when on mobile performance that's a few ideas to keep in mind. Reduce the usage of angle() and lerp() to be called less often. Possible even considering creating a pre designed table for quick looks up rather than doing the math all the time.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,038

Post » Tue Feb 18, 2014 5:27 pm

Iv seen someone on Polish forum says 'i use MMF developer 2 because performance is better than C2 performance' Performance should ve upgrade on all relases
B
111
S
28
G
48
Posts: 1,882
Reputation: 36,428

Post » Tue Feb 18, 2014 6:49 pm

You can't have only advantages without having disadvantage: C2's flexibility comes with the price of not exporting native games.

Still, I find C2's performance really good (with WebGL), especially for it's price.

If you want the best performance and native export then learn a programming language and spend at least twice the time in other engines to make the same actions you would make in C2. Also you would need to optimize your code for every platform otherwise your game would look like a bad Android port from iOS.

And hardware is dirt cheap nowadays, you can buy an used DualCore PC (with integrated GPU capable of decoding at least 720p) or an Android tablet for less then 150$.

Also Windows 7/8 is better than XP in many ways. Unless you have a really old PC (SingleCore and less than 1GB RAM) I don't see any reason not to go for Windows 7/8.
B
49
S
15
G
6
Posts: 535
Reputation: 7,197

Post » Tue Feb 18, 2014 7:31 pm

@TGeorgeMihai

There are many and varied game development tools out there, are you suggesting we should all drop game engines and go learn a language?

Not sure if Your advising me to upgrade my PC or My Operating system to windows 7, but don't waste ya breath, just tell those who buy your 20 meg web game, when it's running like a three legged donkey...
As long as I can move left, right and fire, I'm Happy...
B
42
S
15
G
11
Posts: 655
Reputation: 12,270

Post » Tue Feb 18, 2014 7:50 pm

Pixel perfect, I'm guessing he is saying that in order to develop a somewhat best optimised game you should program in code, but that it takes up a lot of time to do it decently.

I do however see a major advantage in knowing other scripting languages ... understanding those basics, and seeing how contruct interfaces the ide to create exported code, can give an huge leg up in skills and understanding how to apply any potential possibilities, options or approaches and the know how in bug/problems tracing.

And you are right, you can not tell a customer to upgrade their hardware.
That is why there are requirements specifications and device limitations.

Thus testing is crucial on a variety of hardware in order to determine a good hardware range. Preemptively, informing a potential customer what is needed to run th game.


I some times get the idea from new developers that they look at construct 2 programs like cars, and exepct all cars to be able to run at the same speed. But in fact, the car itself (program) determines the speed, and is obstructed by bad roads (hardware).
Who dares wins
B
57
S
17
G
21
Posts: 1,878
Reputation: 19,572

Post » Tue Feb 18, 2014 8:21 pm

@lennaert is this turning into the "How do I" topic, mentioned in first post?

Your loyalty to C2 is commendable and I share it, but don't let the rose tinted glasses fog your judgement...C2 under performs on average spec hardware...

And yep, agreed background knowledge really helps, been working in the gaming / PC business for what, about 25 years now...
As long as I can move left, right and fire, I'm Happy...
B
42
S
15
G
11
Posts: 655
Reputation: 12,270

Post » Tue Feb 18, 2014 8:28 pm

"under performs"?

What are you comparing it to?
Image ImageImage
B
170
S
50
G
179
Posts: 8,379
Reputation: 113,427

Post » Tue Feb 18, 2014 8:31 pm

[QUOTE=Pixel perfick] lennaert is this turning into the "How do I" topic, mentioned in first post?

Your loyalty to C2 is commendable and I share it, but don't let the rose tinted glasses fog your judgement...C2 under performs on average spec hardware...

And yep, agreed background knowledge really helps, been working in the gaming / PC business for what, about 25 years now...[/QUOTE]

Haha, Im simply firing away, as mentioned


~20 years here, mostly IT tech related and programming, only been into game creation the last few years :)

You say it underperforms, that suggests you have an equivelant to compare it to ?
Who dares wins
B
57
S
17
G
21
Posts: 1,878
Reputation: 19,572

Post » Tue Feb 18, 2014 8:53 pm

I wonder how this topic didn't get yet into HTML5 performances instead of C2's Performance, C2 is a great HTML5 engine, but it is an HTML5 engine, maybe that is part of the problem, how HTML5 works on older computer
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 15 guests