H!,
-- start boring intro (you can skip this intro if you want)
I'm a new love2d user, and going to try love2d (old monkey2 / nim-lang coder )
But I don't want to start creating a game before I get the most important thing '100%' correct.
I want to create a simple 'adventure game' with simple collisions detection and animations.
That is the thing I can make. But I don't know what hardware is used by the people that are going to play the game.
And maybe in the future, love2d can compile to other devices like the switch (or in a sandbox or something).
So the game must run on 'all' devices at the same speed.
-- end intro
First I thought: just use fixed fps.
Then I thought: I need to use delta time (like I did before)
But then, I asked Google and give me this info:
https://dewitters.com/dewitters-gameloop/
https://gameprogrammingpatterns.com/game-loop.html
https://medium.com/@tglaiel/how-to-make ... c61210fe75
https://www.gamedev.net/blogs/entry/226 ... ing-godot/
http://rbwhitaker.wikidot.com/time-steps
http://mepem.com/pemcode/?p=50
https://web.archive.org/web/20170113180 ... -timestep/
http://www.java-gaming.org/topics/game- ... /view.html
And now I'm lost.
I was hoping that some love2d user uses the 'better' game loop like in the urls above, and give me some love2d example code how to implement that. So I can start using that and start converting some old (monkey 2d) code to love2d.
What to use/do ?
Yeah I created my first Poll
The game loop
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
Re: The game loop
The correct way of doing this is of course using deltatime. But it's not the easiest and the most straightforward way. You'll need some grasp on math, particularly the concept of integrals, to resolve your gameplay properly such that the game runs the same regardless of framerate (famous example of this implemented wrong: in Quake series you can run faster, jump higher and deal more damage per second if you have higher framerates).
Fixed frame time removes the burden of applying your timing math properly. That's the entire benefit. Beyond that, it creates problems when target system runs its display at a different framerate. It's particularly bad if it's a higher framerate because of forced reduced framerate and microstutter, but if it's a lower framerate it's not that nice either because there's still microstutter.
There's also hybrid system where logic framerate is fixed but render framerate is maxed out, and the motion is kept smooth through interpolation/extrapolation, but it's not particularly great because the former lags and the latter microstutters, for obvious reasons (if you feel like a mad lad you can have both microstutter and lag simultaneously by applying a mix of interpolation and extrapolation).
Finally, if your type of game allows it, you can have "frameless" logic and maxed out render framerate. You can use this if everything in your game happens at a precisely calculated moment in time rather than when any particular frame occurs, so that you can forego using frames for resolving logic entirely. You set up your animations (which now also includes sprite movement and whatnot) at these moments and the rendering engine renders them at any given framerate. It's probably the most math-intensive way of doing it, and it's far from universally applicable.
Fixed frame time removes the burden of applying your timing math properly. That's the entire benefit. Beyond that, it creates problems when target system runs its display at a different framerate. It's particularly bad if it's a higher framerate because of forced reduced framerate and microstutter, but if it's a lower framerate it's not that nice either because there's still microstutter.
There's also hybrid system where logic framerate is fixed but render framerate is maxed out, and the motion is kept smooth through interpolation/extrapolation, but it's not particularly great because the former lags and the latter microstutters, for obvious reasons (if you feel like a mad lad you can have both microstutter and lag simultaneously by applying a mix of interpolation and extrapolation).
Finally, if your type of game allows it, you can have "frameless" logic and maxed out render framerate. You can use this if everything in your game happens at a precisely calculated moment in time rather than when any particular frame occurs, so that you can forego using frames for resolving logic entirely. You set up your animations (which now also includes sprite movement and whatnot) at these moments and the rendering engine renders them at any given framerate. It's probably the most math-intensive way of doing it, and it's far from universally applicable.
Re: The game loop
DeltaTime
Because it can be hard to implement that in some scenarios.
source: https://medium.com/@tglaiel/how-to-make ... c61210fe75
Interpolation
The fun part is that you can skip the delta time, so no math problems
You need some extra variables, but the output is more 'correct', so a double win here.
All the examples above say to use interpolation, but I don't know the correct way to implement that in love2d.
I will try to make a interpolation example, but I guess nobody is using it here
That makes me wonder if there is a full cheat sheet for the use of delta-time math for the most common things ?
So I will skip that interpolation thing and use delta-time without math mistakes, resulting in wrong vector movement.
I really need some cheating sheet what math (deltatime) I need to use and when.The correct way of doing this is of course using deltatime.
Because it can be hard to implement that in some scenarios.
source: https://medium.com/@tglaiel/how-to-make ... c61210fe75
Code: Select all
Vec3D p0 = position;
Vec3D v0 = velocity;
Vec3D a = acceleration*(1.0/60.0);
double f = friction;
double n = dt*60;
double fN = pow(friction, n);
position = p0 + ((f*(a*(f*fN-f*(n+1)+n)+(f-1)*v0*(fN-1)))/((f-1)*(f-1)))*(1.0/60.0);
velocity = v0*fN+a*(f*(fN-1)/(f-1));
I had the 'same' problem before as he describes below in a other 'game'.Ok that last bit is literally cut and pasted from my engine utility code for “actual correct framerate independent move with speed-limiting friction” function and contains a little bit of extra cruft in there (those multiplies and divides by 60). But that is the “correct” variable timestep version of the previous snippit. I calculated it over the course of an hour or so with gratuitous help from wolfram alpha.
Now there’s going to be people saying why not just do:
speed += acceleration * deltaTime;
speed *= pow(friction, deltaTime);
position += speed * deltaTime;
And while something like that kinda works, it’s not actually correct. You can test it yourself. Do 2 updates of that with deltaTime set to 1, and do it once with deltaTime set to 2, and the results aren’t actually the same. Typically you want your game to run consistently, so having inconsistencies like this aren’t great. Its probably good enough if you know your deltaTimes are all around the same value, so then you need some code to make sure your updates are running at some kind of fixed rate and… oh. Right. We’re trying to do it the “CORRECT” way now.
If that tiny bit of code expands to that monstrous pile of math, imagine more complicated movement patterns involving multiple interacting objects and such. You can clearly see how doing it the “correct” way is infeasible. So the “rough approximation” is basically all you got. Lets ignore that for now and assume you actually do have the “actual correct” version of your movement functions. Good, right
You can jump about 1 tile high, and the game takes place on a grid of 1 tile blocks. Your feet need to clear the top of the block in order to land on it.
But since collision detection here is in discreet steps, if the game was running at a slower framerate your feet would sometimes not actually clear the top of the tile, even though the movement curve they followed was the same, and you would just slide down the wall instead.
This is obviously a solvable problem. But it illustrates the types of problems you encounter when trying to make your variable timestep game loop work correctly. You lose consistency and determinism, so you can just throw away the ability to do input replays or deterministic multiplayer and such.
Interpolation
The fun part is that you can skip the delta time, so no math problems
You need some extra variables, but the output is more 'correct', so a double win here.
Ow I din't see the microstutter in a other try-out (non love2d) but that was not tested 100%.but it's not particularly great because the former lags and the latter microstutters,
All the examples above say to use interpolation, but I don't know the correct way to implement that in love2d.
I will try to make a interpolation example, but I guess nobody is using it here
That makes me wonder if there is a full cheat sheet for the use of delta-time math for the most common things ?
So I will skip that interpolation thing and use delta-time without math mistakes, resulting in wrong vector movement.
Re: The game loop
I think that the only correct answer is "it depends", which is not listed as an option, so I selected "Other".
- zorg
- Party member
- Posts: 3444
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
- Contact:
Re: The game loop
I'm with P. on this one.
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
Who is online
Users browsing this forum: Google [Bot], slime and 210 guests