Specific, reproducible bug for Direct3D 9 collision detection

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.
  • I'm running R256.34 and I'm attaching a .mfa file illustrating the issue. Please login to see this attachment.

    I'm attempting to construct a sort of line-of-sight algorithm using a detector object. The detector is a single pixel. In a fast loop, the X scale of the pixel is set to the distance from the seeing object to the target (mouse, or player object.) Its angle is set to the angle from the seeing object to the target. Then it tests for overlaps with walls. If the detector object overlaps a wall, then the player should be safe from being seen.

    There is slightly more to it: the walls all have their animation directions changed to a "footprint" mode and then changed back after the line-of-sight calculation. It's easy enough for me to see if the detector overlaps any part of any wall, but I need to detect overlap with the walls' footprints specifically.

    Now, in the attached .mfa file, the collision detection behaves exactly as it should if you just load it up and run. However, if you change the display mode to Direct 3D 9, you will see that it breaks the behavior. Also note that while in Direct 3D 9 mode, if you position the seeing object and the mouse just right so that the mouse has the same y coordinate as the object and is to the right of the object, it *will* detect collisions with the walls.


    Anyway it would be nice if this technique still worked in Direct3D 9. It would mean the difference of 10-20 FPS for me in normal gameplay, and that's not an exaggeration.

  • It sounds like just the usual thing with how MMF2 handles collision detection...
    It basically saves the position, animation frame, angle, etc of all the objects at the start of the frame. Then when you test for a collision, it uses the current state of the object you specify (which is why embedded collision detectors work), but compares that against the saved state of other objects as they were at the start of the frame (which is why collisions between two embedded collision detectors don't work). In your case, you can either rotate & resize the detector OR you can switch to the footprint mode and back - but you can't do both.
    It's all explained more thoroughly in other threads.

  • It sounds like just the usual thing with how MMF2 handles collision detection...
    It basically saves the position, animation frame, angle, etc of all the objects at the start of the frame. Then when you test for a collision, it uses the current state of the object you specify (which is why embedded collision detectors work), but compares that against the saved state of other objects as they were at the start of the frame (which is why collisions between two embedded collision detectors don't work). In your case, you can either rotate & resize the detector OR you can switch to the footprint mode and back - but you can't do both.
    It's all explained more thoroughly in other threads.

    But what I'm doing works perfectly fine in standard display mode, it just breaks in Direct3D 9. You can test it yourself.

  • I gave it a shot - It seems like the line is checking if it's overlapping with the walls being in the right direction (the graphics) rather than the left direction (the collision mask of sorts) - Since that's the last picture/frame it has to work with. IE: In software mode, active's animations can be changed dynamically and be immediately updated for events; instead as in Direct 9 mode where active's animations only update at the end of the frame.

    Work-around-time! :D

    ... I suggest this:
    Please login to see this attachment.

    It pastes/adds backdrops (as obstacles) in the first two frames with the collision images (at each active), and then checks for obstacle overlapping instead.
    You could then delete a backdrop at a certain X and Y position if you wish*. (I very much believe so at least, there's an action for that - but I've never used it.)

    (*which you do, "breaking-wall-behavior dude")


  • It pastes/adds backdrops (as obstacles) in the first two frames with the collision images (at each active), and then checks for obstacle overlapping instead.
    You could then delete a backdrop at a certain X and Y position if you wish*. (I very much believe so at least, there's an action for that - but I've never used it.)
    (*which you do, "breaking-wall-behavior dude")

    Thanks so much! This technique should work fine in my larger game since I don't use the backdrop on this layer for anything. You are the hero of the day!

Participate now!

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