mynameisnotpaul wrote:
s-ol wrote:Sawamara wrote:...(lets give it a value of 1000, as in 1second), the movement is made, the accumulator value is set to 0. (Or, to be more precise: 0 + the amount of value it passed over 1000, so if it was 1010ms, then the I will start at 10ms.)
This is also what I would recommend, except you describe it in a bit complicated of a way - you are just talking about substraction. I usually do it like this:
Code: Select all
local time = 0
function love.update (dt)
time = time + dt
if time >= time_to_do_stuff then
-- do stuff
time = time - time_to_do_stuff
end
end
I tried implementing this code but it just results in my snake thing not moving at all. I changed the code a bit from the OP but I still don't know why it doesn't work. This is the code for reference:
Code: Select all
...
function love.update (dt)
time = time + dt
...
if time > snakeHead.speed then
time = 0
end
end
You didn't implement what I mentioned in my comment by the way. It's not a big deal for a snake game, but it can already be a noticeable effect and make the game easier to play for some players than for others, depending on hardware.
For example, imagine someone is playing at a constant 60 fps. That means dt is 1/60, and so after 6 frames "time" is at 0.1, but nothing happens yet, and then at 7 frames you reset the timer to 0 and do something.
So for one, your time is actually inaccurate, with a 'speed' of 0.1 and 60fps it takes not 6/60 = 0.10 but 7/60 = 0.1166s per loop.
That's already a lot of drift, but it's not that bad since if you designed the game and tested it, it doesn't really matter if when you mean 0.1 you actuall get 0.116 seconds, as long as it's consistent. But it's not:
Let's do the same example for someone who plays at 50fps:
1/50 * 5 = 0.1
but because you used a > instead of a >= it will loop only at 6/50 again, which is 1.2s, again different.
If you change it and add the >= these two examples will behave the same, but for framerates that don't evenly multiply up to your time of 0.1, the "time = 0" approach is going to be inaccurate anyway, and if dt is changing all the time aswell. For example with 45fps:
4/45 = 0.088 (< 0.1)
5/45 = 0.111 (< 0.1)
now if you subtract 0.1 from the "time" variable, the next iteration will have exactly 0.1 seconds to run, but with the time = 0, you are forgetting the fact that 0.011 seconds have passed already.
All these rather small numbers don't look like much of a difference, but your game is already harder at some speeds than on others, and if you write code like this it probably will be extremely hard to build something multiplayer.