Scirra
Platformer object stuck in wall under certain conditions
Problem description
With certain jump and move speed parameters, the platformer object will get stuck inside the wall under the following conditions:
- Low resolution project ( 16x16 or 32x32 sprites )
- Low jump speed ( < 130 )
- When jumping, the movement button towards the wall is held
- The platform the object is standing on has a collision box 1px+ less than the wall
Attach a .c3p
Steps to reproduce
With the project above, the smaller top green cube is being controlled first. The two brown and orange boxes have collisions that match their shape.
-
Jump onto the brown box, move against the wall, and jump again while holding the right arrow key
- Player will get stuck in the wall and not move unless the right arrow key is released
- The same occurs with the orange box
-
Disable the platformer behavior on the small green box, enable it on the big green box, and repeat the above.
- The same occurs with the player getting stuck in the wall
The same occurs on the left side.
Observed result
The green player box gets stuck inside of the wall and does not fully complete the jump unless the right arrow button is released
Expected result
The green player box should jump with it's jump strength and slide along the wall it is beside, not getting stuck in it.
More details
Tested a few scenarios and the problem description conditions seem to be the trigger
Affected browsers/platforms: All browser platforms First affected release: Tested and problem occurs in both r270 and r290
System details
View details
Platform information Browser: Chrome Browser version: 100.0.4896.88 Browser engine: Chromium Context: browser Operating system: Windows Operating system version: 10 Device type: desktop Device pixel ratio: 1 Logical CPU cores: 12 Approx. device memory: 8 GB User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.88 Safari/537.36 C3 release: r290 (beta) Language setting: en-US
Local storage Storage quota (approx): 80 gb Storage usage (approx): 212 mb (0.3%) 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. (NVIDIA) Renderer: ANGLE (NVIDIA, NVIDIA GeForce RTX 2070 with Max-Q Design Direct3D11 vs_5_0 ps_5_0, D3D11) Major performance caveat: no Maximum texture size: 16384 Point size range: 1 to 1024 Extensions:
EXT_color_buffer_float EXT_color_buffer_half_float EXT_disjoint_timer_query_webgl2 EXT_float_blend EXT_texture_compression_bptc EXT_texture_compression_rgtc EXT_texture_filter_anisotropic EXT_texture_norm16 KHR_parallel_shader_compile OES_draw_buffers_indexed OES_texture_float_linear WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context WEBGL_multi_draw OVR_multiview2 Audio information System sample rate: 48000 Hz Output channels: 2 Output interpretation: speakers Supported decode formats:
WebM Opus (audio/webm; codecs=opus) Ogg Opus (audio/ogg; codecs=opus) WebM Vorbis (audio/webm; codecs=vorbis) Ogg Vorbis (audio/ogg; 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 AV1 (video/webm; codecs=av01.0.00M.08) MP4 AV1 (video/mp4; codecs=av01.0.00M.08) 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)
I had a look at this but it seems to work fine for me.
Does it still reproduce for you in the latest beta? If so can you find a more reliable way to reproduce it? Usually avoiding the need for inputs helps, i.e. if you can automate the repro with 'simulate control' it removes the possibility I'm not doing exactly the same thing as you.
Since writing the issue I've gotten a secondary monitor and after testing some more it looks like the issue is reproducible on a 144hz monitor, but not on a 60hz monitor.
If I change the framerate mode from V-Synced to full frames then the issue also occurs, except instead of hovering 1px off the block the player never actually gets off the ground. Sounds like the platform object parameters are not framerate / deltatime agnostic?
Here is a project using simulate control that will reproduce the issue on a 144hz v-synced monitor or under full frames.
Also - I noticed the game is v-synced to the monitor that is configured as the 'main display' in Windows display settings, rather than the monitor the game is launched from and running on. I don't know how other games/software handle this so this could be a non-issue.
Thanks!
Also forgot to mention - the above tests were done on the latest beta, r310.
Have experienced this too in my projects (https://paulplay.itch.io/doordasher) also using a 144hz screen. Can replicate it on a 60hz screen too though.
