Post subject: Do PC games have ingame lag?
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11268
Location: RU
There's been a discussion in russian wikipedia about the term "lag". My opponent says that PC games never fail to pull the controller or refresh the screen, there's just a variable framerate. I don't know anything about PC games so it's snag for me.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Post subject: Re: Do PC games have ingame lag?
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
feos wrote:
There's been a discussion in russian wikipedia about the term "lag". My opponent says that PC games never fail to pull the controller or refresh the screen, there's just a variable framerate. I don't know anything about PC games so it's snag for me.
Define "PC game". The very first PC games ever created assumed an certain exact CPU (and would run faster if the CPU was faster). This is the reason why even some 486's had a "turbo" button to slow down the CPU.
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11268
Location: RU
I mean modern games. When computers have all these videocards and gigabytes of RAM.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Define "lag". Generally games must try to make the gameplay proceed always at the same average speed regardless of the speed of the PC because else the game would, rather obviously, become completely unplayable (way too slow in slow machines, way too fast in faster ones). If the machine is slow, the gameplay will make "bigger jumps" to compensate, and vice-versa, so that the average speed is always the same. OTOH, "lag" could also be defined as "slow framerate". In other words, even though the gameplay (eg. running) speed is always the same, the screen will update less frequently on a slow computer. If it's really slow, then one could say that it's "laggy". (Certainly, if you imagine eg. having to play a modern game at 2 frames per second, "laggy" would be an apt name for it.) If the game has to pause to load data, then that's true lag in the sense that the player has to wait and the game doesn't advance for that period of time.
AnS
Emulator Coder, Experienced player (723)
Joined: 2/23/2006
Posts: 682
It's really a matter of semantics. If you want to define lag similar to old console games then modern games don't have lag. Because good games don't sync input/physics with rendering anymore, they run them either in separate threads or simply using separate delta timings (for example simulation can use fixed timestamp, while rendering can have variable FPS). http://en.wikipedia.org/wiki/Delta_time http://gafferongames.com/game-physics/fix-your-timestep/ But if you define lag as a time difference between expected and received result, then probably anything lags from time to time. But nowadays you can't measure lag in frames, you should measure it in milliseconds.
Joined: 7/2/2007
Posts: 3960
It's all in how you code the game...but ultimately, the answer is "yes, PC games can have lag." The simplest type of game loop has a defined time per frame that it tries to maintain. Each frame, it polls for input, processes input, updates game state, and then draws to the screen. Then it sleeps until it's time to draw the next frame. You'll get "lag" (in the sense that the game will visually stutter) if it takes longer than the target time per frame to process a single frame. You can be sneakier about this by disconnecting the drawing code from the physics update code. In this scenario you have a target drawing rate of, say, 60 FPS, and a target physics update rate that's much lower, e.g. 15 FPS. Then you modify the above loop to have multiple draw actions while waiting for the next "physics frame" to occur. These draw actions interpolate positions and animations between the last two physics frames to give smooth motion, so they aren't redundant. If physics start taking a long time, then you don't draw as often (creating less-smooth motion), but the game still "happens" at the same speed (i.e. objects don't start suddenly moving more slowly). However, if the physics take long enough that the 15FPS rate of physics updates can't be maintained then you're back to getting lag again.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.