8-Direction Sliding on Wall : Bug on corners

[OverboyDev]

Problem description

With the new Sliding feature of the 8-Direction behavior, there are issues on corners : The Object blinks/teleports/is stucked when sliding along certain corners. Especially when the corner is at the bottom or the right of the 8-Dir Object. (but sometimes also for left and top corners depending on the angle of motion ? or depending of the "shape of the corner")

Attach a .c3p

8Direction_Bug.zip

Steps to reproduce

1. Try to slide along the corners of the blockout level, especially corners on bottom or on right of the Sliding Object. (but issue can happen on all of them)
2. On half of them, especially the Right and Bottom corners, the movement is really janky. (the issue doesn't seem to happen less often for "top corner" and "right corner", maybe it depends on angle of motion or the "shape of the corner")

Observed result

On Left and Bottom corners especiallt, the 8-direction movement is clanky/noisy/laggy. It blinks/teleports/moves very fast with a noise.

Expected result

Should slide smoothly or stop depending on current user inputs/angle of motion in corners.

More details

It's maybe due to the order of operations ? it looks like it works fine most of the time going up and left and breaks most of the time going down and right so I'm guessing that one is being processed after the others which causes these issues

Affected browsers/platforms: all platforms and browsers

First affected release: r298

System details

View details

PASTE HERE

[AshleyScirra]

I'm not sure what problem you are referring to. It's difficult to deal with bug reports if we don't have clear steps to reproduce the problem - I can't match your exact inputs. It's much easier to deal with reports if you demonstrate an issue without using user input, so it works automatically, e.g. with "simulate control".

I think you might be referring to how in certain positions the object ends up "juddering", moving between two different positions very fast. However I think the main reason for that may be the tiny size of the project. The viewport is only 200x200, and if you resize everything to 400x400, it seems to work better. There are lots of difficult corner cases in handling collisions, and in some cases it may do something like "try back up 5px and see if there's a space"; in a tiny world that 5px will be a much larger distance and so it risks doing something like teleporting. I'm not sure that it would be feasible to do anything about that, given the complexity of handling all the possible cases, there has to be some degree of tolerance built in.

[Wackytoaster]

I'm not sure that it would be feasible to do anything about that, given the complexity of handling all the possible cases, there has to be some degree of tolerance built in. Would it be possible/make sense to give users access to said tolerance in the properties? That sounds like something that would allow some project specific fine-tuning. (Actually it would be cool to get some lower-level access to many of the plugins, at our own "risk". Some kind of advanced mode, specifically for stuff like this. What if my game would work better with 3px of tolerance instead of the hardcoded 5px? Stuff like that, right now we're at the mercy of the plugin as to how it handles such things.)

[OverboyDev]

@Wackytoaster Mmmh this might be a different issue but this is not the kind of corners i'm talking about.

Try to slide towards those Corner specifically in my examples

@AshleyScirra try to slide towards those corner with the red circles in my example. (it especially happens if you really try to move toward them, by pressing 2 arrow keys at the same time (like Top + Right or Bottom + Left) for example) The "juddering" can happen in the other corners too, but I think those one are the most obvious.

It would be important to support this kind of resolution for games (200x200px), as it's the kind of resolution i'm using in all the games i've ever made with Construct (as they are in pixel art)

[Wackytoaster]

Oops, that does indeed seem like a bit of a different issue. I'll file a new report then. My brain just kinda glossed over everything other than "stuck" and "corners".

I can very easily reproduce said stuttering without much trying. Maybe it's easier on higher refresh rates? I'm on 144hz right now. I remember there was an issue with the platform behavior that also only got really apparent at higher refresh rates. The issue does seem to disappear at higher resolutions. It's not the first time I've seen something like that, where low resolutions caused the problem which is unfortunate for anyone that wants to make pixelart games. Maybe the tolerances shouldn't be set to a hardcoded value but rather depend on the size of the viewport?

I've also seen people talk about cheating a little on the whole pixel thing and just upscale the art. So in your case you could try to make the viewport 400x400 (check if that solves the issue), you upscale all your art assets 2x. You'll retain the overall look but the engine will run at the higher resolution. You will lose pixel-rounding though, or rather it would visually round it to half pixels. (I think I've seen this mentioned on the forums as a way to get smooth, non-pixelrounded camera movement in a pixel game.)

[OverboyDev]

I'm not on 144hz, so I think it happens for everyone.

(tbh I prefer to change game engine rather than upscaling all my art everytime x2 in addition to all the other work-arounds I have to do for a lot of things everytime)

[AshleyScirra]

I've made some improvements to the collision handling algorithm for the next beta. It looks like it helps a lot for this case and another one filed in #5781. It's very difficult to get right - this all reminds me of the Platform behavior algorithm, which years later is still being tweaked for various edge cases. Hopefully we won't need to make many more changes after this...