I solved this. Thanks.

That's right - you shouldn't. So that's completely out of question. All it gives you is slightly simplier programming, and that's it. It's a false claim that it gets you better physics, too. It's good for newbs who can't get into deeper details, but overall, it's a mess and in reality it doesn't wo...

Minor detail: don't call love.draw() in love.update(). They're both callbacks. Also, why don't you simply multiply speed by dt instead of mucking about with semi-fixed timesteps? Thanks. I'll fix that. Because I want to experiment. Because other software I am familiar with uses fixed timesteps. Bec...

As I said, rewrite the love.run function. What I really suggest is to avoid using "fixed" timestep approach. I enquote it because no matter how hard you try, you can't get it really fixed, due to many many factors. Fixed timestep anyway is a simplification of dynamic timestep, a tradeoff ...

raidho36 wrote:That's because you're doing it wrong. You should re-write love.run function rather than tamper with it's workflow.

Well, duh. Obviously my implementation is incorrect. How should I go about fixing it?

I'm trying to fix my time step and use interpolation to correct the visual stuttering, and although this is leaps better than my first attempts, it's still not perfect. I'm updating the game at 30 ticks per second. I know, for example, that GameMaker can run games at 30 ticks per second and doesn't ...