C2 Performance, let's be honest...

0 favourites
From the Asset Store
Firebase: Analytics, Dynamic Links, Remote Config, Performance, Crashlytics on Android, iOS & Web Browser
  • 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:

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

    Okay...need sleep...<img src="smileys/smiley12.gif" border="0" align="middle" />

    Cheers,

    Tim

  • 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.

  • 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

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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...

  • 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).

  • 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...

  • "under performs"?

    What are you comparing it to?

  • 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...

    Haha, Im simply firing away, as mentioned <img src="smileys/smiley2.gif" border="0" align="middle" />

    ~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 ?

  • 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

  • It under performs when set against the expectations of the end user in today's high spec gaming world...

    I love the challenge of squeezing a few extra frames per second from a project by reworking a few events, I guess that's half the attraction for me, and I really appreciate the effort and passion the Scirra team have put into the C2 engine, I have seen it's performance improve leaps and bounds from it's early days...

    But recently the engines core simplicity and compact size seems to be getting wieghed down, as more features are added, performance seems to be taking a nose dive...

  • Its really hard not to go full flame when you say your using old hardware, but your users are from a high spec gaming world.

    Wouldn't they use modern machines?

    It doesn't have to be from this decade, but geez half that would be nice.

  • newt Your comment makes no sense, the "high spec gaming world" is the cutting edge backdrop that is perceived to be the norm...

    The modern phone,tablet or mid range laptop would still probably not out perform My old desktop...

    So you suggest we just wait until all hardware can run a C2 game well?

    Sounds familiar...

  • Yeah I don't know, the sense I get is that C2 is basically still a beta-stage product for many of the platforms it supports because it has a slew of dependencies most of which are still heavily changing and in flux, and just downright incomplete. You can't really trust features to work consistently on different browsers or machines, especially not just out of the box, whether it's performance or just functionality. I still think the product is more than worth the price for what it does, but it does set too high of an expectation in its marketing.

  • Juryiel I agree 100%, C2 needs in house exporters for the obvious offending platforms...

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)