Shawn Hargreaves > XNA (in fact all of D3D and GPU hardware) is focused on 60hz animation, and not designed for either inputs or outputs with millisecond precision.

(note the italics)

Unfortunately game and tech journalism is in on this scam/conspiracy to ruin the arcade and twitch PC gaming experience for good.

I don't recall a single tech journalist using a benchmark for a true keyboard to display latency. (Input to output, that's pretty critical right?)

One could probably develop such benchmark tool on a breadboard with $5 of components from ebay, yet no one in the "tech" journalism has bothered. Maybe they aren't that much into tech or are paid to shut up about this by Nvidia, Intel and Microsoft.

I think it would be most interesting to see a line up of all sorts of PC hardware from early 80s to right now tested for end-to-end latency and jitter in end-to-end input-output.

I would not be entirely surprised if the best performing hardware, as usual, was made in, as usual, in the early 90s, as usual.

I think the solution could be a latency calibrated touch sensor pad and audio sensor, so you calibrate the audio input latency using the sensor pad, then subtract the travel time by analyzing the audio but this seems overly complicated.

how many humans can react in the millisecond time range ?

how many games *NEED* that level of high detail timing ?

now this is just a wild guess but I bet that most humans playing most games are just fine with n times a second level of timing.

as far as I have seen DX does a good job for most all games I have seen.

Heck to get a solid millisecond timing on I/O you would need to design a whole system to make sure that for example a Disk IO did not lock a thread that in turn created a lag on delivering a key click to some app.  that might not be a great way of stating that but just look at the real-time systems and know that windows is not *real-time* never has been.  and with XNA you add to that .net and GC and all that....

Other than that, I have never, ever experienced the kind of latency you are describing. I've never had a problem with a noticeable delay between my actions and the result on screen unless that delay was caused by network lag in a multiplayer game.

http://hypertextbook.com/facts/2006/reactiontime.shtml

Are you intentionally trying to be controversial in order to draw attention to yourself, or do you simply not understand the subject?

Let's assume the latter, because the former suggests deep psychological and self-confidence problems which is beyond the scope of Channel9.

Game loops generally run at either 16.7 or 33.3ms precision -- this is true of pretty much platforms, well beyond Microsoft's.  You'll find it on PlayStation, you'll find it on Wii, you'll find it on Android, you'll find it everywhere, going back for many years.  Why?  It's because many monitors made before the last couple years can't draw faster than at 60hz.  There are some 120hz and 240hz displays out there but they are often considered at a disadvantage relative to 60hz when displaying fast-moving video 60hz (or 30hz) content for a variety of complicated content production reasons.  It's only become possible in the two years or so to even get 120hz-capable desktop monitors and graphics cards, and of course, your CPU etc. need to be capable of rendering a frame of your game every 8.7ms if you expect it to be smooth.

What the person from Microsoft is talking about here, is millisecond precision, which means something closer to 1ms from the time you hit a key on a keyboard, to the time the display is updated.  This isn't really possible using any current PC technology, considering everything from USB latency, to memory protections afforded by modern operating systems, to the fact that it's very, very hard to write an input loop that is even capable of consistently taking 1,000 input polls a second and issuing commands that have visual results in 1ms.  This kind of perf is still multiples faster than what mainstream hardware is capable of today.

One millisecond is a hell of a lot shorter period of time than most programmers realise.  Sure, anyone can knock together a for loop in C# that multiplies 100,000 integers together in 1ms, but that's toddler-class compared to the computations needed to render even a single frame of a game that uses dozens of effects with thousands of textures, never mind handling collisions and other physics concerns, which is pretty much Ph.D. level math.

It all comes down to multiples.  If a game can't run its logic + render loop faster than every 33ms, then 60hz doesn't matter.  If a game can achieve everything consistently in 16hz, then yes, 60hz is possible.  But if it takes 17ms, then you won't be able to consistently draw at the display's refresh rate, and the game will not feel smooth.

None of this is related to the design of Direct3D or XNA.  They'll go as fast as the hardware allows.  Once we have USB 3.0 keyboards, monitors that run at 960hz, and graphics cards several times faster than are on the market today, then you can have your millisecond precision in games.  Until then, don't get worked up over the fact that it doesn't exist.

