Collision Events, framerate, and object picking

[Kid_Roleplay]

I've read that checking for collisions at the start of an event, particularly when there's a lot of them, can slowdown framerate.

Specifically, the ( "Object 1" ) collides with ( "Object 2" ) event.

I'm currently looking for ways to speed up my own game, mainly ways for larger objects that are animating to -not- slowdown the game, and so in hearing about this, I became curious:

1) Does putting the collision event any place but the first make the triggering of collisions just as reliable?

2) The collision code can also call for specific object picking, and other objects that may follow it or be connected to it in some way are easy to identify. Would this still work if the collision event isn't the first event?

3) Can you also call a specific object with the ( "Object 1" ) is overlapping ( "Object 2" ) event outside of fastloops?

[Pixelthief]

When you do a "Object 1 collides with Object 2" event, a lot of tricky stuff goes on behind the scenes.

Each scoped Object 1 will be iterated through, comparing its current collision position against the positions of all scoped Object 2's as they were at the start of the frame (the current loop through the code, not the beginning of the level, ie the 50 frames per second kind of 'frame'). Now how exactly the scoping is changed from there on is tricky. Afaik, both object 1's and object 2's will be scoped for only the instances that had any collisions in that check, and all non-colliding objects will be unscoped on both sides. This is different than most other code which is invoked on a single object but compares to another object, when normally it would affect the scoping of #1 but not affect any referenced objects (#2 or #3 or so on)
Note how Object #1 will use its current X/Y positions, which you could have set in a previous event, as well as its current animation, angle, direction, scale, whatever, while Object #2, the latter one being collided in the condition, will use whatever it was at the start of the event editor that frame- mmf2 only updates the collision map at the end of each frame. So you can use hitboxes by setting object #1 to a special animation, but you can't do the same with #2, whatever displayed animation/angle/scale/etc is the same as the collision map.



Now the key to understanding this is to understand what scoping means, MMF2 starts each event condition with all objects of all types scoped at the top of the event, and as it proceeds down the event's conditions, it eliminates all the ones for which the conditions are untrue, and cancels the event if any condition returns all falses (9 falses and 1 true means it keeps executing). So to specifically answer those questions:

1) Yes, collision events can be placed in any place, it will just impact which objects are scoped and checked for collisions. If you do a line like:

*X of Object #1 > 500
*Object #1 is overlapping Object #2
*Do something

Then at the start, all object #1's are scoped. After the first condition, only object #1's with X > 500 remain scoped. After the second condition, only object #1's of X >500 that are colliding object #2's are scoped, and the events applied to them only if a collision was found and at least one was past X of 500. Meanwhile, only object #2's which collided with those #1s would be scoped. This can be important as a distinction.

In terms of applying events to #1's, it wouldn't matter if you had those lines inverted, either way it would only count the ones that were both past X>500 and colliding with #2's. Order doesn't matter for them. But it matters for #2s: Any actions applied to #2 in this event would count only for the ones that are colliding with the #1's past 500. If you put the collision first, any #2 colliding with any #1 anywhere would be scoped. I hope thats not as hard to follow for you as it is for me, I lost myself

#2) The collision code will be called for all the #1 objects that are scoped, this can be 100, 5, 2, 1 or 0. Naturally if no objects were scoped (for example, none existed or you descoped them all in an above event somehow) then that line would return a false and end the event with no actions taken. So it will work wherever you put it in the conditions, just remember the scope list starts with all objects, and culls through events, and finally applies only to the ones remaining on the list.

There is a glitch here by the way, catches a lot of people. An event that reads "#1 is not overlapping #2", using the negated form of the detection, will actually fail the test and return false if no objects of that type exist. Logically this doesn't make sense, say if there are no "Bullets" and no "Bad Guys" in the frame, you'd expect a line that says "Bullets aren't overlapping Bad Guys" to be "true" and the event to continue, but because its iterated over every object and tries to check its collision, it follows that flawed logic and returns "false", no actions being taken. I'm not 100% sure if that would apply only if #1's don't exist or #2's don't exist or both don't exist, its one or more of those three, I've never really tested it.


3) You can indeed call a specific object by this condition, you just need a way of specifying the object you want. For example, if you had a line like:

Value A("Object #1") = 27
Object #1 is overlapping Object #2

Then it would only check for the Object #1 with Value A = 27. Now just make sure only one object has Value A = 27. If multiple had A = 27, it would check for each of them.


Oh and the reason it can cause so much slowdown is because of how expensive it is to check for collisions, particularly with fine detection on, and how many checks must be made. If you have 500 of object #1, and 500 of object #2, and each one is 32x32, then it can compare up to 500x500x32x32 pixels against each other; it iterates through each #1, compares it to each #2, so on. However MMF2 uses optimizations to not be ridiculous about it, it will only check per pixel if objects are in overlapping X/Y bounds, it first checks if the Right X of #1 is less than the Left X of #2 or whatever, and objects without fine detection don't go any further than that, and you can speed up background collisions by turning off the "handle background collisions even out of window", since MMF2 would elsewise have to compare to the entire frame's background instead of just the much smaller window, in a scrolling level.


I wrote a cruddy article on it once, if this wall of text wasn't enough;
http://www.create-games.com/article.asp?id=1942

Good luck!

[OldSchool80s]

Thanks for this, and a reference to the other article.

[netninja]

Thanks for the great post Pixelthief. I've noticed that many lines of collision checking code were causing slow down in my game (on slow computers). I'm still not 100% sure how to optimize it all, since I need collisions checked out of the frame, and there's lot of objects, but I'm interested to see how this thread develops with new ideas.

[Danny]

Just to backup what PixelThief said, for Android/Flash/HTML5/iOS optimisation is key and with conditions that only affect a particular object that might not be on-screen all of the time then you can always do:

Number of ("Active")>0
+Another Condition ("Active")
+Another Condition ("Active")
+Another Condition ("Active")

By having Number of ("Active")>0 greater than 0, if that particular object isn't available then it will stop rendering all the other conditions below it saving a hell of alot of scoping and parsing on MMF's end.

Whilst we're on topic for framerates, don't forget majority of the exporters are hardware accelerated so always good to try and create your original images to the power of 2 (ie: 8x8,16x16) or any variation (ie: 512x256). If something can be scaled UP then create the smallest possible version and scale up using the Scale > Action in the event editor.

I wish I had time to put together everything I had to do for IGX and hopefully this year I can put together something that will assist others in future development. Alot of areas have already been covered on this forum already but I'll gladly put something together trying to outline specifically what I did to achieve maximum performance for the IGX engine.

[OldSchool80s]

@Danny, I look forward to your outline. It'll have tons of goodies.

[Pixelthief]

Well always try to save collision detection cycles by descoping any objects that you don't *need* to look at.
For example, give all the bad guys in your game a flag which is set ON if they are within say 200 pixels of the frame window, and OFF if they are too far away, or else use the "inactivate if too far from window". Then on not just collision detection, but many other events, you can restrict it to checking just objects with that flag on.

[Simflare]

I just figured out something awesome if anyone is trying to scale up pixel art - when you scale up pixel art, if you choose '1' for maximum quality, it will be blurry because it tries to smooth it, but if you choose '0' for speed and less quality, it doesn't auto-smooth it and keeps the sharp pixel look. 0 for quality is perfect for pixel art, it just scaled perfectly on my game.

Is there an easy way to work out if an image is to the power of 2? I made have to re-size some images for my game.