Health bar set frame int(health/10) 100 is full health. Divided by 10 assumes health bar has 10 animation frames 0 being low health, 10 being full health

If your health bar has 20 frames for finer resolution then divide health by 5 ( not 20 )

I think I got this right off the top of my head, but I usually use this kind of system

You could also set width of the health bar to value of health so it will shrink from 100 to 0. In this case just make sure the origin point is set to left not center

Not sure. With my game it was/is opposite. I was using force and it worked great on 60hz, but got screwed up with higher refresh rates. Changing to impulse seems to have fixed it. It may vary slightly, but is fine. With applying force it was unplayable.

Impulse should be applied just once when you hit something ( as fedca mentions above ). Maybe you were applying it every tick?

No, it's as simple as can be. Apply force at angle when player kicks the ball.

Because I had to simulate gravity myself, I had to simulate drag and slow the velocity slightly as it flies, but I tested without that line of code, same thing.

There is absolutely nothing being applied physics wise to the ball once it's kicked and moving.

But you may have provided a solution . Using impulse at angle instead of force produces similar results. Sort of a WTF moment for me Shouldn't either way work the same at different frame rates? Why is one more consistent than the other at different fps?

I guess I should have been more careful in differentiating those two. I'm testing it and impulse seems to work so far

Thanks

I thought so too, but it does not work as expected.

Can you try this version https://www.deusx.com/volley-master/

When you kick the ball at 60 hz it works as expected, but I saw some people playing at high refresh rates and it just bounces a little without reaching the goal ( Then I tried with unlimited frames and yeah, got the same result.

Ball uses physics in x,y only, gravity is disabled. I coded my own gravity with z-elevation, but that should not affect the actual physics

Ok, I linked to the published version

I know this has been discussed before, but it seems that no satisfactory solution has been found. I know about frame rate independent settings and all that

Anyway, I only have 60hz displays to test right now and of course it works fine, but I know that it does not work fine on let's say 144hz, not even close. Not doing anything complicated, just launching a ball in certain direction by applying force at angle.

On a 60 hz monitor it goes fast, on a 144hz monitor it barely moves ( not using gravity either, physics world gravity is 0 so nothing to slow it down other than the refresh rate ).

In testing trying/changing to Unlimited ( fullframes ) in project properties if I calculate the frame rate and then multiply the force applied by fps/60 it seems to work OK, but since frame rates are all over the place it gets a little janky.

I am hoping that this would be smooth on a real 144hz display because fps would be steady 144, and a simple solution

Example. I apply force of 400 in certain direction/at angle this works fine v-synced at 60hz

if somebody plays it on a 144hz monitor force applied would be 960 ( 400*(144/60 ) )

Does that make any sense?

I'm working 1/2 blind until I can test it out myself on a 144hz monitor, but it seems to work when testing with unlimited frame setting

Can't you just give it more time by using greater than 355 degrees instead of 359, and add trigger once while true, so it does not get triggered more than once while between 355 and 360

You can speed it up by skipping frames with actions.

Certain condition met > every tick ? animation go to currentframe +2

when you reach the last frame run it backwards with currentframe -2

Not ideal, but could work well depending on how smooth the animation is

Could be a for each problem.

Physics stay enabled because one sprite is outside the pink area, so you have to use a for each loop to enable/disable physics for each sprite.

for each sprite event, then add overlapping conditions as sub-event there

Anyway, that would be my guess