"The human eye and its brain interface, the human visual system, can process 10 to 12 separate images per second, perceiving them individually,^[1] but the threshold of perception is more complex, with different stimuli having different thresholds: the average shortest noticeable dark period, such as the flicker of a cathode ray tube monitor or fluorescent lamp, is 16 milliseconds,^[2] while single-millisecond visual stimulus may have a perceived duration between 100ms and 400ms due to persistence of vision in the visual cortex."

http://en.wikipedia.org/wiki/Frame_rate#Background

I can send an IP packet to Europe faster than I can send a pixel to the screen. How f'd up is that?

1 hour ago, Bas wrote

So how have we been playing all these games then?

I have decide to stop playing any games, because it's obviously not possible to play them. It's a shame really, I've nearly finished Skyrim.

Herbie

> average human reaction time appears to be around 200 to 250 milliseconds

Reaction time tests are really contrived and it's always a laughing point when they're quoted in irrelevant context: We usually get cues that allow to anticipate events from distance. Especially in gaming and musical context. I've seen how the 200-500 ms reaction time figures often quoted have been "deviced" and what it measures is the scenario that you are blind and deaf and suddenly your blindless is gone and you react to that singular and sudden event.

I already use a CRT and I can put it to 200 hz should I wish to, but that doesn't really tell anything about latencies. Reacting to game events is conceptually similar to a "feedback loop" in electronics, except that added latency increases the loop lenght while ability to anticipate (look-ahead) decreases it. In a game like TrackMania or many arcade style games, the intensity and satisfaction derived from the game is strongly correlated to the lenght of this feedback loop.

http://techreport.com/review/21516/inside-the-second-a-new-look-at-game-benchmarking/11

"To cushion jitter, Nvidia is increasing the amount of lag in the graphics subsystem".

Lets say the loop length is increased to reduce jitter (which may have something to do with an architecture that was designed for office/multitasking first in mind) that work better with a shorter feedback loop.

In this case, a theoretical fix is to keep the loop length the same (eg. target 120 hz vsync for 8,3 ms interval) to reduce jitter & tearing, but when user input arrives, the OS or game don't have to use a "polling" method to react to this, the keyboard/game controller and bus can be designed for low latency in a way that does not require any polling or electricity (schematics for soft switches that don't consume electricity are out there, eevblog detailed one). This key event can be made to use similar technology as 10 Gigabit ethernet or firewire, so the keyboard directly avails the buffer to the game without any OS intervention. The game can then look at how long the typical game loop took on the current system, and decide if there's time to re-run the loop based on the new input before that 8,3 ms timing window closes. This will shorten the feedback loop, as otherwise you'd possibly get that 8,3 ms additional delay.

Then there's the matter of 2D rendering. I have seen stats which suggest that for 2D rendering, XP with the appropriate card and drivers, is 10-20 times faster than Windows 7 with latest generation as of the making of those stats. 20 times faster and no jitter cushioning could potentially mean that XP+ old drivers and old graphics card has lower end to end latency. I saw 20 ms quoted for modern 3D stack driver latency. But to measure this, some measurement hardware is needed.

Based on my observations and feel of things, I believe that 50 ms latency end to end is likely typical for a gaming PC today. That is WAY TOO MUCH! Just by switching from LCD to CRT you can cut maybe 20-30 ms, so that's better, but from experience I know that you really want <20 ms to "feel in sync" with the game or musical instrument for a consumer level experience. At professional/competitive level, <10 ms is necessary.

No matter how many hz your display is updating, you don't really know from that figure how long it takes from a key press for something to happen on the screen.

It's much much easier to play when you don't need to input ahead of time (lag compensation) and rely on memorization (the increased end to end lag reduces the "anticipation horizon"). When I try playing things from memory, it's similar to playing piano from memory, instead of playing to the music, you're playing to some memorized thing and timing inprecision accumulates quickly and the outcome isn't as musical as when feeling the music already sounding and playing to the patterns and timings established live, not from memory.  And in case on TrackMania I've noticed consistently from years of playing now that my first race performance is often best because I don't have the memory messing things up and it's much more about anticipation based on the visual input, very similar to live jamming in music, you're anticipating what other players do. Great groove involves millisecond precision (swing/shuffle) and anticipation, musical context and "feeling it" makes that possible.

