game loop
Author
http://jare.planet-d.net/docs/FixLoop.htm
Can anyone please explain what the interpolation is/should be here. Some code would be nice. What is the theory behind interpolation for a game loop?
[edited by - wolfbane on January 5, 2004 12:59:46 PM]
Okay, I don''t have any code offhand, but...
The setup that Javier outlines is marginally useful for a standard 2D setup, where animation consists of separate, discrete animation images that are displayed in sequence. It can be made to work, bu the drawing with interpolation is largely meaningless. That fixed time loop is really meant to be used in a system where you draw your animations as interpolations between 3D keyframes.
In a keyframed setup, you have keyframes which represent the animation pose at intervals of maybe 4 or 5 frames or so--this is really up to you. For each frame (game tick), you generate an intermediate frame, or pose, by interpolating between 2 keyframes, to generate a smooth blend between the keyframes. In a 2D setup, this would be somewhat equivalent to being able to morph between 2 animation cels, drawing a frame that lies "between" the 2 frames being morphed.
In Javier''s loop, it is possible that when the screen is drawn, the current animation can be between frames. Not just between keyframes, but actually between frames. By generating the percent within tick, you can generate the pose for the current frame, then interpolate that pose forward just a tiny bit to represent how far into the next tick we are. In a game where physical game ticks happen at maybe 15 or so a second(acceptable for an RTS), this smooths out the roughness that would crop up from actually displaying at 15 FPS. Instead, you generate intermediate displays as the tick progresses, interpolating animations so that while updates occur at 15 FPS, the actual animation is running at the maximum FPS allowed.
I use Javier''s loop in my current project, but I have discarded the drawing with interpolation stuff since it is a standard 2D. In this case, the screen might be drawing at 150 FPS, but most of the time it is just re-drawing the same scene over and over, which changes at a rate of 40 FPS because of the time step I fix the loop at. With interpolation, it would smooth out the 40 FPS rate, by being able to draw in between frames, in effect connecting the "dots" of a 40 FPS system, to draw at 150 FPS.
As an example: If a game unit move, say, 3 pixels per game tick or frame, and the percent within tick for a given render period happens to be 0.5 (halfway to the next frame), then the render with interpolation would advance the drawing position of that unit by 3*0.5, or 1.5 pixels to draw at that time, eliminating the 3 pixel jump in position per frame by drawing it at intermediate positions.
Josh
vertexnormal AT linuxmail DOT org
Check out Golem: Lands of Shadow, an isometrically rendered hack-and-slash inspired equally by Nethack and Diablo.
The setup that Javier outlines is marginally useful for a standard 2D setup, where animation consists of separate, discrete animation images that are displayed in sequence. It can be made to work, bu the drawing with interpolation is largely meaningless. That fixed time loop is really meant to be used in a system where you draw your animations as interpolations between 3D keyframes.
In a keyframed setup, you have keyframes which represent the animation pose at intervals of maybe 4 or 5 frames or so--this is really up to you. For each frame (game tick), you generate an intermediate frame, or pose, by interpolating between 2 keyframes, to generate a smooth blend between the keyframes. In a 2D setup, this would be somewhat equivalent to being able to morph between 2 animation cels, drawing a frame that lies "between" the 2 frames being morphed.
In Javier''s loop, it is possible that when the screen is drawn, the current animation can be between frames. Not just between keyframes, but actually between frames. By generating the percent within tick, you can generate the pose for the current frame, then interpolate that pose forward just a tiny bit to represent how far into the next tick we are. In a game where physical game ticks happen at maybe 15 or so a second(acceptable for an RTS), this smooths out the roughness that would crop up from actually displaying at 15 FPS. Instead, you generate intermediate displays as the tick progresses, interpolating animations so that while updates occur at 15 FPS, the actual animation is running at the maximum FPS allowed.
I use Javier''s loop in my current project, but I have discarded the drawing with interpolation stuff since it is a standard 2D. In this case, the screen might be drawing at 150 FPS, but most of the time it is just re-drawing the same scene over and over, which changes at a rate of 40 FPS because of the time step I fix the loop at. With interpolation, it would smooth out the 40 FPS rate, by being able to draw in between frames, in effect connecting the "dots" of a 40 FPS system, to draw at 150 FPS.
As an example: If a game unit move, say, 3 pixels per game tick or frame, and the percent within tick for a given render period happens to be 0.5 (halfway to the next frame), then the render with interpolation would advance the drawing position of that unit by 3*0.5, or 1.5 pixels to draw at that time, eliminating the 3 pixel jump in position per frame by drawing it at intermediate positions.
Josh
vertexnormal AT linuxmail DOT org
Check out Golem: Lands of Shadow, an isometrically rendered hack-and-slash inspired equally by Nethack and Diablo.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
