SyntaxBomb - Indie Coders

According to this video, you have been using Delta time wrong.

I watched this the other day too, pretty decent video.

Yes I saw this a couple of months ago and I thought the guy seemed to be making sense but was on something perhaps so while I usually speed-up videos, maybe I need to slow this one down. He was kinda hyper.

Too bad Jonas didn't touch on frame rate independent velocity damping (or if he had then I somehow missed it).

Maybe we should all listen to BasicBoy, his games always run silky smooth...Please educate us mate.

Quote from: Steve Elliott on July 20, 2023, 22:44:10Maybe we should all listen to BasicBoy, his games always run silky smooth...Please educate us mate.

Hmmm... In my naivety I'm not certain how to take that, whether it's a genuine compliment or just tedious sarcasm . But assuming it's the former, nothing special's going on with my games - some of them do attempt frame-rate independence via delta timing e.g. "Tyoob" and (IIRC) the rather awful "Festive Burglar", and the others stupidly assume that everyone has 60Hz screens! (I remember you saying "Forces Of Darkness" ran too quickly on your 75Hz screen). And actually my games are prone to occasional glitches and stutterings depending on what Windows gets up to in the background, or when there's too much going on on the screen, or when there's too much for the dear old BASIC interpreter to cope with, so my games don't always run silky smooth.

I did learn some new things from Jonas's video, one of them being that I've been doing delta timing wrong! I definitely found it worth watching, and will probably give it a 2nd viewing.

I was just a bit surprised he didn't deal with speed or velocity damping (e.g. vel = 0.9995 * vel), although there are sources on the 'net that I've looked at in the past which do discuss this issue. It's not a biggie.

Not sarcasm, I just seem to remember your games playing smoothly that's all - like  Maizie Bones.

Ah, was that one of your games when I had a 75hz screen, no matter I have a 60hz screen now lol.

Can you elaborate on the "velocity damping" and please include your thoughts on this simple thing:
Delta timing is done remove the influence of "frame interval deviation". 
"Time" is still "intact" (you get a point in time which is "correct")

When now modifying the "velocity" of objects, you will actually impact physics of your game (time is "constantly flowing" but the time-based physic settings - like velocity - are adjusted).


Despite adjusting "physics" I would use delta timing also for rendering: as you decoupled physics from rendering already (you should do...) the delta timing approach is there to guarantee "physics" to be simulated with "correct times". Using delta timing (or maybe call it "tweening" here) for renders will then just interpolate between two physic frames (last + delta timed current one).


So yeah, please elaborate on it.


bye
Ron 

QuoteCan you elaborate on the "velocity damping"

By "velocity damping" I was referring to exponentially decaying velocity, which I've used in a few games of mine (IIRC), and I'm sure many others here have as well. For example, suppose you're in control of a game object (might be a spaceship) which has only horizontal movement. Pressing the 'left' or 'right' keys increases or decreases the object's velocity whose absolute value is clamped at some allowed maximum value. But if neither key is pressed, the object's horizontal velocity decreases rapidly (exponentially decays) to a crawl, and then perhaps eventually stops dead. As if some kind of frictional force has been applied.

In BASIC pseudo-code (no delta time stuff here):

maxVel = 4.0
xVel = 0
xAcc = 0.05
damping = 0.95

REPEAT
  CLS
  PROC_drawSprite( x, y )

  keypress = FALSE
  
  REM Check 'Z' key (accelerate leftwards):
  IF INKEY-98 THEN xVel -= xAcc : keypress = TRUE

  REM Check 'X' key (accelerate rightwards):
  IF INKEY-67 THEN xVel += xAcc : keypress = TRUE

  IF ABS(xVel) > maxVel THEN xVel = SGN(xVel) * maxVel
  IF keypress = FALSE THEN xVel *= damping 
  x += xVel
UNTIL FALSE

There's some discussions/info on the web about frame-rate independent velocity damping:

https://stackoverflow.com/questions/14013248/damping-velocity-with-deltatime
https://www.rorydriscoll.com/2016/03/07/frame-rate-independent-damping-using-lerp/
https://gamedev.stackexchange.com/questions/169558/how-can-i-fix-my-velocity-damping-to-work-with-any-delta-frame-time

Now, it turns out that I was wrong when I said Jonas' video doesn't deal with "velocity damping" (as I called it).  During my first viewing of the video, either through distraction or obtuseness, I failed to notice that Jonas had in fact briefly discussed applying delta time to decaying velocity (or speed, in his particular example), using an exponential function. So, my bad.

I'm currently making a game (a 3D shooter, if it ever gets finished) which I'm determined to make fully frame rate independent (as opposed to 'mostly' frame-rate independent), so I really need to swot up on this stuff.

Quoteand please include your thoughts on this simple thing:
Delta timing is done remove the influence of "frame interval deviation".
"Time" is still "intact" (you get a point in time which is "correct")

Yeah sorry, I have no interesting or informative insights to offer not already covered in depth by Wikipedia articles, and plenty of other resources.

(And I've spent enough flippin' time on this post already...)