# Confusion about timing and lag

This topic is 3481 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm trying to understand the mechanics of how a videogame works in principle. From what I could tell it's a giant while loop that caps its framerate to 30 fps, each iteration performing game logic and rendering to the video buffer. My question if it's necessary to give some cycles back to the OS? Say we have code that executes whenever a frame goes by. Whenever that code is not executing, we need to call a function like Sleep() or something. But instead of wasting cycles like that, couldn't we process AI, movement, and logic code based on a computed delta time, and then simply render every time a frame goes by? What I mean to say is we somehow separate logic from presentation, so if there's a time consuming task to be done like sorting huge lists we don't waste cycles? Would it hang up the system, or would the system be smart enough to allocate time to each process so not calling Sleep() will not have ill effects? Also, how would executing scripts to control the actors work without a severe performance penalty? Let's say a thousand instances of the same script needs to be running simultaneously for the same type of enemy. How would you be able to process all that information without severely lagging down the game? In a real platformer there are many, many objects that have behaviors, and many instances of the same script. How would it all integrate seamlessly? Maybe 100 different actions could be happening at once!

##### Share on other sites
You can use Sleep() when the basic calculation and rendering is completed in an iteration, and then you can start a new thread to proceed other functions or calculations.

##### Share on other sites
Would code like this work?

...Forever   AbortIfExitCondition   HandleGameLogic   If deltaTime > 33.3 ms      RenderEverything   EndIfEndForever

Or will it destroy a user's system because I didn't call Sleep()?

##### Share on other sites
What most PC games do is just compute everything they can, drop what they need to the GPU, and move onto the next frame. Everything is computed based on the computed delta time between the last frames.
You can modify this model to be multithreaded (or just have time accumulators) so that you only step your calcuations at a set rate (say 30fps) and refresh the screen as fast as you can with data interpolated between the last 2 sets of calculated game state.
You can modify this even further to give different calculations different update rates. Like user input at 120fps, but physics at 20fps, and AI planning scrips at 1fps.
Or modify the plan so that you update 20 AI scripts per cycle at 30fps (600scrips/sec) to space out calculations inorder to keep the game running smooth. And the player won't notice that the AI takes a few frames to change it's planning.

And to your thought about scripts. The key thing when you are thinking scripting is to know that scripts are SLOW compared to native code. So you want to abstract the script to a high enough level where it is useful to the game. This means something like the AI's planning is done in script, but all the stuff like "find targets", "aim at location" and "path to point B" are all done in native code. Take for instance Resistance Fall Of Man. They had AI that ran in two main states. Thinking AI and "Drones". Thinking AI changed what it did all the time in response to the player. "Drones" mindelessly did one task untill some signal made them think. So the logic for a "Drone" to sit there and shoot was fast and simple compared to the logic that activated to choose what the drone would do next.

--edit

What you REALLY want is something like

while ( 1 )
AbortIfExitCondition

If deltaTimeAccum > 33.3 ms
HandleGameLogic

RenderEverything

assuming you wanted a fixed timestep on your logic, and your logic takes less time than your timestep to actually compute.

or you could do

while ( 1 )
handleGameLogic ( deltaTime )
renderFrame

or you can get complex with multithreading.

The point being that there are reasons to update your game loop quickly (responsive to the player, stable physics). But unless it is multiplayer, where the acutal ms you clicked counts, the player will never even see that you updated 200times between frames, so you may as well just do more work and only have one cpu update per graphical frame.

The other side of that is if your computations are slow, and you render only after a frame of data is done than the game seems choppy. But if you interpolate between the last two game updates and continously display frames than the game doesn't seem choppy, just slow. And this reads better to the player.

Also, unless you are running in windowed mode, the user probably doesn't care so much that their computer isn't doing anything but running your game. Even then, who cares most of the time. The only thing the user cares about is being able to task switch to some other program, at wich point, depending on the type of game, you may as well pause anyway, since the player isn't paying attention to the game. Or, if you don't want to pause the logic, just keep the same logic update rate, but don't do any of your rendering calculations.

[Edited by - KulSeran on July 13, 2008 5:23:16 AM]