22 hours ago, Proton2 wrote

The average human reaction time appears to be around 200 to 250 milliseconds: 

That response time is a different thing. What you are talking about is the response time from seeing something and then responding physically. What this is talking about is the response time from performing an action and the display/sound reacting to it. Those two things are essentially serialized.

When playing online FPS games, anything more than about 50 ms round-trip network lag is starting to get annoying. 200 ms will be unplayable. This was true in the old days at least, but I think many games these days can mask the latency relatively well. They do this by performing the actions locally rather than waiting for the round-trip from the server before performing the action.

What I did was create a simple app with a button. When pressing the button, it would trigger a click sound. Then using an external microphone placed very close to the phone and a desktop audio application, I recorded me tapping on the screen and the resulting click from the phone. I then zoom in on the waveform and measure the time difference between the first audio event (hitting the screen with my finger) and the resulting audio click from the phone.

You should be able to rig something similar for keyboard-to-screen response time. Place a video camera such that it can capture both the keyboard and the screen at the same time. Then load a game or something that visually responds to key presses. The resulting video can be examined frame by frame in a video editor to see how many frames it takes for the key press to register on the screen. Recording at 60 fps gives you 17 ms resolution.

1 hour ago, BitFlipper wrote

BTW, there are relatively easy ways to test input-to-output latency. I did this once when I wanted to test the response time on a Windows Phone from touching the display to being able to produce a sound. It isn't just enough to know how large the input buffer is (100 ms is the smallest input buffer on Windows Phone - quite annoying). What you also need to test is how long does the OS take to send the touch event to the app, and how long does it take for the buffer of audio to actually be played out via the DAC?

What I did was create a simple app with a button. When pressing the button, it would trigger a click sound. Then using an external microphone placed very close to the phone and a desktop audio application, I recorded me tapping on the screen and the resulting click from the phone. I then zoom in on the waveform and measure the time difference between the first audio event (hitting the screen with my finger) and the resulting audio click from the phone.

You should be able to rig something similar for keyboard-to-screen response time. Place a video camera such that it can capture both the keyboard and the screen at the same time. Then load a game or something that visually responds to key presses. The resulting video can be examined frame by frame in a video editor to see how many frames it takes for the key press to register on the screen. Recording at 60 fps gives you 17 ms resolution.

 Recording at 60 fps gives you 17 ms resolution.

or if you need to get 1ms then you need to record at 1020 fps ?  LOL

15 minutes ago, figuerres wrote

*snip*

 Recording at 60 fps gives you 17 ms resolution.

or if you need to get 1ms then you need to record at 1020 fps ?  LOL 

What are you talking about? This is only for testing purposes. Recording video at 60 fps will give you the ability to resolve down to 17 ms intervals. When we are talking about human response times then 17 ms should give us enough resolution in most cases. What is so strange or funny about that?

And if you want to simplify things even further, you can simply state how many frames it took for the input to get to the screen. Hopefully it is within 2 frames since the input could have come a fraction of a second before the next frame was displayed in which case there would have been no way to respond in that frame.

BTW most TVs give you a "Gaming Mode" option where they turn off advanced processing since that usually delays the output by one or more frames. It's enough of an issue that they had to give a special mode for playing games.

Also, the notion that the human can only respond in 200 to 250 ms doesn't really apply in these cases because if you for instance record guitar into a computer and there is more than 20ms delay it becomes very distracting. It's about playing the string and expecting it to sound almost immediately. Even the slightest delay will throw you off. Now gaming isn't quite at that level but still, the threshold is much lower than 200 ms.

9 minutes ago, Minh wrote

One thing to keep in mind... Games never sample inputs every frame. Networked games with the builtin latency don't need to sample inputs that frequently. I remember reading something like 10 or 20 a sec only. So who really need single digit latency?

