Optimization, Performance HELP

"But as I started by saying I don't know that much about the C2 engine, but it doesn't seem very hard to kill it you want."

Clearly depends on too much things, I have a kind of bad computer (spelunky might be the only game I can think of I can play on it without too much lag, and sometimes there are), but never managed to get bad fps in C2 unless I do really bad design that wouldn't work in native anyway, other have better computer that cannot run properly a simple C2 game, it is just plain weird.

On this, don't forget that lot's of people have either graphical drivers outdated, lots of background process taking most of their CPU and RAM, especially in browsers, where the basic user has toolbars up to the head. "Cleaning" computers everyday, this is a lot more common that some could think.

I agree with you to some extend. However a lot of performance hit also comes from C2.

I made a small program here, that basically doesn't do anything except moving some small sprites around. You get a massive performance hit.

Which is caused by "on collision", there are added nothing to it. And you are not able to change the way this event works as its part of C2. Now in the program I have added that it should only trigger this if the speed of the sprite is above 0. Which ofc shouldn't make any difference to whether it should check for collisions or not, so removing it, makes no difference. And since the event doesn't actually do anything, it doesn't matter anyway in this test.

But that you cant configure when collision detects should take place, you actually get a performance hit, even though non of the objects starts out moving. As you increase the speed of the objects, it just completely kills it.

On my computer the moment I spawn 350 objects, the fps drop between 20-25 instantly. Even though these objects do absolutely nothing, except being on the screen.

Increase it to 650 objects, still doing nothing and it drops by 49-50.

So even though the computer also plays a part, the C2 engine or what to call it, will be the first thing to kill performance. Im pretty sure my computer can handle rendering 650 sprites :D

In order to improve performance when handling lost of objects, you would need to be able to control when and under what conditions for instant collision testing should even take place.

Whether you could do that with some distance calculations, and avoid the one that are build into C2 I don't know.

Here is the capx if you want to try it yourself:

Performance test

Sprite collisions with themselves doesn't work well at all (A sprite is overlapping itself constantly)

Bad point Of C2 I think personnally, families can correct that I think, but not sure yet

Also you are checking the collisions for each individual object, let's see...

Number_of_object? collisions I think

EDIT:Indeed, checking like that means you check collision of an object with himself, and so the number of collisions to check will be huge, not a C2 problem, every engine would have trouble with this kind of logic, try instead to check collision between 2 different kinds of objects, or add some kind of other test

Im not really sure if what you say is correct.

If i make 500 objects, and tell it to test for collision against the same object. I get 18-19 fps.

If i make 500 of another type, and test against them i get the same fps.

So could indicate that it doesn't make any difference, and it does the same amount of tests.

But my point was, that if you take that game i linked earlier, there must be something in the way they do, or handles collision detection that are different than how C2 handles it. As there are no problems in that game to have several 1000 objects interacting with each other. If its because they use some type of range to determine whether an object should do collision check with another i don't know. But I can place 500 objects on the right side of the screen, and make sure that they would never interact or even come close to the other objects, and still fps would suffer. So my guess is that "On collision" simply take one object, and test against every object that its told, regardless of the other object is even relevant for testing or not. And therefore it doesn't matter whether you test 500 objects of the same type against each other, if its different type, if these objects are even close to each other and so on.

ADDED***

Ok fooled around a bit and optimized it a little, so it can now run 5000 objects with around 30 fps, so it was quite and improvement :D

And can run 2500 objects with 60 fps.

But it seems that its correct that it just does a straight up comparison when doing collision testing.

Chrome 32 has a performance problem that's fixed in the next version. It affects node webkit as well.

On my computer, an AMD 4400+ and Nvidia 9800gt, it runs at 60 fps in Firefox, 67 fps in IE (odd...) and 60 fps in cocoonjs on both an ipad 3 and iPhone 4S.

Not sure why your laptop is having a hard time with it, but laptops are generally a lot weaker than desktops. Thoughts about what could be causing the issue: sometimes performance on laptops is reduced by having them unplugged, you could have an 'abandoned' card that isn't getting updates for its drivers anymore, if you're not using aero you're not getting hardware acceleration for the window manager, your card could be blacklisted.

Aside from that, I'm not sure. Performance is a frustrating topic sometimes, as it seems it should be simple, but isn't. :/

nimos100 - checking 500 objects against 500 others is 250,000 collision checks per tick. That's a lot. There are ways you can cycle through them and only check them in batches, and a lot of what's going on in that video with the moving objects doesn't actually require collisions at all.

Oh well it didn't work, it just seemed like it.

nimos100 - checking 500 objects against 500 others is 250,000 collision checks per tick. That's a lot. There are ways you can cycle through them and only check them in batches, and a lot of what's going on in that video with the moving objects doesn't actually require collisions at all.

Yeah that's the same amount i got to, but i cant seem to figure out how to do that, because it my eyes, it doesn't really make sense to check for collision if the objects are not even close to each other.

But i tried adding something that would turn collision on/off, based on distance but that doesn't work well, it completely kills it, well i can make it run with 500 objects and get around 38-45 fps, but its not smooth, but look kind of funny as i have made them change color when they turn collision on/off :D

Im not sure how they do it in that game. But since each of the objects stop when they collide with each other, there must be something that check if that's the case or not. So it would require a lot of tests, regardless of it being "true" collision detection or not.

nimos100 - I checked your performance test.

I made a small program here, that basically doesn't do anything except moving some small sprites around. You get a massive performance hit.

Your capx is far away from just moving some sprites around. It's moving 650 sprites around and doing 422,500 collision checks every tick.

