Performance: in fairness

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.

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.

[quote:2srdfutv]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.

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

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

Because of what I explained in my earlier reply.

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?

Because of what I explained in my earlier reply.

Yes, but you added particles as an alternative to using sprites, and for those you don't use the collision overhead. Seems like you discarded that because it wasn't needed- so if a person has a case for not using collisions with sprites, then you say "well there would be no significant benefits from that method."

There are plenty of cases where a person can't use the particles because of the limited control over them, and have to resort to using sprites. It seems like the particles system is exactly something you shouldn't have created in the first place if you don't want to create multiple types of object for construct that are similar to each other.

So why not just modify the sprite object to be more customize-able and get rid of the particles? replace it with a plugin.

I know you can't do that though because you want to keep compatibility- I'm just saying..

Maybe I just don't understand this though, so if that's the case just ignore me.

So why not just modify the sprite object to be more customize-able and get rid of the particles?

My point is that is time consuming, difficult and would bring little benefit to most games, so there's not a whole lot of point to it. As I said before this is classic benchmark chasing at the expense of everything else, which can be actively harmful.

okay, yea- better to work on stuff that will actually improve the product.

I hope there are some comparisons for polygon collision performance. C2 sprite stress rendering testing result is good enough among all HTML5 solutions.

For anyone's purpose which is simply rendering massive sprites, you may consider to write a engine-less project (without polygon collision, layer parallaxing, SOL management...).