Custom collision polygon ignored

0 favourites
  • 7 posts
From the Asset Store
Supports keyboard, mouse and gamepads. Supports several gamepads at once.
  • Link to .capx file (required!):

    sdrv.ms/1aRSf6f

    Steps to reproduce:

    1. Create a player sprite (50 w, 25 h) with a custom collision polygon such that the nose of the player sprite falls inside the sprite's bounding box. Assign the behavior "8Direction" to the sprite.

    2. Create a wall sprite (9 w, 147 h). Assign the behavior "Solid" to it.

    3. Create another instance of the wall sprite. Set its Angle to 90.

    Observed result:

    The collision is correct when the player sprite collides with the non-rotated (Angle=0) wall sprite (i.e. the player sprite stops when its nose hits the wall sprite).

    When the player sprite collides with the rotated (Angle=90) wall sprite, the player sprite stops when its bounding box hits the wall sprite and not when its nose hits the wall sprite.

    Expected results:

    1. Collisions with sprites work uniformly regardless of Angle.

    2. Collisions use the collision polygon instead of the bounding box.

    Browsers affected:

    Chrome: Not tested

    Firefox: yes (v 22)

    Internet Explorer: yes (v 10)

    Operating system & service pack:

    Windows 8 Pro 64-bit

    Construct 2 version:

    Release 132 64-bit

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Can't reproduce, collisions still look like they work properly with rotated sprites. I think you're just confused by the way the 8-direction behavior is handling collisions with these sprites. Construct 2 is used for hundreds of games, and if rotated collisions didn't work, I'm sure we'd have heard about it long ago.

  • Ashley,

    Thank you for taking a look at my report so promptly, however, your Jedi mind tricks won't work on me. I'm not confused about 8-dir behavior and just because someone hasn't found a particular bug doesn't mean it's not there.

    In fact, I find your lack of faith disturbing. Seeing is believing so I made a video demonstrating what I am observing. I uploaded the video to Skydrive in the same location as the .capx file. Here's that link again for your convenience.

    Examples uploaded to Skydrive

    Right-click on the video to download it or left-click to play it in your browser.

    Thanks!

    Paul

    p.s. In case it's not clear, the tone of this reply is intended to be humorous.

  • Radish it works as expected in r137. Have you tried the beta?

  • Radish - I cannot reproduce any issue. The collision mask is clearly not ignored in the place you describe. The 8-direction behavior does treat collisions slightly different for the two surfaces, but that's just due to the solid detection algorithms it uses, and doesn't mean collision masks aren't working.

  • thehen, I will try the beta. Thank you for the suggestion.

    Ashley, did you watch the video I uploaded?

    Paul

  • thehen, the issue is fixed in the latest beta (r137). Thanks again for your suggestion.

    Ashley, fyi I was able to reproduce the problem on several computers. I also exported the project as an HTML 5 website and opened that on different computers as well and still had the problem. As noted above I do not see the issue with r137 beta, i.e. the pointy end of my collision poly now goes right up to the sprites (which is the desired and expected behavior).

    Paul

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)