I am working on a platformer, and right now I am trying to get the physics right. I really want to make the physics from scratch (no pun intended) instead of using an engine or tutorial, or something like that. However, the landings after a jump are inconsistent, and it looks and feels awful. The link is below. Please help, and thanks!
https://scratch.mit.edu/projects/1259408308/
- iana

[bIn Scratch, inconsistent landing physics are often caused by the sprite “sinking” into the ground during a high-speed fall before the script detects a collision. Because the y velocity changes the sprite's position in large chunks, the player might end up several pixels inside the floor, causing jittery corrections.
]

naveenjo wrote:

[bIn Scratch, inconsistent landing physics are often caused by the sprite “sinking” into the ground during a high-speed fall before the script detects a collision. Because the y velocity changes the sprite's position in large chunks, the player might end up several pixels inside the floor, causing jittery corrections.
]

do you know what i can do to fix it in my project? i already tried one way, and it helped but didn't fix it.

remove the wait block at the end and change the “change yvel by -1” to “change yvel by -0.8” (that part is found in if grounded = 0 and near grounded = 0)

I recently tried out a new idea I had for a sidescroller demo I wrote. I'm trying to deal with a weird jumping problem (ugh, don't ask), but I'm super happy with my new gravity code! Since you don't want to just “follow a tutorial” or copy/paste, I'll explain what I do and let you try to work it out for yourself.

So… You've overshot the ground. Your deceleration rate (y velocity) is at -6 but the ground is only 3 pixels beneath you. Doh! Ok, standard protocol is to reverse the drop (go back up +6) and then go down slowly until you hit the ground. Right? But I can hear you thinking…

THERE'S GOTTA BE A BETTER WAY!

Ok, maybe I used to spend too much time watching infomercials on tv. Anyway, what if we just… stop overshooting the ground entirely? Without screen refresh on a custom block, I measure the actual distance until I touch the ground. I drop by 1 until I touch the ground (or until I hit a maximum loop count to prevent an infinite loop). After measuring the drop, I move the sprite back to its original position. It's all done without refresh, so it's quick and never noticed by the player. After running that, I check to see if the actual distance to the ground is less than my current rate of descent. If so, I simply drop by the real distance instead of the descent.

Anyway, there's always more than one way to do it, but this was something that came to mind so I tried it out. I'm pretty happy with the results. Is it better than other methods? Not necessarily.

Oh my god, you might be a genius. And yeah, I did read the “THERE'S GOTTA BE A BETTER WAY!” in a funny commercial voice.

It warms my heart to no end that you got the reference. As I was typing it, I very specifically had that one super famous made-for-tv guy's voice in my head.

Well, yeah, the idea is smart. I might do it with a 0% opacity sprite instead of the player to stop anything weird or embarrassing happening, but it's way better than what I came up with, which doesn't really fix the problem. Thanks a bunch!

I suppose I should've mentioned I always change costumes to a hitbox before checking for collisions, then change back when done. Oops.
Since it should be done in a no-refresh block, it doesn't need transparency. Just switch costumes, test, switch back. User won't even see it happen.

kansea wrote:

I suppose I should've mentioned I always change costumes to a hitbox before checking for collisions, then change back when done. Oops.
Since it should be done in a no-refresh block, it doesn't need transparency. Just switch costumes, test, switch back. User won't even see it happen.

Oh, okay then! I don't need to switch costumes though; the hitbox and visual is the same (though the hurtbox is different). Thanks again!

Well, I've made the change, and it works perfectly, except for a strange bounce that happens occasionally. Did you have this problem too, or is it just me? Could you check it out (the change is saved in the project)?

Good morning! I managed to replicate the bug, so I'm taking a look at the code now. I haven't had that particular problem with mine.

The problem appears to be with the sizing/positioning of your hitbox costumes. I got the character bouncing up and down, and while I let it run, I changed the head hitbox from a width of 3 to 2, recentered, and it stopped bouncing. But it causes another issue with being able to partially fall into a block. Alternatively, temporarily disabling the head broadcast (by pulling the set yvel out of the Receive head event) also stopped it from bouncing.

kansea wrote:

The problem appears to be with the sizing/positioning of your hitbox costumes. I got the character bouncing up and down, and while I let it run, I changed the head hitbox from a width of 3 to 2, recentered, and it stopped bouncing. But it causes another issue with being able to partially fall into a block. Alternatively, temporarily disabling the head broadcast (by pulling the set yvel out of the Receive head event) also stopped it from bouncing.

This makes me think the problem has something to do with the fact that the hitboxes always follow the player. Maybe it's still happening during this process?

ianacojmockh wrote:

This makes me think the problem has something to do with the fact that the hitboxes always follow the player. Maybe it's still happening during this process?

I don't know if that's necessarily a problem, but I do know that there's always going to be a slight delay in one sprite going to another sprite. I always keep my hitbox (I generally only use one, but I've toyed with separate line-based hitboxes like yours) on my player sprite. A big part of that is for organization and how I handle my collision detection, but in your case it would also mean zero delay.

Again, not sure that's necessarily the problem though.

This is an example of what I do (although the jump collision detection is currently broken):

https://scratch.mit.edu/projects/1219287231/

Scroll down to the bottom of the Player sprite. Of note are the Gravity and GetDropDistance blocks.

Oh, wow, the answer was right in front of me again. I was going in steps of 4, not one. I thought it wouldn't make a difference, but sine the target position wasn't always rounded to 4, it could overshoot, causing the bounce. Bug fixed!

ianacojmockh wrote:

Oh, wow, the answer was right in front of me again. I was going in steps of 4, not one. I thought it wouldn't make a difference, but sine the target position wasn't always rounded to 4, it could overshoot, causing the bounce. Bug fixed!

Awesome!

Yeah, that was an issue for me when I first started working on a platformer (prior to this one).

“All my steps are powers of 2, so it should be fine!”

Famous last words. I started doing single steps after that.

kansea wrote:

ianacojmockh wrote:

Oh, wow, the answer was right in front of me again. I was going in steps of 4, not one. I thought it wouldn't make a difference, but sine the target position wasn't always rounded to 4, it could overshoot, causing the bounce. Bug fixed!

Awesome!

Yeah, that was an issue for me when I first started working on a platformer (prior to this one).

“All my steps are powers of 2, so it should be fine!”

Famous last words. I started doing single steps after that.

Yeah, I'm glad I fixed it. Thanks for your help! But I'm still not done fixing bugs . I get why people typically just use tutorials (but I'm glad I didn't, I like how the physics feel and it will work better with my future mechanics).

Actually, I know I'm relying a lot on others, but this bug is really stumping me. Could you check it out? The problem is that left wall collisions don't work.

Well, actually, never mind. I somehow fixed it. Scratch was just being silly, re-entering the value did the job.