Printable View
does count of collision check matter for perfomance? I mean, if i making a platformer and collision checks goes through backdrops. I'm a bit worried, because scene contains floor, walls, and even roof, background images - all of them are backdrops wich are converted by active - add backdrop as obstacle. Logically engine must check all backdrops with player position.
Yes, it matters a lot! That’s why you should uncheck fine detection/use quadratic shapes as often as possible and reduce colliding objects/backdrops to a minimum amount. Most games layer a complex tile set over a very simple collision mask to save resources. Also, object scoping and collision scheduling are very important to reduce checks wherever possible. That’s why you would always put an overlap check on the bottom of an event block. Especially AIs often don’t need overlap checks every frame tick, most enemies in my current project run their checks at 30 FPS which reduced the load a lot, sometimes even 10FPS is still sufficient. And keep one quirky thing of Fusion in mind: Collisons will always be checked and cannot be avoided by scoping or group deactivation (yes collisons are even checked in deactivated groups!). Overlap checks don’t show this behavior tho, that’s why I use them in any case where I employ the techniques mentioned.
https://community.clickteam.com/threads/101380-The-Clickteam-Fusion-2-5-optimisation-amp-performance-Hard-Data-thread/page6?highlight=Hard+data
This thread will be interesting for you, linked the part about collisions.
damn, i knew it! thanks a lot :)
Of course you can also use rectangles, I got that wording wrong. Slopes will always need fine detection tho and therefore are a lot more expensive, if your gameplay doesn’t need them skipping those at all might be a good step.
one more question. How you do custom collision checker? My ideas is:Quote:
Originally Posted by Julian82
1. Using 1 pixel wide and tall active object. Just by looping through you objects you can re-position collision checker relative to target position and scale him. Something like:
on group activation - run eachloop "cr_cChecker"
on eachloop "cr_cChecker" - create ("Active")set x position to x left of target x (optionally x offset)* only problem is here - you can use only rectangle form.
set y position to y top of target y (optionally y offset)
set scale x - owidth of target object
set scale y - oheight of target object
2. or one active object wich contains all possible collision shapes in frames.
* And here question: wich way is better for perfomance, active object with single frame or with multiple frames?
I think using one collider in general an shaping it for each instance you loop through is a pretty smart and practical approach if planned carefully. Scaling will probably be a bit more expensive than frame shifting, but that’s minor and just a guess. Be careful with non rectangular shapes tho, I would use an extra collider that holds all shapes that need fine detection enabled to work properly, otherwise all rectangles are fine detected too and produce unnecessary load.
There is another method next to instance looping called “embedded colliders”, which I prefer in most cases as you get rid of the need of to use instances and for each loops this way, I’ve linked the tutorials here. https://community.clickteam.com/threads/102646-Can-not-make-quot-headshot-quot-function
i saw this before, i'm a bit worried because this method uses always and rapidly swithes between animation sequences before engine even draw animation. This sounds like abusing/overriding. Anyway, i'll try.Quote:
Originally Posted by Julian82
It’s very performance friendly in my experience, just a bit weird to start with.
It is working fine for me and with a lot of objects having gravity and a bunch of loops for attacks and movements. Also enemies in my game are like this one with HD graphics and no slow downs so farQuote:
Originally Posted by alexexhowl
https://media.giphy.com/media/l0NgRq...dlq8/giphy.gif
This is one of the bosses from my upcoming game
@coler123 : Wow, a real beauty! Hope to see more of this in these forums soon! What kind of game is this? If it's something like Odin's Sphere (reminds me of it) I'm totally sold!
Hey thank you! our game is actually more story driven, less arcade, a bunch of loot like weapons and magic but less combos (you can combo stuff tho!) we will be posting as soon as we have a working built that we can show around or a demo for people to try.Quote:
Originally Posted by Julian82
Sorry for getting out of topic.
What exactly is not working? Do you have an example .mfa? The method is not limited to backgrounds, I use it with actives too.
here: Attachment 24598Quote:
Originally Posted by Julian82
@alexexhowl : Had a look at your .mfa and modified it a bit. The object using embedded collision detection has to be checked first in an overlap condition, otherwise the so called "overlap delay bug" occures and the changed collision shape is not recognized properly. Fusion's overlap delay bug is a very quircky thing that can cause trouble in different situations, I did not even know it affects animation and frame shifts too XDQuote:
Originally Posted by alexexhowl
What it basically means is that if you change two objects within a frame loop (position, animation, scale, whatever) and then test for overlap only the changed state of the first object in the overlap check will be recognized properly while the state-update of the second object is delayed until next frame loop. This was the reason why your example did not work, as you had tested the object with the embedded collider second.
Here is the adjusted .mfa, I made the embedded shape very small to illustrate the effect a bit more prominent. https://www.dropbox.com/s/lnksq80iuz...debug.mfa?dl=0
Your .mfa made one important thing clear to me: You cannot test two objects that both use embedded colliders against each other, at least not if they're visible and shift their shapes within one frame loop. My player runs with classic attached colliders while all my enemies run on embedded detection, that's why this issue never occured to me.
Oh look at that you don't even have to check for animations, I used to check if the animation was playing to check for collision.
Attachment 24600