Strange platform behavior

Hello!

I'm currently working on a jump'n'run game and experiencing some strange behaviors. The game is tested by approx 5 regular testers including desktops and mobiles. Some testers reporting some things like:

• Hero jumps into the spikes at the ceiling. But he shouldn't reach them! There is barely space between the jump high of the player and the spikes, maybe just 1 pixel. But on most devices he doesn't reach them (or only in rare cases). But on this one device regulary. This rises the question: how can it be that the jump high is different? Or are there perhaps differences with floats in the collision polygons?

• it is a one button game. with the button you jump. the hero runs automatically. if he touches a wall he changes direction. Sometimes it happens that if he lands on the edge of a block, but clearly ON the block not against the side, he changes his direction - and runs off the block. 2 pics to make that clearer (I hope):

If I don't miss something here he shouldn't change the direction. Next thing is: this happens rare on desktops, but often on mobiles. As if the performance play a role here. Is this possible!?

Post a capx so we can test and help.

Could be those other testers are experiencing lower fps.

Do you know if the one pixel offset is before or after scaling? Also, maybe I'm not familiar with those events, but if the condition is "not overlapping offset at (0, -1)" would the condition be true if it was overlapping at offset (0, -2) or greater?

Platform behavior has a "is by wall" condition—is there a reason that won't work here?

- Hero jumps into the spikes at the ceiling. But he shouldn't reach them! There is barely space between the jump high of the player and the spikes, maybe just 1 pixel. But on most devices he doesn't reach them (or only in rare cases). But on this one device regulary. This rises the question: how can it be that the jump high is different? Or are there perhaps differences with floats in the collision polygons?

The jump height can vary depending on device/browser and dt/fps, by much more than the 1px you're allowing. See this old bug report.

I'd suggest increasing the tolerance to at least 8px, and increasing it if the problem persists.

I think you misunderstand the 'is overlapping at offset'. You seem to think about it as 'is overlapping at a point'. In reality, the engine moves the Sprite to the given offset, checks if the Sprite overlaps (the whole Sprite with its collision polygones), and then moves it back.

—:

I don't exactly get what you mean with "before or after scaling". The window? I guess it happens in all sizes, but I will test that. I can't rely on the implemented "is by wall" function because it has other (worse) side effects. So I looked into the code and modified it a bit. So my conditions are mostly the same I already tested the (0,-2) variation too but it doesn't make a difference.

OddConfection:

Thank you for clarification! I suspected something like that and it's good to be sure. In my opinion thats a big down for Construct. I have to rely on repeatable behaviour in a hard and exact gameplay. The game behaviour must not be affected of the fps, thats an unbreakable rule in my opinion. Now I have to find a way out :/

99Instances2Go:

No, I understand it this is (as said) copied and modified from the "is by wall" function and should work the way I want it to. Thank you nevertheless!

Sorry, my comment didn't really make sense—my mind was wrapped up in something else. Though I'm curious to know what the 'is by wall' issues are...

I understand how the offset works now—are the collision polygons, for both player and solid tiles, rectangular?

If not, there could be a frame where the lower point of the player collision polygon clips the tile when moved to the right (and up) even though majority is still above the tile.

Also, is the image the exact spot this happens? and will the player change directions mid-air? I was thinking if maybe on the jump they clip the corner of a 'new' ceiling, as in there is not ceiling above them but above and to the right there is, it could cause the change in direction. But unless it is programmed to not change directions until on the ground you would notice right away.

...those probably aren't the issues, but just trying to think out of the box as I don't see any issues in what you posted.

It's been a while but I think it were things like:

• turning on slopes
• turning on "tunnels" with too near ceilings (or turning NOT in tunnels with too near ceilings but ending on wall)

All the collision polygons are rectangles. Increasing the overlap (0, -2...+) helps at (0, -4) but then I run into the problems of the original isByWall function.

Yes, this is one of the exact spots where that happens. The player has already landed on the corner of the platform. So it IS in fact ON the platform. There is no wall here. But he turns around sometimes (and more often on mobiles with lower performance).

The only reason I can imagine at the moment for this behaviour is:

My wall condition sometimes happen while the player is IN the platform (just before the platform behaviour moves him out). But this shouldn't happen! On the other side the varying jump highs SHOULDN'T happen either....

I think I may have a far better solution, I'll just have to test it intensive:

If the hero's vertical speed equals to null, change direction. Simple but effective! Because if the hero stopps, he has to be by a wall.

On the other side the varying jump highs SHOULDN'T happen either....

This is true. And yet i am a bit surprised. I tested this the other day, with the last stable release, and i could not find a substantially frame dependence no more.

I did this while i was working on this:

Aphrodite, accuracy is pretty perfect. It seems to me that jumping is now frame independend. (latest stable release)

https://www.dropbox.com/s/i3h3w3lpw1idw ... .capx?dl=0

On the other hand, there is few pixels difference between what i could predict and what i actuary could measure. I (for myself) concluded that is impossible to accurately get the jump height in event, with triggers. As you can see (i hope) the predicted values are way more accurate. Does this help you ?

For the 'on wall'. That is so depending on the collision mask, mirroring and more things, animations ... etc. Really cant help without the capx. Also, and yes, when you jump of a solid platform, and you come close to that perform, there is a wall detected.