That is only true if the game follows the old style implementation where it waits for a round trip from the server before displaying the result of a local action. Modern games are good at hiding latency. Here is an example:

Let's say there is 200 ms round trip latency to the gaming server. Also let's say two people are facing each other with shotguns. Whoever shoots first will kill the other one. Now if player A presses the fire button 50ms before player B, then player A should win, right? Well what really happens is that on both screens it looks like both players fired their guns, because the local game responds immediately to the input action (or as fast as possible given the local system delays). Then as far as the server is concerned, player A fired first resulting in player B losing. So even though player B will see their gun fire, he will still lose as if he didn't fire at all.

8 minutes ago, BitFlipper wrote

*snip*

That is only true if the game follows the old style implementation where it waits for a round trip from the server before displaying the result of a local action. Modern games are good at hiding latency. Here is an example:

Let's say there is 200 ms round trip latency to the gaming server. Also let's say two people are facing each other with shotguns. Whoever shoots first will kill the other one. Now if player A presses the fire button 50ms before player B, then player A should win, right? Well what really happens is that on both screens it looks like both players fired their guns, because the local game responds immediately to the input action (or as fast as possible given the local system delays). Then as far as the server is concerned, player A fired first resulting in player B losing. So even though player B will see their gun fire, he will still lose as if he didn't fire at all.

1 hour ago, Minh wrote

*snip*what you are describing is just prediction by the local client as to what might happen, but to maintain a consistent universe there must still be one arbiter, the server ... Most likely one instance of thenetworked games.

Yes correct, but as far as input-to-screen latency is concerned, it is all local and as such it has little to do with network latency. What is important is the perceived responsiveness of the game. For instance, in Gears Of War (not sure if all versions did it), it is usually very hard to tell whether there is network latency or not. The only times you can really tell is when you do something and the outcome is completely unexpected or if your position jumps around (you enter a building but a second or two later you are outside again).

Not sure who here is old enough to remember but in the original Doom games for instance, the way it worked was that any input had to go through the server round trip, meaning that when you rotated it would usually lag half a sec or so, even on a good day. This caused a lot of people to get motion sickness. This was until they changed it to do movement locally.

13 hours ago, ZippyV wrote

https://twitter.com/id_aa_carmack/status/193480622533120001

I can send an IP packet to Europe faster than I can send a pixel to the screen. How f'd up is that?

http://superuser.com/questions/419070/transatlantic-ping-faster-than-sending-a-pixel-to-the-screen

7 hours ago, BitFlipper wrote

Let's say there is 200 ms round trip latency to the gaming server. Also let's say two people are facing each other with shotguns. Whoever shoots first will kill the other one. Now if player A presses the fire button 50ms before player B, then player A should win, right? Well what really happens is that on both screens it looks like both players fired their guns, because the local game responds immediately to the input action (or as fast as possible given the local system delays). Then as far as the server is concerned, player A fired first resulting in player B losing. So even though player B will see their gun fire, he will still lose as if he didn't fire at all.

The only multiplayer shooter I play is Mass Effect 3. Its multiplayer uses a host/client architecture, with one of the players designated the host. The host is responsible for all game calculations, and the other players are essentially just seeing a simulation of what the host is telling them is happening. It does use the prediction system you're talking about, but this doesn't really mask latency very well.

If there is significant lag, symptoms include "rubber banding" (your PC and the host disagree about where you are so you constantly snap back and forth between the two locations), and a noticeable delay on actions (shoot an enemy: two seconds later, it dies). Some of the weapons and powers are not hitscan (instant hit) but use projectiles with travel time. In this case there is a delay between pulling the trigger and the projectile starting to fly, making it essentially impossible to hit moving targets with a projectile weapon unless you're the host. The delay is especially fun for things that are supposed to restore your shields. You think you used an ops pack in time to save your life, but unfortunately the host already thought you were dead so it doesn't work. And the game is evil enough that it will still subtract an ops pack from your inventory in that situation, even though it didn't do anything.

