2D Engines benchmark 2021 - including Construct 3 results

Thanks simstratic,

1) I'm curious how such a pronounced difference can be possible between C3 and gamemaker if, as you state, gamemaker YYC export is compiling to entirely C++. Is this a case where JIT compiling can outperform C++? My guess is it probably has to due with the difficulties of replicating comparisons between different engines.

2) Can you go into more detail about the different ways you set up Construct 3s experiments? (Behaviors vs Events vs conditional expressions vs conditional expression with rotation) There are some significant differences between these results that could be relevant to those of us trying to squeeze out every bit of performance possible.

Thanks,

1Step

The only problem I see is that the browser just doesn't offer a viable monetization method. At least not in any way that would rely on being performant.

Windows Wrapper would most likely return equal results since it was done using Edge, but the wrapper is not a great option... yet.

1) I think part of it is because the GML scripting language is not typed, so even when it's compiled to C++ code, it probably has to do a lot of inefficient type checking/casting. And if I remember correctly, certain types of variable lookup can also be slow, which is why GameMaker people will often copy them into a local variable first. So it's not as fast as a C++ engine could be without a scripting language.

2)

a) Behaviours was simply assigning the Bullet and Wrap behaviours to the object. Wrap was set to wrap to viewport. In the create object event, the Bullet actions were used to set a random direction and velocity to the Bullet behaviour for that instance.

b) For the events, I deleted the behaviours from the object and I added two instance variables - sx and sy (speed x and speed y). Then in the event sheet - on create object I set sx and sy to random values. Each step I use actions to apply movement - i.e. set sprite x = x + sx*dt, set sprite y = y + sy*dt. Then there's a series of IF events to handle the wrapping:

if sprite x < 0 set sprite x to 800 (800 being viewport width)

if sprite x > 800 set sprite x to 0

if sprite y < 0 set sprite y to 450 (450 being viewport width)

if sprite y > 450 set sprite y to 0

c) Avoids all the if statements by putting it into a single conditional expression when applying movement to the object, i.e. each step:

action - set sprite x = x < 0 ? 800 : x > 800 ? 0 : x + sx*dt

action - set sprite y = y < 0 ? 450 : y > 450 ? 0 : y + sy*dt

These expressions allow you to 'short circuit' the evaluation, i.e. if the first part (x<0) is true then the rest of the checks will be skipped. This is what I wished the ELSE event would do...

Hope that makes sense...

The only problem I see is that the browser just doesn't offer a viable monetization method. At least not in any way that would rely on being performant.

Windows Wrapper would most likely return equal results since it was done using Edge, but the wrapper is not a great option... yet.

Yes, I am more interested in desktop publishing, not browser or mobile, so the new Windows wrapper definitely perked my interest, but for me it needs some Steam integration first (at least achievements) to be a viable option.

c) Avoids all the if statements by putting it into a single conditional expression when applying movement to the object, i.e. each step:

action - set sprite x = x < 0 ? 800 : x > 800 ? 0 : x + sx*dt

action - set sprite y = y < 0 ? 450 : y > 450 ? 0 : y + sy*dt

These expressions allow you to 'short circuit' the evaluation, i.e. if the first part (x<0) is true then the rest of the checks will be skipped. This is what I wished the ELSE event would do...

Hope that makes sense...

Wow, 25k difference by switching to conditional expressions?

I thought the else condition operates the same way, but with the downside of still having event block overhead unlike the conditional expression. This is interesting, thanks again for these experiments.

I thought the else condition operates the same way, but with the downside of still having event block overhead unlike the conditional expression. This is interesting, thanks again for these experiments.

I could be wrong, somebody correct me if I am, but I think the ELSE condition still checks every instance (not only those that failed the prior condition).

To give credit, it was eleanorjmorel who showed me how much faster conditional expressions can be.

As for ELSE, per the manual it is as you state. I use ELSE quite religiously, so this is good to know.

I used to use it quite a bit, but they changed negated, or inverted to work with just about everything.

Why not include C3 test project at least? I think bunnymark test usually does not use wrap, they jump up and fall down.

We've worked hard to make Construct performance shine, and it's nice to see that reflected in a microbenchmark. Modern JavaScript JITs are also extremely sophisticated and it's cool to see that they're competitive even with compilers.

However I'd caution against taking any performance advice from tests like these. As noted often you can get significantly different results by making obscure changes to events. However these changes usually only affect microbenchmarks that are hammering one code path super hard. Real games generally don't do that, so porting microbenchmark-level changes to real games will probably have no effect. So don't look at results like these and think "Wow, I should always use conditional expressions instead of conditions". Most likely you'll just needlessly obscure your events to no performance gain. As ever, with real games the only meaningful approach is to make measurements, and target optimisations at the things you've actually measured are slow, and only keep optimisations that measurably improve things.

A thing to be aware of when doing micro-benchmarks is what you are testing.

In case of "bunnymark", it is "how many moving objects with little to no logic can I have", which, assuming that each respective engine has the general competency of using GPU for rendering and batching same-textured objects together using vertex buffers, effectively translates to "how little overhead there is to an object that has a sprite and nothing else".

The results are consistent with expectations:

• GameMaker historically has a certain amount of "luggage" attached to instances, which has them check for velocity, check if they have timers to tick, tick animation frames, etc. Consequently, this also means that storing your buns in an array of structs or a ds_grid will yield much better results.
• Godot has a different kind of luggage - although objects don't have velocity and timers to calculate by default, they do have support for child objects and consequently calculate transformation matrices.
• Construct has little luggage - unless an object actively presents itself on the scene, it won't even have position variables. Although some of this advantage would fade as you add more complex logic to the objects, this makes it a good fit for this kind of comparisons, which had been the case for quite a while.
• You bring your own luggage for RayLib - with no entity system to boot, you likely wrote the exact amount of code to stuff your bun-structs into a vector and move them around, or maybe opted to use separate arrays per-property for better caching, or even used par_unseq to allow bun movements to be processed in parallel on multiple CPU cores, or even implemented GPU instancing... rest assured, the result unbeatable because the overhead comes solely from your own oversight.

In the end, what Ashley said - use the profiler to figure out pain points, and especially be wary of incorporating "cool tricks" that appear to perform better on synthetic tests.