Scirra cog

About Us

We're a London based startup that develops Construct 2, software that lets you make your own computer games!


Browse all our blog posts

Latest Blog Entries

We love brains!

Join us! Joiiinnn ussss! Mooooree brains!

Optimisation: don't waste your time

by Ashley | 9th, May 2012

We regularly get questions like this on the forum:

"Which is faster: event A or event B?"

Sometimes they will also be asking if a specific event or a handful of events can be optimised, or if a particular behavior is faster than doing the same thing with events. Most of the time, the answer is "it makes absolutely no difference either way". You'll be wasting your time if you're worrying about it. It's like asking "which will make my car drive faster: when it's polished or when it's dirty?" - in response you think "um, neither... I guess it might be a tiny bit faster if it's polished, but the fact you asked probably means you don't really understand what's important about how fast a car goes". So let's go in to some more detail and see why that is.

Firstly, the most important performance indicator of a game is its frames per second (FPS) rate. Most modern displays update at 60 Hz, so the target of the game is to run at 60 FPS, so each time the display updates there is a new frame of the game to show. If the game runs faster than 60 FPS, there is no visual improvement! It will simply be drawing a new frame, then replacing it with a newly drawn frame before the display has had the chance to actually show it. So 60 FPS is as fast as it needs to go. That's also why many browsers don't go faster and cap the framerate at 60. Is your game already running at 60 FPS on your target machine? If so, you have nothing to gain by optimising. Nothing whatsoever. It's a waste of time. Why not spend some time improving your gameplay instead?

Secondly, games typically have two major processing jobs: processing the logic (running events, behaviors, testing collisions etc.), and rendering (drawing the sprites and objects on the screen). Our profiling has shown it's not unusual for even a fairly complex game to spend 10% of the time on the logic, and 90% of the time on rendering - even when hardware accelerated! In other words, if you're not getting 60 FPS, the #1 thing to do is think about how to speed up the drawing of the game. That might mean having fewer sprites on-screen, avoiding heavy particle effects, and so on. Remember your events and behaviors are part of the logic, which only takes 10% of the time. So even if you went to extreme pains and managed to get all your events and behaviors to run ten times faster overall, which is typically an impossible goal, you will just be reducing that 10% to 1%. The overall performance will just be a few percent better for hours and hours of work, and you could probably have got the same speed-up by reducing the rate of one of your particle effects.

The most common cause of poor rendering performance is software rendering (not using the dedicated graphics hardware to draw). On desktop systems that means your graphics card drivers are out of date, so try updating them. On mobile for the time being you'll need to use a wrapper like CocoonJS or directCanvas to get hardware-accelerated rendering. If you have poor performance, you should certainly try those things before anything else!

With a hardware-accelerated renderer, rendering is done parallel with the logic. In other words, every frame, the logic will be running at the same time the graphics card is drawing. This means the duration each frame takes to render, which determines the framerate, is whichever took longest out of logic and rendering. It's not the time they both took added together! So again even if you made all your logic ten times faster, chances are rendering still takes exactly the same amount of time, so each frame still takes exactly the same amount of time. You made your logic ten times faster but the framerate did not change. A complete waste of time!

This is partly why using a scripting language like Javascript is still fine for games. You'll see some benchmarks showing that in places C++ is 5-10x faster than Javascript. So porting our entire engine to C++ would get you up to a 10x logic speedup. But as we've seen that will often have no effect at all on the framerate. That's part of the reason we're happy to stick to a pure Javascript engine without diverting our limited resources to native ports: it's fast enough.

There are only a few select cases where the game logic takes longer than rendering and determines the framerate. These cases are usually obvious and easy to optimise as well:

  • Heavy use of the Physics behavior. Realistic physics simulations are extremely processor-intensive and having over 50 physics objects can reduce the framerate, especially on mobile. Simply using fewer objects usually fixes this.
  • Using too many objects. Having thousands of objects can make Construct 2 have to do a lot of per-object processing. Using Tiled Backgrounds instead of grids of sprites is usually the solution here.
  • Checking for collisions between too many objects. If you test for overlap between instances of an object with 100 instances, there are thousands of combinations of pairs of instances that Construct 2 has to check every tick, which can total over half a million collision checks per second. You can either check on a timer, e.g. every second instead of every tick, or simply reduce the object count again.
  • Long-running loops. Using a for-loop or repeating an event thousands of times every tick can demand a lot of logic processing. This is especially easy to do with nested loops. Again, usually it's not necessary to run every tick and reducing this to every second or just on certain triggers is fine.

