LÖVE

kikito wrote:Kindof similar to brushing up your teeth between eating smelly cheese and going to the dentist.

I always give the dentist my raw, unadulterated stagnant fumes.

gordebak wrote:Actually I use velx and vely. I just wrote it here incorrectly.

Edit: Corrected the code.

I think the problem is somewhere else then. Why don't you just upload the whole .love file?

Anyway, robin explained it well, you define your speed as pixels per second, then multiply it by dt (every frame) to get the distance traveled between the frames.
So: EDIT: Of course there is the risk that I've misunderstood and you're past this stage.

Here it is.

Edit: Sorry, the code is a bit ugly.

bartbes wrote:Anyway, robin explained it well, you define your speed as pixels per second, then multiply it by dt (every frame) to get the distance traveled between the frames.
So:

Code: Select all

--somewhere, when the speed is set
velx = 200 -- pixels per second

--and the starting x position of your object
x = 15

--in update
x = x + velx*dt -- it moves 200 pixels per second, so after 1 second it will be at 215

EDIT: Of course there is the risk that I've misunderstood and you're past this stage.

That's what I do in the code. It works fine, but velocity changes from time to time. Especially after changing direction.

I haven't checked the code, but I think it's not dt.

Your speed is faster when you hold the arrow keys than when you release them. That explains how it changes after changing direction.

I checked the game on another computer, and it works fine. It seems that it's a hardware problem on my side.

The relative velocity (the velocity at each call) will change. But when you sum the displacement between your position at t = 0 and your displacement at t = 1, it will equal your velocity in pixels/second.

If you simply go, x = x + velx, then your velocity is in pixels/dt, which is 1/dt times faster than the above.

I think this is where you are getting the perception of a speed increase/decrease. If you just print(velx * dt) then it will look like a speed change. Just remember that isn't really the case.

I hope I have that math right. My brain hurts today.

MarekkPie wrote:The relative velocity (the velocity at each call) will change. But when you sum the displacement between your position at t = 0 and your displacement at t = 1, it will equal your velocity in pixels/second.

If you simply go, x = x + velx, then your velocity is in pixels/dt, which is 1/dt times faster than the above.

I think this is where you are getting the perception of a speed increase/decrease. If you just print(velx * dt) then it will look like a speed change. Just remember that isn't really the case.

I hope I have that math right. My brain hurts today.

But velx = difficulty * dt in this case. To be exact, x = x + (difficulty * dt). So it must be the same as what you said, right?

This is quite a lot of fun! Kudos.

My only niggle is that the music can get repetitive.