The "Delta" variable [RELOADED]

Newbie & Debugging Questions
#1

Alright,

Shall we talk a bit more about that delta variable ?
I did understand the concept behind it, but there’s still something I don’t get.

I’m still using the < app.setTargetFrameRate(60) > easy mode, but I wish I could use the delta someday.

When you use assisted-tools/makers (Game Maker & such), you usually don’t have to worry about the time because when you set the FPS to 60, you’re pretty sure that a script in there will be called 60 times per second (probably less if lagging, but no more)
That bit is really important for, say, fighting games, when you want to have a character’s punch last for exactly 5 frames.
Still, when I try to think on how to achieve this with the delta variable, my mind doesn’t seem to be able to resolve this. >:(

For example, lots of game use something like < posX += velocity * delta >, but I don’t see how I can apply something like that for a game when I want to make absolutely sure that each “important” frames are shown.
If a ball were to bounce off a wall, with proper collision code it won’t be a problem but isn’t there a risk that you “won’t see” the ball bouncing off the wall?
To be precise, let’s say that we have something like that :

//velocity = 1, T stands here for Time, or a Tick in the game loop actually.
T1: x += velocity; //x - 2
T2: x += velocity; //x - 1
T3: x += velocity; //x reached -> bouncing -> velocity *= -1
T4: x += velocity; //x - 1 (moving away)

It may be my imagination but let say that I put some sort of a pause-shining-effect at T3, isn’t there a risk that it might just be ignored since the time elapsed went straight from T2 to T4 due to the delta variable? … I don’t know, I just feel like I’m misunderstanding something about the delta variable here.

Edit : Since my english is bad, here’s a little picture of what I’m trying to say :

http://dl.dropbox.com/u/21670438/delta.jpg

Note that since it went straight for a position to another due to delta, I somewhat “missed” the time when i want to “pause” the game.

#2
#3

Make sure your physics, rendering, and user input response are all done separately. Prioritize physics so that when there is lag you only lose a few frames instead of delaying game play and messing up the player’s timing. Run the physics simulation in discrete (no delta) steps so that the simulation is consistent, predictable, and easier to debug. Record the user’s input and wait until the next (physics) update cycle to process it. Save the time the event occurs so that all commands are processed in the right order and in relation to the user’s perception of the game state. Render as often as you can in the time you have left, using linear interpolation to smooth the paths of fast moving objects.

If the user can react with objects directly and you want twitch reaction style game play (such as aiming at a moving character) then use the time you recorded as a result of user input to inform the physics engine so it can do similar interpolation such that it can calculate a hit or a miss accurately even if user input came midway through a physics update cycle.

If you have problems with inaccurate graphic rendering interpolation then calculate potential collisions one step ahead of time. Store the start coordinates, the collision coordinates, the collision time, and the end coordinates. Interpolate between the start and middle coordinates if you’re rendering before the collision will/might happen or between the middle and end coordinates otherwise. Don’t bother with this though unless it seems like things are temporarily flying through walls due to an uninformed graphics interpolation.

Don’t rely on effects that last an exact number of frames. There’s no guarantee the player will get those frames and if you’re talking about a very brief animation then it probably is happening too fast for the user to notice that level of detail. If you still want to provide the visual cue you can jump into the middle of an animation and try to show what you can, replace long shining/glowing/sparkling effects with an easy to render quick flash effect or overlay multiple frames as if you were trying to do motion blurring.

Don’t worry about the user not seeing the ball hit a wall. If the physics engine responds correctly and most of the frames show the ball in its correct spot the player will see an “optical illusion” and know the ball hit the wall even if they don’t see it at that exact motion. Even if you do happen to render at that exact correct time, there’s still a chance the player will blink. And blinking doesn’t throw off a person’s perception for things like that, even in real life.

You can update at a fairly low rate like 20 ticks per second and a higher frame rate like 60 fps and get a very realistic result. And by saving input times and processing them in the correct order you can still maintain correct responses even if you have multiple players on a single computer or if the user sends a series of commands in the same update cycle. At worst feedback will be delayed the length of your update cycle but everything else will be accurate, including (and most importantly) timing.