That's just four points, and you can usually disregard the effect of everything else. Other things do have a performance impact, but usually it's too small to be of any importance, like the effect of polish on your car's speed. So don't waste your time. You could spend your valuable time improving your gameplay, refining artwork, or designing new levels and worlds. That's going to be a far more effective use of your time than spending time optimising things which will make no difference at all to the quality of your game.

Of course, these are all just rules of thumb. If you think something in your game is causing a big performance problem, it's easy to test: disable those events (or remove the behavior), and check the framerate. If it's a higher, bingo. If it hasn't changed, it's not important, so forget it! There's some more advice in the 'performance tips' manual entry.

Hopefully that gives you a good idea how performance works. It's not just about making things go faster, it's about judgement (knowing when or if you need to optimise) and planning (knowing what to try first). If you're wondering which of two events is faster, it's neither. Concentrate on your game!

Now follow us and share this



AppmobiTyler 2,698 rep

Great Post

Wednesday, May 09, 2012 at 2:00:36 PM
Albatr 9,237 rep

Good thing to know, thanks !

Wednesday, May 09, 2012 at 2:01:41 PM
noirfluo 6,941 rep

Interesting blog post ! Thank you :-)

Wednesday, May 09, 2012 at 2:10:26 PM
Anonymous1 3,311 rep

This was an excellent post for clearing up optimisation. I often wondered what the "Optimisation" hot fixes are that you see in major productions that have no effect what-so-ever on the FPS or even Latency. Fortunately in the HTML5/Javascript environment it is simplified even one step further.

Thanks for the clear post that will hopefully allow more new devs understand what exactly they should be concerned with.

Wednesday, May 09, 2012 at 2:18:41 PM
CyberDagger 2,638 rep

Great post Ash! I already knew that the rendering ate more resources than the logic, but I had no idea the difference was so large...

Wednesday, May 09, 2012 at 2:19:33 PM
Aritz 7,349 rep

Optimisation can be very addictive, fps are like a game score :).

Wednesday, May 09, 2012 at 2:46:16 PM
gammabeam 13.3k rep

Great post!
One of my secondary objectives with Bioclash (my Ludum Dare entry) was to check the performance when having lots of objects testing collision, positioning health bars and so on. I was amazed by the amount of objects on screen, moving/attacking/getting killed - all done without lowering the frame rate.

Now I'm less worried about creating for each loops!

Wednesday, May 09, 2012 at 2:55:49 PM
simwhi 6,279 rep

A very nice post Ashley. It certainly gives us something to think about where we place our efforts in the future.

Wednesday, May 09, 2012 at 3:02:00 PM
cesisco 10.3k rep

Nice post... and i will never wash my car again :)

Wednesday, May 09, 2012 at 3:29:46 PM
VampyricalCurse 8,336 rep

Excellent and informative.

Wednesday, May 09, 2012 at 3:38:06 PM
thiago 4,264 rep

Nice to read this. I´m a little paranoic about that.

Wednesday, May 09, 2012 at 3:45:55 PM
dssonthenet 3,325 rep

Good post!

Wednesday, May 09, 2012 at 3:49:26 PM
Bigheti 15.8k rep

I did not understand what it was for the FPS. Now I know thanks to your explanation Ashley. Thank you! I know that is not the appropriate place but I Ask: the use of gradient in sprites reduces the game's performance?

Wednesday, May 09, 2012 at 3:58:13 PM
Ashley 192.2k rep

<span style="background:yellow;font-weight:bold;">@Bigheti</span> - do you mean having a particular kind of image in a sprite? The image in the sprite does not matter at all, it can be very detailed or all the same colour and it is exactly the same amount of work to process.

I understand Ashley...tks!

Wednesday, May 09, 2012 at 3:59:23 PM
AJTilley 5,086 rep

Great post, its good to know that an extremely complex event driven game will not have a massive effect on the overall speed and running fo the game. I can instead focus on reducing the unneccessary objects.

Wednesday, May 09, 2012 at 4:00:11 PM

Leave a comment

Everyone is welcome to leave their thoughts! Register a new account or login.