Another fun one is the magnet grab. A few enemies in ME3 are capable of "sync kills", which means they grab you and instantly kill you regardless of how much health and shields you had, and team mates cannot revive you if you've been killed that way. Each enemy capable of doing this has a certain range at which they can do this, and some conditions that must be met. The fun part is when you think you're nowhere near such an enemy, but the host thinks you are. You will get grabbed, dragged towards the enemy, and killed, with no way to stop it. On bad connections, people have been grabbed from up to 30 metres away, sometimes even through walls.

However, I rarely host and 90% of the time the lag isn't bad enough to affect gameplay. Strangely enough, on those rare occasions where I am the host it almost feels like actions have results before I perform them because I'm so used to the slight lag of playing off-host.

(And there is a glitch where if you're hosting, one particularly nasty enemy type (Phantoms) have 90% damage reduction during their dodge animation making them nearly impossible to kill with hitscan weapons on host, which is one of the reasons I actually prefer playing off host)

But, again, while there is noticeable lag in network games like that, I've never had any such delay on my own computer like what android was talking about, except in NFS3 which had notoriously slow control responses.

7 hours ago, BitFlipper wrote

*snip*

Yes correct, but as far as input-to-screen latency is concerned, it is all local and as such it has little to do with network latency. What is important is the perceived responsiveness of the game. For instance, in Gears Of War (not sure if all versions did it), it is usually very hard to tell whether there is network latency or not. The only times you can really tell is when you do something and the outcome is completely unexpected or if your position jumps around (you enter a building but a second or two later you are outside again).

Not sure who here is old enough to remember but in the original Doom games for instance, the way it worked was that any input had to go through the server round trip, meaning that when you rotated it would usually lag half a sec or so, even on a good day. This caused a lot of people to get motion sickness. This was until they changed it to do movement locally.

Im not sure about the original doom game. I've only played it on a LAN and never had a problem

12 hours ago, BitFlipper wrote

*snip*

What are you talking about? This is only for testing purposes. Recording video at 60 fps will give you the ability to resolve down to 17 ms intervals. When we are talking about human response times then 17 ms should give us enough resolution in most cases. What is so strange or funny about that?

And if you want to simplify things even further, you can simply state how many frames it took for the input to get to the screen. Hopefully it is within 2 frames since the input could have come a fraction of a second before the next frame was displayed in which case there would have been no way to respond in that frame.

BTW most TVs give you a "Gaming Mode" option where they turn off advanced processing since that usually delays the output by one or more frames. It's enough of an issue that they had to give a special mode for playing games.

Also, the notion that the human can only respond in 200 to 250 ms doesn't really apply in these cases because if you for instance record guitar into a computer and there is more than 20ms delay it becomes very distracting. It's about playing the string and expecting it to sound almost immediately. Even the slightest delay will throw you off. Now gaming isn't quite at that level but still, the threshold is much lower than 200 ms.

possibly I was not clear, joking that the folks who must have 1 MS timing might also need a frame rate that matches....  as DX is too slow and was not designed for high speed games that require high resolution timing.   if you can react that fast you also need the screen to update that fast or the display will lag and you will not be able to fully use your "MATRIX" bullet time skills to full effect.

is that clear ?   cue up a neo fight now.....

Note here the key of new information. That's why there is a 2 second rule to following the person in front of you, in a motor vehicle.

I think the fact that Carmack has made some noise about this as well suggests that leading game designers have such driver lag actually affect their game design decisions.

There are some music games where you can cheat/skirt around the lag issues because your input to the music game does not affect the tempo of the music. If you compare this to arcade or driving games, your actions do affect what will happen in future (momentum). There may be interesting game ideas that are not just doable right now because if you do them you will find that in order to get the anticipatory and "in tight sync with the world yet allowing each time be new experience", the gameplay just becomes worse and worse the more end to end lag and jitter there is.

TrackMania is very similar scenario to playing music live with others - your actions establish new patterns but if timing is inaccurate they will sound bad in the context of the current established pattern (think ninjam, zero-lag global live jamming, your midi input (usb lag) latency and jitter matters a lot). I love both of these and the popularity of TrackMania was in the millions until they made some "poor" business moves trying to kill the free game in favor of the new v2. (the right model would have been to charge players of custom tracks and provide rev share to most played user tracks, as the user made tracks are the life of the game, similar to music again! - musical instrument makers don't make the popular music!)

This isn't about reaction but action to known (or highly probable/predictable) information! Computer I-O lag is all that matters in this scenario!

Only if your action was poorly timed, the information flow changes so much that you have to react to it (like the faster you drive or the tempo is, the less time you have to anticipate and time your action to the changed pattern / error in the position in the environment).

This guy would know what I'm talking (were he to try use midi drums in ninjam) about were he still alive.

(3 min 20 sec comes my favorite part)

(4 min 10 sec comes my favorite part)

That's a highly predictable event, so there's no reaction timing involved, and yet it's quite hard to nail the time exactly (that would have been an error of -5..+5 ms as the cheap digital watches we used only had two decimal digits) and nearly impossible to do that consistently. I would be surprised if anybody could get an average significantly better than the (roughly) 17ms of a 60fps game loop.

If you have a chronograph lying around, you may want to try that.

It likely boils to "people are different".

Best short analogy: I play music by ear and hate learning "by rote". Quickly recalling things in great detail is not my forte, I need some context through ear or visually and that helps me to recall the details.

In the TrackMania case, if the context is delayed by latency, that shortens the actionable time, or opportunity to press the correct key in time. By context I mean, in TrackMania there are repeating elements in the track designs, so you learn one particular curve, and as other track authors use the same type of curve often, one just needs to recall is the timings for that curve, and time the actions as I see that curve approaching. This allows the play of relatively advanced and never seen before maps with high success rate (finishing the track on first attempt at full speed without crash). Some authors use custom tools to make track modifications not possible in the built in track editor to keep things fresh.

That's much closer but not exactly the same as the kind of game and musical scenarios I'm discussing. That sounds more like a "singular" or "relatively rarely repeating" pattern/game.

In TrackMania fullspeed tracks and music, the predictable patterns repeat so often that after warming up you get much better in accuracy.

It takes me usually 1-3 hours of warming up (after days/weeks of not playing) to play keyboard at <10 ms accuracy, this is sort of similar to TrackMania, where if I kept weeks/months of break, I wouldn't perform well enough in my favorite tracks* without some warm up play. (*unable to reach finish due to error accumulation which reduces the window of opportunity to time the action accurately in the "full acceleration/speed required" tracks)

5 minutes ago, androidi wrote

@Blue Ink:

That's much closer but not exactly the same as the kind of game and musical scenarios I'm discussing. That sounds more like a "singular" or "relatively rarely repeating" pattern/game.

In TrackMania fullspeed tracks and music, the predictable patterns repeat so often that after warming up you get much better in accuracy.

It takes me usually 1-3 hours of warming up (after days/weeks of not playing) to play keyboard at <10 ms accuracy, this is sort of similar to TrackMania, where if I kept weeks/months of break, I wouldn't perform well enough in my favorite tracks* without some warm up play. (*unable to reach finish due to error accumulation which reduces the window of opportunity to time the action accurately in the "full acceleration/speed required" tracks)

 

I hate tracks that can't be finished unless you play them flawlessly. I want to be able to do the first run really really slowly and horrible just to get a feel of where I'm supposed to go, and then I'll work on getting the speed up. But with required full speed tracks, you just end up being unable to make a jump and then when you finally do make it past that part you have no idea what to expect so I immediately crash (and watching the "GPS" does not work for me, I won't remember it unless I've driven it myself).

Similarly back when I used to play piano I would start out slow but once I began to internalize the movements I could get up some good speed. Not as fast as this guy though (the insanely fast bit is at the end of the video):

Note that a piano, because of the mechanical movement of the hammers, has some pretty large lag between keypress and sound.

20 hours ago, cbae wrote

By definition, any game that DEPENDS on millisecond precision suffers from really shitty gameplay.

This deserved a response of its own:

Some of the best games outside the adventure and RPG genres are those that offer enough incentive/advantage for those that master controls in a high precision manner. Now I don't like street fightning games, I am talking about things like BF1942 Desert Combat helicopter controls. 2 weeks of constant crashing to get a handle on it, but it's extremely rewarding and the controls manage to create great feel of flying and "gravity", creating a much more fun experience than anything in any other game because they didn't try to simulate a real helicopter but the controls, I am told, resemble more the feel of flying a RC helicopter in "3D" show-manner, which is no doubt a ton of fun too until you crash!

The helicopter controls are so much worse in rest of the Battlefield series that many DC players quit playing the game as DICE/EA didn't keep those controls, the DICE/EA choppers fly like a friggin school bus with an anti-gravity device in comparison and you can't do similar flying atleast using keyboard (maybe with the aid of a gamepad you can) since the keyboard controls don't have that precision. It's just a whole lot of fun flying in DC with a keyboard as your both hands fingers get a full workout keeping the thing in air.

re: TrackMania

It's possible you encountered either too advanced tracks (sounds like it) or missed a trick or two. After playing a lot of fullspeed tracks I can quickly spot some bad track design as well - though "bad" can also be interpreted in a way that there's some trick you need to know. If there's some unfamiliar thing causing failures I may watch and play against the world record times as some of the subtleties are hard to discover. These are easily found online.

Personally I don't like tracks with great deal of jumps & loops or no acceleration in the first half of the track. This is because if these conditions exist, the track actually becomes more difficult as those elements drain your momentum so much that the rest of the track becomes impossible if you make a slightest mistake in those early elements. Accelerator tiles are more forgiving usually, the tracks where you must drive through accelerator tiles perfectly to reach the finish exist but I see them less often on the servers I play as those jumps & loops tracks. Typically in "smooth tracks" if your wheels aren't oriented straight going in and coming out of loops and jumps, speed is lost or you crash at the edge. Line up to the loops/jumps early and avoid any drifting or wheels coming off the ground at any point of the track in these "smooth" tracks. Any corrections done inside loops really eat the momentum/speed.

Best beginner track in my opinion is Phase 2 by Socius. Most fun tracks are: ESL - Midnight Skillz` 3, Toxin Flash 2 and Wallride City. I can probably play them at my current skill quite easily even with a laggy computer and LCD, but it won't be nowhere as fun as on a low IO latency setup and for beginner with high latency LCD these are probably torture.

The learning approach I used for the more difficult fullspeed tracks was to download both the world record replay and another replay that's closer to the time that you can play. Watch the tricks in the world record replay and play against the one that you have hope of beating using the stuff in the wr replay.

Complete "bollocks" as they say in the UK. I don't like fast games like platformers. The TrackMania fullspeed maps are more about flow and feel only fast if you aren't familiar with them, there's no collisions to other cars. BF1942 Desert Combat mod plays very slow compared to other FPS. It's all about the flow & controls, rhythm/pacing and the atmosphere if it's an adventure or rpg. It's very hard to act precisely or correctly to random input. I like things that are predictable yet positively surprising. (In games with exploration, some randomness done cleverly can be very good though)

This personally very influential concert for example is quite slow for most part yet works due its precise timing that you can sort of anticipate as a listener. I just love it when music is well thought out and makes sense. The other extreme is called "guitar noodling".

1 day ago, androidi wrote

@Blue Ink:

That's much closer but not exactly the same as the kind of game and musical scenarios I'm discussing. That sounds more like a "singular" or "relatively rarely repeating" pattern/game.

...

I was simply pointing out that there's plenty of games you can write and play at 60fps, regardless of what kind of lag Direct3D and GPUs introduce, as long as it's constant.

But 60fps is not set in stone: even in XNA you can speed up the game loop (or use a variable speed one), as long as your hardware can keep up. The problem is that higher graphic details are more likely to drive sales rather than a massively faster game loop.

(a hybrid approach, with a faster input loop is technically possible, but it's just a nightmare to pull off)

So yes, you have a point: in some conditions games don't simulate reality faster than humans can interact with it, but that has nothing to do with the technology being used. It has to do with priorities and what is considered to be good enough for the industry.