Jumpthru issues

[RichardAstrom]

Hello! I'm having some issues with the jumpthru behaviour. I often get snapped to the top of an platform with jumpthru enabled even though the character I'm controlling is quite a bit below it, and even though I'm using very thin platforms.

jumpthru.zip

1. Jump around near the platforms. Run from the left platform to the right and watch as you get snapped up on the platform next to it.

Observed result

You get snapped to the platform even though your the bottom of the player sprite is below the jumpthru platform.

Expected result

The player should fall down to the ground below passing through the jumpthru platform?

More details

Chrome

r185

System details

View details

Platform information
Browser: Chrome
Browser version: 79.0.3945.130
Browser engine: Chromium
Browser architecture: 64-bit
Context: webapp
Operating system: Windows
Operating system version: 10
Operating system architecture: 64-bit
Device type: desktop
Device pixel ratio: 1
Logical CPU cores: 4
Approx. device memory: 8 GB
User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36
C3 release: r185 (beta)
Language setting: en-US

Local storage
Storage quota (approx): 14 gb
Storage usage (approx): 368 mb (2.5%)
Persistant storage: No

Browser support notes
This list contains missing features that are not required, but could improve performance or user experience if supported.

Nothing is missing. Everything is OK!
WebGL information
Version string: WebGL 2.0 (OpenGL ES 3.0 Chromium)
Numeric version: 2
Supports NPOT textures: yes
Supports GPU profiling: yes
Supports highp precision: yes
Vendor: Google Inc.
Renderer: ANGLE (AMD Radeon HD 7800 Series Direct3D11 vs_5_0 ps_5_0)
Major performance caveat: no
Maximum texture size: 16384
Point size range: 1 to 1024
Extensions:

EXT_color_buffer_float
EXT_disjoint_timer_query_webgl2
EXT_float_blend
EXT_texture_filter_anisotropic
KHR_parallel_shader_compile
OES_texture_float_linear
WEBGL_compressed_texture_s3tc
WEBGL_compressed_texture_s3tc_srgb
WEBGL_debug_renderer_info
WEBGL_debug_shaders
WEBGL_lose_context
OVR_multiview2
Audio information
System sample rate: 48000 Hz
Output channels: 2
Output interpretation: speakers
Supported decode formats:

Ogg Opus (audio/ogg; codecs=opus)
WebM Opus (audio/webm; codecs=opus)
Ogg Vorbis (audio/ogg; codecs=vorbis)
WebM Vorbis (audio/webm; codecs=vorbis)
MPEG-4 AAC (audio/mp4; codecs=mp4a.40.5)
MP3 (audio/mpeg)
FLAC (audio/flac)
PCM WAV (audio/wav; codecs=1)
Supported encode formats:

WebM Opus (audio/webm; codecs=opus)
Video information
Supported decode formats:

WebM VP9 (video/webm; codecs=vp9)
WebM VP8 (video/webm; codecs=vp8)
Ogg Theora (video/ogg; codecs=theora)
H.264 (video/mp4; codecs=avc1.42E01E)
Supported encode formats:

WebM VP9 (video/webm; codecs=vp9)
WebM VP8 (video/webm; codecs=vp8)

[AshleyScirra]

IIRC (much of the platform code is years old), the Platform behavior has a number of cases where it applies a few pixels "fudge factor" to correct itself on to platforms. I think this was in response to a series of other bug reports along the lines of "my player misses this jump by 0.1 pixels, it should figure out what to do and land on the platform anyway". Also, past experience of changes to the Platform behavior is we end up playing whack-a-mole with bugs, with even tiny changes causing regressions in other games, which depend on every possible subtlety imaginable in the behavior.

How serious a problem is this for you? We can try and make a change and run down the rabbit hole of dealing with all the follow-up issues that will probably come up, but having done this in the past it will be a lengthy and error-prone process. It looks like you can probably work around it with level-design type adjustments. Also given in many cases the platform behavior treats small steps as slopes it can smoothly move along, it seems like arguably what it's doing is reasonable.

[RichardAstrom]

Ok, I understand! I wont be able to work around it by design because even though I could place the platforms further apart, the snapping (when you are falling too close to the edge of the followthru object) just breaks the platform controls and feels more like a bug I'm afraid.

Thanks!

[AshleyScirra]

What I mean is if you space the platforms out a bit more the issue no longer reproduces, as shown here:
jumpthru-spaced.zip - I was suggesting you might be able to do this with your level design to avoid the problem.

Another workaround is to make the player's collision polygon only cover the base, instead of the full height of the object, as shown here: jumpthru-adjusted-poly.zip
This prevents the higher parts of the player from catching on to jump-thrus and avoids the problem even when the platforms are close.

Would these be enough to work around the problem?

[RichardAstrom]

I'm not sure, I'm still having some problems :)

The spaced one still gets snapped to the next platform. And it happens if there's only one platform as well if I overlap it when falling (I can upload a GIF of that later).

And the one with the adjusted polygon, it falls through the right platform if I first jump on the left one, this seems to happen everytime. Also I guess I would need to create a second sprite for hit detection against enemies using this method?

[SnipG]

Jumpthru seems to have a lot of bugged behaviors. But it still serves pretty good, if you set certain gravity, fall speeds etc or polygon sizes.

If you try to create that behavior "snapped to the next platform" by yourself for smooth platform behavior it would be pretty complex i bet.

Instead there should be new feature(jumpthru2.0) for more accurate jumpthru results, with new core logic. Which could also support this smooth "snapped to the next platform". And in the end you could define yourself how much it snaps! Atm you cannot control it. And after some time retire the old jumpthru.

And current jumpthru needs guide/info, which shows that after supporting a lot of different cases over the years, made it so that it has now own special behaviors.

My 5cents on the issue.

[AshleyScirra]

We're at the start of a new beta cycle now so it's a good time to make riskier changes so they get as much testing as possible. I've done some experimentation and increasing the precision of the floor landing detection should avoid any "snapping" problems. However it's probably a breaking change since there are probably some games out there that depend on the previously more relaxed detection (and even smaller changes in the past have caused breakages in the Platform behavior). We'll see how this plays out over the next few releases. If we have to we can probably add some kind of setting for the tolerance, but I'd prefer to avoid having to add micro-management features like that if possible - ideally it should just work in all cases.

[RichardAstrom]

That's great! Looking forward to trying it out!

[AshleyScirra]

This change is live in r190. Does it fix the issue for you? Meanwhile we'll have to keep an eye out for any regressions.

[RichardAstrom]

Ok, I've done some tests now and my initial feedback is that it's working much better! Thanks for looking into this!

[AshleyScirra]

OK, I'll close this for now, but I think there's a medium chance we will have to make further changes if there are any regressions.