Coffeehouse Thread

43 posts

Microsoft admits Direct3D and GPU's are not designed for gaming

Back to Forum: Coffeehouse
  • User profile image
    BitFlipper

    , 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.

  • User profile image
    Minh

    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?

  • User profile image
    Minh

    Also "Microsoft admits"... I like that haha

  • User profile image
    BitFlipper

    , 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.

  • User profile image
    Minh

    , 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.

    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.

  • User profile image
    BitFlipper

    , 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.

  • User profile image
    Ion Todirel
  • User profile image
    Sven Groot

    , 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.

  • User profile image
    Minh

    , 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.

    you can't have both a local arbitrator and a remote arbitrator. All networked games have to deal w latency. When you don't see the problem, it's either low or consistent latency, or you're just lucky and local predictive actions happened to hide the lag. When you notice it, there's lag thatthe local gamecould not overcome.

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

  • User profile image
    figuerres

    , 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.....

  • User profile image
    Proton2

    There is a big difference between processing new information inside of the brain and having the fingertips responding to the new information. The lag time is still about 200 ms. Some commenters are confusing the issue.

    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.

  • User profile image
    androidi

    Yes, while this issue is certainly very applicable to some "massively singleplayer" or pseudo-multiplayer games like TrackMania (where cars don't hit each other but milliseconds and accurate reaction are key and errors accumulate due to car momentum), multiplayer games where the "reaction environment" is chaotic and the closest you can get to a pattern that can be anticipated (thus making the reaction time irrelevant and making the driver etc lag very critical) is probably a case where someone is trying to dodge your instant hit (quake railgun type) weapon very predictably by having some sort of predictable pattern in their movements - only in such online shooter scenario you can really speak of "anticipation horizon", provided the network lag is very constant also.

    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.

  • User profile image
    DCMonkey

    I think what you're all missing is that you are arguing with a being with a positronic brain. His reaction times are going to be much faster than a human.

  • User profile image
    androidi

    @DCMonkey: As I just explained again (and again now), this is about noticing a predictable pattern (like a curve where you're going into so fast that you'll hit the wall or fly out the track if you don't time your controlling accurately) that you can anticipate, and the only thing that matters is accurately timed action to that pattern - but if your *action* is timed poorly, the pattern changes (you crash the car). Note that this isn't about reaction but action to known (or highly probable/predictable) information!

    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!)

  • User profile image
    androidi

    Last time (incase that edit didn't come visible due to c9 caching):

    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)

  • User profile image
    Sven Groot

    You know, I used to be utterly addicted to TrackMania Nations and TrackMania Nations Forever, and I don't recall the problem you're describing ever being an issue. I certainly never had the problem where my first attempts at a track were better than later attempts.

  • User profile image
    Blue Ink

    @androidi: This reminds me of a game we used to play in high school instead of counting rhymes (hey, we were grown ups, right?): we took a chronograph and tried to stop it as close as possible to some predetermined time, usually 10 seconds.

    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.

  • User profile image
    androidi

    @Sven Groot:

    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.

     

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.