Fastloop overlap problem that has been driving me insane

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    Ohhh I see the 1 frame delay on post-correction!
    This is very annoying!
    (I thought I could have spotted that while testing but didn't slow down the process to actually verify)

    A pre-correction then?? XD
    Please login to see this attachment.

    Could only work for "box collisions" though...

    a selection of my Fusion examples can be found Please login to see this link.

    That's a really awesome work-around Schrodinger, but unfortunately I need fine detection on these :(

    The idea was to have entire objects such as ships or wheel platforms like in Mega Man X that you can be pushed by or ride on. Sometimes an entire set of rooms that are moving (imagine the room you're in actually raising up and moving somewhere else!) etc. Normally I would be much less picky, but the whole project has been on-going for the past few months, and this isn't even the first time I've attempted something similar to this, so it's kind of like a vendetta!

    I'm already much researched about the formula to shift objects by their delta and such, and all of that works fine: it's just this overlap problem throwing a wrench in it all and causing jump-thru platforms to miss, as well as the frame-late thing making the shifting noticeable. The platforms would also have slopes; you can probably imagine how they would be affected by it too.

    I think what could fix all of this is allowing us to manually call things like when collision detection happens in the program itself. Judging by Clickteam's behavior lately, it likely won't happen until Fusion 3, though. And that's if they don't shoot it down for some reason, anyways (Like my manual event editor position idea that I still want XD).

    Again: I appreciate all the help. I'm giving this up until I get any feedback from the bug box. I really hope Clickteam doesn't shrug it off. Am I the only one who thinks things should work the way I explained? :O

    Best person at writing incomprehensible posts. Edits are a regularity.

    Edited 2 times, last by casleziro (September 22, 2015 at 12:00 AM).

    I agree with you.
    There's something that would need to be clarified (and maybe fixed?) in how collision detection works.
    We all should benefit much from this information.
    This is a key-mechanic in a 2D engine, for aiming at a professional result.

    This, or a set of builtin movements with pixel perfect fine collisions at any speed.

    (I was also thinking that pre-correction could achieve fine collision with some extra data on the item stored somewhere,
    and a very long time frame to properly setup,
    but this would be overkill, and worse still, why reinventing the wheel if Fusion is aptly created to ease this kind of things? :))

    -also, a curiosity-
    have you tried if move safely object extension does a better job in this scenario?

    a selection of my Fusion examples can be found Please login to see this link.

    For moving platforms? No. The way I got around it was described in the "Broad phase collision" thread.

    Moving object hitboxes seem to update independently of each other, so I resorted to:

    -move player
    -record platform xy in value
    -move platform
    -correct player position by snapping him to platform edge depending on platform old position and player current position

    Basically, you check if the player is in line with the platform, and check if the platform passed over the player after it moves. This works fairly well but is annoying as a workaround. I thought you were talking about static collisions in that new thread of yours

    Best person at writing incomprehensible posts. Edits are a regularity.

    I did this too and it works for a minute. Up until randomly your prior position which you thought was good was actually bad due to the lag in overlap detection. So I run into the problem where my prior XY position is inside a moving platform. At that point I can't resolve out of the platform and am stuck.

    How do you ensure your prior X and Y Position are safe to store as a good XY position that is not overlapping a moving platform?

    since the player moves first, i check for collisions against the platform directly in his movement. Once you move the platform the collisions will desync because 2 objects have moved, so i use values to determine if the platform crossed the player. unless youre doing something much differently than me, that order should work. The first object to move should have accurate detection.

    Best person at writing incomprehensible posts. Edits are a regularity.

    here, sorry about the wait.

    Please login to see this attachment.

    I had fixed this problem while on vacation and completely forgotten about the thread XD

    At least now the solution has been posted if anyone has the same problem! Still something I think Clickteam should look at. Maybe an event to update detection? I doubt they would add it to 2.5 though...

    Best person at writing incomprehensible posts. Edits are a regularity.

    By the sound of it seems this thread has been solved.

    Regardless, this is how collisions work in Fusion ( ObjA collides/ overlaps with ObjB ):

    Collisions are handled between 'collision masks' ( this happens behind the curtains and you have no controll over this ).

    When ObjA overlaps/ collides with ObjB, ObjA collision mask is up to date, while ObjB collision mask lags by 1 Game Frame ( meaning ObjB collision mask remains for the sake of the specific collision, at the coordinates of the 'previous' Game Frame.
    So if ObjB is static, no problem.

    It is easy to make an example demonstrating this ( if not fixed ).
    This is why moving platforms are tough to handle and not too Accurate ( if using the collision/ overlap function ).

    How can i change username and display name?
    Please login to see this link.

    Hi King Cool,

    I made a manual AABB check where I see based on coordinates if my player overlaps. They both use floats. Problem is that sometimes it registers a collision when it should because of floating point rounding errors. How does everyone compensate for these rounding errors?

    Thanks King_Cool! I will try to add the rounding function to my event as all my calculations are done in an array.

    Update: It worked like a charm! :)

    Also something that I found which could be useful to others: Please login to see this link.

    Nice!

    I have attached an example demonstrating the overlap lag in action, as i feel its importaint to uderstand how things works, and also in case people are still not convinced this is the way it works.
    Its not a common problem for general Object interactions, but when you need that pixel perfect fine tuning this lag will become apparent.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login