Performance: in fairness

It's fairer to test the c2bunnyparticles test against Pixi, because they both use the same rendering mechanism. The c2bunnymark test uses general purpose sprites with more capabilities like collisions, so I don't think it's really fair to compare that to a particle renderer.

[quote:2ynzwm4t]Setting the render scale in runtime for lower/midrange phones would be nice

You already can, using low quality fullscreen mode.

[quote:2ynzwm4t]I hope you will get some time at a later point to investigate some further improvements to get a bit closer to the pixi score.

I already did, they basically use particles.

I already did, they basically use particles.

Oh cool, That means we should start building games out of particles instead of sprites for max performance.

Would it make any sense to have more object types then? that doesn't use collisions etc, kind of like a stripped down version of the sprite object?

For I'm currently playing the Paster plugin, load my whole layout on to the paster object instead of sprites and tile maps, and then use hidden dummy objects for collisions.

Seems a good comparison now then would be Unity particles and also optimizing the Construct 2, Godot, and Unity sprite benchmarks for retesting

There are numerous times when I use sprites, yet have no need for their collisions. Particles are too limited because they can't be controlled in the same way. It would be nice to have ability to remove that collision overhead from the specified sprites.

Come on guys, most of us aren't that adept. In the beginning, we all were and most of us still are very happy and grateful for the relative ease and simplicity of use of C2. I mean where is a non-programmer gonna go to make a video game, a first one anyway without a ton of time and cash? Even pros love C2 because it shortens development time so much.

Can you test DT fluctuations on everything too?

Like keep count of frames when DT is over 1/50 for example.

If you test C2 please make sure you replace the "For each" condition ...So I looked in to Pixi's code .....So I made a similar test in C2 using the Particles object instead, and you can get similar performance gains.

Testing on a HTC 10:

Sprites: https://www.scirra.com/labs/c2bunnymark/ - ~5500 30 FPS

Particles: https://www.scirra.com/labs/c2bunnyparticles/ ~31000 30 FPS

Particles are super fast, over 5x faster at rendering! ....... particles don't process collisions ........

just butting in being an ass ....but considering the above, then The Manual needs an update....

quoting under particles "......Particle effects are more efficient than creating the same effect with Sprite objects, but not by a large margin......."

but the tests show said margin is actually pretty large.....

this manual is saying to me "....go ahead and use sprites for that massive particle bomb /all that smoke / dust explosions etc because sprites have so many extra features and negligible performance hit over particles..."

Adding a new object that uses the particle rendering method is a classic micro-optimisation. As I described before it makes a difference on the order of a few hundred nanoseconds per object. I honestly doubt many real-world games would be meaningfully faster with the particles rendering method. Meanwhile it complicates the engine, since you more or less end up with two kinds of sprites, which confuses beginners ("which should I use and why?"), and it means more time to develop and maintain, when we have far more compelling things to be working on. Wouldn't you prefer us to do advanced text features or a built-in canvas plugin or other more useful things like that? We're a small team and we can't do everything. These are the things that would fall by the wayside if we chased benchmark results.

This is how benchmarks can actually have harmful consequences if you slavishly follow maximum performance at the expense of everything else.

Computer Specs

Pixi

51-60 fps averaged out at 55

Construct 2

stable decline to 54

8960 bunnys

Unity

9051 bunnys

Unstable fps randomly jumping from 54-65

Godot

4670 bunnys

31 fps

Honestly, I don't think performance measurements at 50-55FPS are useful. You should run it all the way down to 30 FPS and measure there.

From what I can take from these tests it's that construct 2s rendering backend is about 10xs more stable than pixi js and unity.Construct 2 has a more stable decline in fps as more bunnies appear on screen compared to unity and pixijs that seem to jump a bit

Construct 2 (30 fps)

Unity(wonky 30 fps)

15,801 bunnies

I stopped at this level cause unity was dipping down into the 20s and spiking up into the 50s

Pixijs(30fps)

Ashley

Games with many objects are often rich with environment sprite, making the game prettier.

The option to disable collisions for sprites, does it remove the mentioned overhead of vertex info sharing ?

New better optimized version for Godot:

Intel i7 920 and GTX580

C2 Chrome: 59/60fps 7790 bunnies

Godot: 59/60fps 6740 bunnies

https://godotdevelopers.org/forum/discu ... erformance

The option to disable collisions for sprites, does it remove the mentioned overhead of vertex info sharing ?

No, but for real-world games this probably makes no meaningful difference. Also if a sprite is decorative and doesn't move, it never has the overhead of recalculating its collision box, which is much of what bunnymark is profiling.

No, but for real-world games this probably makes no meaningful difference. Also if a sprite is decorative and doesn't move, it never has the overhead of recalculating its collision box, which is much of what bunnymark is profiling.

Ok so decorative and not moving ... What about collision detection with various other elements which do move, such as bullets being fired, hud elelements, player and npc objects or even other scenery objects (birds, bugs, smoke, rain)

On a big map, could these detections, noticeably, rack up?

If so, is it possible, when disabling collision detection, to actually have that bit skipped so it does not share the vertex info to reduce that bit of overhead?