Platform/Solid collisions not triggering for specific y pos.

Report Construct 2 bugs here.

Post » Fri Oct 16, 2015 10:10 am

@Ashley : my apologies ! I recently cleared some old links I submitted in the past for other bugs/demos and it seems I mixed a few things :/

Correct .capx for this bug : https://dl.dropboxusercontent.com/u/526 ... onBug.capx

You'll be delighted to see it only has 6 events :D Thanks for finding the time to look into this !
Last edited by Refeuh on Mon Dec 28, 2015 6:38 pm, edited 1 time in total.
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 240
Reputation: 2,238

Post » Fri Nov 13, 2015 2:31 am

@Refeuh - Hello,

@Colludium nailed it, The platform behavior is solving the collision as best as it can before you get to even test overlaps. Its not a bug at all and it actually is consistent in what it is doing and why.

When a collision is resolved in construct 2, there is a certain level of error due to floating point calculations and the type of resolution being performed. If it were guaranteed that collision objects were on a grid pattern and were square, you could calculate resolution perfectly... but as it is there can be up to a 10th of a pixel of error. You can google floating point math errors, and polygon collision detection to get an idea whats going on here.

On the second badguy, the collision resolution phases of the platformer behavior pushes the player completely out of collisions and then some. It all has to do with how far the object intersected the solid and the type of "push out" that was performed.

I have had to deal with this a ton in my game, but it isn't a problem that is game ending. You can simply create another animation (OverlapTest) and a frame for your player object that has a collision polygon that is 1 pixel larger than your polygon normally used by the platform behavior. On the rendering side of things, Your player object should be slightly larger than your collision object. This way you get the whole narrow escape but no unfair hits aspect to your game. Let me know if you have any questions regarding this.

@Ashley - I believe this is all correct and similar to something you told me several years ago, please correct me if I am wrong.
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,173

Post » Fri Nov 13, 2015 10:42 am

The "solid" behaviour needs the collision information to resolve object overlaps anyway ; that's how all discrete or continuous collision detection systems work. Preventing object overlap should still register a collision, otherwise it makes the behaviour useless to write actual gameplay logic.

Floating point math errors are a known problem, and while actually solving collisions can always be difficult and lead to degenerate cases, registering collisions should be consistent.

I still believe the specific y positions hint at a physics cell boundary issue.
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 240
Reputation: 2,238

Post » Mon Dec 28, 2015 6:39 pm

Bump -

Not that I really care for a fix, but I'm wondering if anyone had a chance to confirm what's actually going wrong with this :-?
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 240
Reputation: 2,238

Post » Mon Dec 28, 2015 11:01 pm

It looks like it's got to do with the collision cells.
https://www.scirra.com/blog/ashley/6/collision-cell-optimisation-in-r155 wrote:The layout is effectively split in to cells the size of the window.....
...Now when checking for collisions with an object, it only needs to check all the other objects in its cell


Your window height is 104 so each collision cell is 104 pixels high. The problem in the capx occurs at y = 520, a multiple of 104. You can see the same problem when the collision happens at 104, 208, 312, etc. It looks like the two sprites are in different collision cells and so no collision is registered.
B
55
S
29
G
19
Posts: 1,520
Reputation: 25,680

Post » Wed Dec 30, 2015 12:59 am

Ah great, my thought exactly ! This blog post I hadn't seen seems to confirm my previous hunch :) Thanks for the contribution.
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 240
Reputation: 2,238

Previous

Return to Bugs

Who is online

Users browsing this forum: No registered users and 2 guests