hi

what does mean this "Make sure collision conditions are the first condition in the top-level event" ?

and as ashley say "is overlape=cell collisions (new method)" and "on collisions=brute force (old method)

so i think we should use is overlapping method for betterperformance

Hi, that's not what Ashley says in the blog in the r155 blog (link).

In "The new way: collision cells" he says: "It includes Sprite's On collision and Is overlapping conditions... "

and in Caveat 2 he says: "If Is overlapping (or On collision) comes after another condition which has picked certain instances, it can no longer use collision cells. Looking in collision cells returns all possible instances, not just those that have met prior conditions. If a prior condition picked a large number of instances, it must brute-force collision checks again."

Thus the official line is that On-Collision will use collision cells providing the collision check is the first event in an event group that picks or filters instances of an object.

— - you're helping someone from a post made in 2012...?

cacotigon - good point re collision cells and the performance difference; I didn't check the cell count when I was looking at it. It's like the engine is doing a for-loop check of each object for the on-collision trigger check...

It's as if is-overlapping uses collision cells but on-collision does a brute force check of the objects....

...Just to add - the main difference is that a second or subsequent overlap condition will not be registered by using overlap/trigger once, whereas the On Collision does detect multiple occurrences of collisions between multiple objects.

— - I had about the same - the On-Collision has a massive and surprising overhead to it. I would certainly use Overlap / Trigger Once if the situation allows; however, if you need to know whenever a collision happens to a new object, while another similar object is overlapping, the On Collision trigger seems to be the simple way to go (although I'm sure that you could use Overlap with an array for a much better result in situations like this). I'm pretty sure that Ashley said in another thread that the two methods in that example are essentially identical - but that clearly isn't the case!

This is quite an interesting finding but there is a marked differences between using "is-overlapping" with a "trigger once" compared to using the "on-collision" trigger. I've messed around with the example above to demonstrate this. This version includes drag and drop behavior, so you can select a green or purple square and drag it over the squares of the other color. Because of the squares' dimensions, if you drag a square to the other side of the screen it never stops overlapping at least one of the other types of object. Give it a try and you'll see different results for testing for an overlap and testing for a collision trigger. I added a text object to show the cpu time and fps, in case the debugger added some overhead that muddled the findings.

So, never say never use on-collision - just be aware of what you are asking the engine to test for.

Weird - I had only bubbles where squiddy should be.... It took a couple of hard refreshes and clicks on the link to get it to work properly. For comparison then, here's a screen shot of the v2 running - no difference to v1 as far as I could see.

[attachment=0:1ey8zjsa][/attachment:1ey8zjsa]

I'm wandering if you're using a lot of a 3rd party plugin... Not sure if that sort of thing could make the editor crash, although not that long ago a small text object memory leak was fixed - which gave similar symptoms. It's possible that a 3rd party plugin could be causing a memory leak - does this happen when you work on a new project as well? Also, thinking as I type, do you save your backups in the same folder as the main caproj file (so the backups contain archives of themselves)? Also, I once found that saving microsoft office word documents in the root of the c2 project would cause c2 to crash on save (when the word doc was open). I've now run out of ideas....

I'm not sure if this is a useful comparison because v1 of the demo allowed me to zoom around and force lots of graphics work of my gpu, whereas v2 of the demo doesn't move around (so should be 60 fps, right?). I took these screen shots of chrome developer tools showing the javascript work being done per frame and, where there are gaps, the dropped frames. Version 1 dropped something like 1/5 and version 2 dropped something like 1/10. It would be interesting to make a comparison with a version made with r198 that allows for zooming around. If there's no difference between v3 and v1 then the problem is more likely to be of chrome's making. Such a comparison might show a difference in dropped frame rates - and if there is a discernible difference in dropped frame rates under similar loads then that would indicate that some of the problem could be down to the c2 engine. I have just reached the limit of my understanding...

[attachment=1:264w5cbi][/attachment:264w5cbi]

[attachment=0:264w5cbi][/attachment:264w5cbi]

I did some testing to see what triggers the janking on my laptop. My earlier result of 1280, the design resolution, being the cut off was probably just a fluke / caused by the slight loss of performance associated with rendering at higher resolutions, and it might have been influenced by my having developer tools running...

The jank seems to be only dependent on the number of pixels that need to be rendered each tick - lots of large area overlapping objects or large objects that move quickly seem to be the culprit.

It seems like my GPU can only handle a certain amount of pixel drawing work when drawing the canvas before frame drops start. Thus if I draw 2k moving large sprites the frame rate is poor, even though only 100 of them might be visible due to z order. Make the sprites small, so the overall pixel area they cover is reduced, and performance goes up - that seems to not be a function of the sprite original image resolution but just related to its draw size.

Not sure if this helps though because it just seems that there an upper limit to the number of pixels that can be smoothly drawn, a number that is different for each piece of hardware. If you allow nw window scaling then the player can at least select a window size that is playable on their machine, and perhaps the forthcoming jank fixes in chrome will also help.

Just guessing about the possible gpu loading with upscaling an image from a lower resolution compared to effectively downscaling a HD image at all game resolutions. Having just read through the other thread, my suspicions as to the cause are the same as yours.