Performance: in fairness

Discussion and feedback on Construct 2

Post » Fri May 26, 2017 3:13 pm

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)
Image

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
Image

Pixijs(30fps)
Image
B
22
S
11
G
33
Posts: 54
Reputation: 18,435

Post » Fri May 26, 2017 4:02 pm

@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 ?
Who dares wins
B
57
S
17
G
21
Posts: 1,878
Reputation: 19,562

Post » Fri May 26, 2017 4:08 pm

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

Image
Image
B
2
G
3
Posts: 2
Reputation: 854

Post » Fri May 26, 2017 7:17 pm

lennaert wrote: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.
Scirra Founder
B
387
S
230
G
88
Posts: 24,254
Reputation: 192,470

Post » Sat May 27, 2017 4:34 am

Ashley wrote: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?
Who dares wins
B
57
S
17
G
21
Posts: 1,878
Reputation: 19,562

Post » Sat May 27, 2017 5:40 am

Ashley , you say this; "I honestly doubt many real-world games would be meaningfully faster with the particles rendering method."
but then why does Construct particles use that method? You must have seen some benefit of adding that in the past. So why all of a sudden say that it wouldn't be helpful in any real-world games?
I'm a bit confused.
B
41
S
19
G
65
Posts: 1,085
Reputation: 37,842

Post » Sat May 27, 2017 1:33 pm

lennaert wrote:What about collision detection with various other elements which do move

In this case the collision checks will be far more significant, making the performance overhead of the individual objects negligible.

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?

See my earlier reply.

Prominent wrote:but then why does Construct particles use that method?

Because particles are an obvious and easy isolated case in the engine where you might actually create several hundred of the same "sprite" (although the individual particles are not really sprites).
Scirra Founder
B
387
S
230
G
88
Posts: 24,254
Reputation: 192,470

Post » Sat May 27, 2017 3:06 pm

Ashley wrote:
Prominent wrote:but then why does Construct particles use that method?

Because particles are an obvious and easy isolated case in the engine where you might actually create several hundred of the same "sprite" (although the individual particles are not really sprites).


So if I need to make several hundred of the same sprite (not particles), are you saying there is no benefit of having the collision stuff removed in this case? Why is it beneficial for the particles case and not the case I describe?
B
41
S
19
G
65
Posts: 1,085
Reputation: 37,842

Post » Sat May 27, 2017 8:06 pm

Because of what I explained in my earlier reply.
Scirra Founder
B
387
S
230
G
88
Posts: 24,254
Reputation: 192,470

Post » Sat May 27, 2017 9:08 pm

Ashley wrote: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.


Would it be possible for users to commission updates for Construct 2, Would it be possible to pay 1,000$ or so towards a new native feature?
B
22
S
11
G
33
Posts: 54
Reputation: 18,435

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: Garrey and 1 guest