(Platform Behavior) Object can 'slide' up slopes during a jump without ever landing.

[Tokinsom]

Problem description

If an object with the platform behavior jumps onto a slope while moving almost parallel with it, it will 'slide' up the slope and never actually land. The 'jump arc' is only completed when the object stops moving or encounters a flat surface.

Attach a .c3p

Platform JumpSlide Bug.zip

Steps to reproduce

1. Preview the .c3p and hold [Right Arrow]
2. The platform object will automatically jump at the right spots to reproduce the bug by colliding with the "Jumper" object.

Observed result

The platform object should turn blue when airborne, and yellow when on the floor. However, the platform object remains blue (airborne) despite having landed on a slope and moving up it. (You might need to repeat a few times for the bug to occur.)

Expected result

The platform object should revert back to yellow when landing on the slope and moving up it.

More details

It appears that platform objects are not allowed to land unless they are actually falling. Going up a slope at a certain angle range from a jump means the object will never fall, and thus this bug occurs.

Affected browsers/platforms:

All platforms

First affected release: This has been an issue for a very long time but surprisingly no one has ever reported it, or it has regressed.

System details

View details

Platform information Browser: NW.js Browser version: 0.47.2 Browser engine: Chromium Browser architecture: 64-bit Context: nwjs Operating system: Windows Operating system version: 10 Operating system architecture: 64-bit Device type: desktop Device pixel ratio: 1 Logical CPU cores: 16 Approx. device memory: 8 GB User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (@ac9418ba9c3bd7f6baaffa0b055dfe147e0f8364) NWjs/0.47.2 (like Chrome/84.0.4147.105) C3 release: r210.2 (stable) Language setting: en-US Local storage Storage quota (approx): 793 gb Storage usage (approx): 190 mb (0%) Persistant storage: Yes 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 (NVIDIA GeForce GTX 1080 Ti 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_compression_bptc EXT_texture_compression_rgtc 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]

I can't seem to reproduce any issue here, the platform sprite seems to reliably turn yellow on the slopes.

The Platform behavior logic is extremely complicated and very easy to break and cause regressions in other projects. I'm very cautious about making any kinds of changes to it, so unless there is a really clear and obvious way to reproduce the issue, I'd rather not touch it.

[Tokinsom]

@AshleyScirra I discovered this bug does not occur when my monitor is set to a refresh rate of 60, as I assume yours was at when trying to reproduce this bug. Any higher and it's extremely easy to reproduce.

The platform behavior has always had, even in C2, some subtle quirks with framerate. With 144hz and even 240+hz monitors becoming more and more popular, now is the time to really crack down on them.

(Sidenote I'm getting some serious deja vu here...I'm going to see if I can find this same report / discovery from a couple years back)

Here's a .gif just so you can see what's happening on my screen:

[AshleyScirra]

OK, I can reproduce if I set the time scale to 0.5 on startup, which reproduces the same delta-time values you'd get on a 120Hz display on my 60Hz display.

It looks like when the platform object touches the slope on the first jump, the movement vector is exactly aligned with the angle of the slope. This is one of these appalling edge cases that have kept coming up over the years, it's just unbelievable what a nightmare the Platform behavior is to get right!

[Tokinsom]

Trust me you're not alone. It's been, what, ~30 years since the 2D platformer slope was invented? To this day everyone does it differently or finds their own unique hack lol. My favorite is in "Leilani's Island" where he spawns invisible lifts/elevators to shift the player up or down based on their relative position to the slope object. Works surprisingly well but I'm sure there's 1,000 issues and special cases under the hood.

Ages ago I proposed either a simplified "retro platformer" behavior, and later the ability to toggle unneeded components from the platform behavior. I can only assume a large portion of its difficulty/complexity comes from trying to do so many things at once. While it's impressive, and handy at times, I would gladly disable a number of its features if it meant greater stability and precision. I sure would love to see ceiling slope interaction though...

[BonzerKitten]

I don't want to be nosy here, but I really needed to share a .gif on how Leilani's Island achieved the slope thingy, it's simply amazing and kind of funny to be honest. 😅

Link: https://ishisoft.com/wp-content/uploads/2019/12/AnimEdgeCaseSlopeBottom2.gif

[Fib100]

I'm not sure if it helps, but here's a few videos from Sebastian Lague on creating a platform controller in Unity. I understand it's Unity, not C3, but maybe his techniques will still be enlightening. His techniques seem to cover all the edge cases.

1) https://www.youtube.com/watch?v=OBtaLCmJexk (basic collisions using raycasts) 2) https://www.youtube.com/watch?v=cwcC2tIKObU (ascending slopes) 3) https://www.youtube.com/watch?v=kVBABNw1jaE (descending slopes)

[AshleyScirra]

After having spent about a decade working on the Platform behavior, and still having issues come up, I find it difficult to believe any platform algorithm is free from edge cases.

[AshleyScirra]

I looked in to this some more and it's really a nightmare edge case. I'm not actually sure it's possible to fix it.

It seems related to #2905 (itself a nightmarishly difficult edge case) and #3146 (which is missing the original project file - can you provide it again? I can't test if any changes will regress that issue again).

Each of those issues is a bit more clear cut: if you land on something at the peak of a jump, you should either land on it or not (issue #2905). Additionally, if you jump past a ledge, you should jump past it, and not snap to running along the ledge (which is what I think #3146 was about). However this case seems to be a half-way point between the two: you're jumping past a ledge but you do want to land on it; and the slope angle approximately coincides with the jump angle, so it's in a grey area between jumping and running up a slope. I can't figure out a way to solve this: if I force it to land and count as running along the ground, it regresses ledge-snapping issues; if I try to allow it to ignore the ground and count as a jump, it regresses peak-of-jump-landing issues. Hence I'm not sure it's possible to solve it. Are you sure you can't find some way to avoid this in your level design? I genuinely don't know what approach to take to fix this right now.

[Tokinsom]

I'll have to recreate the .c3p or see if there's a backup on my dropbox. Will have it reuploaded ASAP and comment here.

Unfortunately it's not something that can be fixed by changing the level design - anything with a dynamic jump height will encounter this bug if the apex of the jump is parallel with the slope.

Wouldn't the difference between this and the ledge-snapping involve something with the Y vector? Like even if the jump was parallel with a slope, wouldn't the Y vector be trying to go back to 0 / a positive number? As opposed to the ledge snapping where that's only a problem when the Y vector is negative.

[AshleyScirra]

The Y vector is negative in this case too. The logic to avoid ledge snapping is roughly "don't land, even if you could, if the Y vector is still pointing up". In this case the player has a Y vector pointing up as they are still in a jump, but they are also sliding along a slope at an angle that roughly matches the overall vector of movement. So the Y vector is still pointing up, and it's avoiding landing on the assumption that your jump will lift you off the ground, but because the movement vector roughly matches the slope, you don't visibly lift off the ground.

[Tokinsom]

@AshleyScirra I've remade & attached the missing .c3p for #3146 as you requested. You can still currently get the player to snap to the ledge if you put the jump strength to 283 or so, but that's so insanely precise it's a non-issue.