Which is caused by "on collision", there are added nothing to it. And you are not able to change the way this event works as its part of C2. Now in the program I have added that it should only trigger this if the speed of the sprite is above 0. Which ofc shouldn't make any difference to whether it should check for collisions or not, so removing it, makes no difference. And since the event doesn't actually do anything, it doesn't matter anyway in this test.

The event most certainly does something - the collision condition is what's slamming the CPU. Conditions take CPU time, too, and in this case it's a lot of it.

You also set up the event wrong. You have:

On sprite collision with sprite

Sprite bullet speed is > 0

This means c2 misses out on all the performance benefits because it does all the collision checks first, which is the more intensive task. The filtering happens top to bottom, so what you should have done was:

Sprite bullet speed is > 0

If sprite is overlapping sprite

Doing that gets 60 fps on my computer. Checking the bullet speed is a far, far faster operation than the collision checks, so by filtering them out first, c2 doesn't have to do any collision checks at all.

On my computer the moment I spawn 350 objects, the fps drop between 20-25 instantly. Even though these objects do absolutely nothing, except being on the screen.

I want to make sure you understand that just because the object don't appear to be doing anything, doesn't mean you're not slamming the CPU. The act of checking for collisions on them all every tick is intensive, even though there is no visible result.

So even though the computer also plays a part, the C2 engine or what to call it, will be the first thing to kill performance. Im pretty sure my computer can handle rendering 650 sprites :D

Again, this example is CPU bound, not GPU.

In order to improve performance when handling lost of objects, you would need to be able to control when and under what conditions for instant collision testing should even take place.

Which you can. You can set conditions, but they need to be BEFORE the collision check. That's why you use 'is overlapping' rather than 'on collision' so you can put conditions before it (trigger conditions have to be at the top of the condition list).

"Your capx is far away from just moving some sprites around. It's moving 650 sprites around and doing 422,500 collision checks every tick."

I understand what you mean, but i meant "IM" not doing anything, that i don't trigger anything for these objects, C2 does a lot of things, that's why the fps drops.

"On sprite collision with sprite

Sprite bullet speed is > 0

This means c2 misses out on all the performance benefits because it does all the collision checks first, which is the more intensive task. The filtering happens top to bottom, so what you should have done was:

Sprite bullet speed is > 0

If sprite is overlapping sprite"

You are correct about that, did a test earlier of these events, and found that the "On collision" is the one that does the biggest performance hit.

1000 objects, will reduce fps by 92.5% where the same test using overlapping, only reduce fps by 62.5%. So that could explain why you don't suffer that much when you use that.

"I want to make sure you understand that just because the object don't appear to be doing anything, doesn't mean you're not slamming the CPU. The act of checking for collisions on them all every tick is intensive, even though there is no visible result."

Yeah im aware of that :)

"Which you can. You can set conditions, but they need to be BEFORE the collision check. That's why you use 'is overlapping' rather than 'on collision' so you can put conditions before it. "

Yeah it does way better than the other. Agree.

So i made a new version :D

And got it running better by using a distance check. So can do around 2500 objects (1250 since half of them are colliding objects) and still keep it around 30 frames.

<img src="https://dl.dropboxusercontent.com/u/109921357/Image_1.jpg" border="0">

I tried to see if i could do some kind of Quadtree collision detection that i saw on the internet, that apparently divide the screen into areas for testing. So one area doesn't test against another area and so on. but couldn't really get it to work. :( And think it should probably be implemented into C2 it self, if it should even have a chance of being possible :D

Anyway here is the new Capx, if anyone is interested:

Collision test

To make a clarification about collision checking.

C2 previously used Brute for collision. This meant every object is compared to every other object based on the collision check event.

Since a few versions ago C2 now uses Collision cells. Collision cells divide the objects into rectangle based cells. this means the objects only need to check against other objects in the same cell. This is an improvement.... unless of course that the cell size is the size of your viewport :( boooo :( that's right. The screen you see is the size of a collision cell. That means your tests of object and collisions are back to using brute force.

I've insistd that C2 should use a quadtree, but I believe the reason ashley won't is because it would require a major overhaul to many of the behaviours. So don't expect better performance if everything is on the same screen,.

Anyways. there are two reasons why the OP is having a performance problem.

1. Your GPU is black listed on the browser

2. Probably un-optimized code. I've discovered lately that certain events eat performance on an every tick use :(

I re installed and updated the laptop, things work much better, still fortunately now i know i need some "code" improvements and you guys helped me a lot. Thank you.

I am happy that it was me, and not the engine, even if the engine still needs lot of work, with tests i guess i can do whatever i need.

Now to be clear, there should be a major topic or manual article, where proper usage of events is explained and update(since some structure can destroy your real fps, even if it shows 60), because this engine is advertised like an easy tool, but in reality if you dont have background in scripting(which i have, tho it didnt help this time, i wasnt carefull), you are pretty much screwed on performance.

For example in examples you see every tick > do something, pretty much everywhere, so a new user will use that without thinking and have surprises later.

Anyway this helped a lot, and i reached a few other topics that helped too.

Thanks for your time.

just like to mention that you can use on collision in a subevent, ashley comfirmed that it does work,

doing collision check every couple of ticks can be a huge save

i do this, system compare tickcount%2 = 0 (checks every 2 ticks)

subevent on collision

depending on how big and how fast your objects are you can up this number

something that could be tried to improve on this method (c2 internally)

having a collision budget, there's a timer that checks how long it takes for collisions to be checked, if more than you budget, it stops the objectloop and continue on the next tick where the loop has ended,

the way its now if you have more collision checks than you system can handle it drags down the performance just to make sure every object is checked, wich could potentially be spread over more ticks,

and further i also would like too see if splitting the actual screen in 4 or 8 could improve performance

Small update on my performance, bit of a PICNIC!

My graphics driver was out of date - updating it locks me at 60

nice, thanks!