tag:blogger.com,1999:blog-5246987755651065286.post2351921572341782971..comments2024-02-22T16:15:42.388-08:00Comments on cbloom rants: 06-14-11 - How to do input for video gamescbloomhttp://www.blogger.com/profile/10714564834899413045noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-5246987755651065286.post-20968503303474301952011-09-24T22:33:52.156-07:002011-09-24T22:33:52.156-07:00With your system physical triggers based on player...With your system physical triggers based on player input are a full extra frame behind.<br /><br />I know it's appealing to think of the player as just another object to physically simulate, but I think the advantages of special-case hacking it are massive and worth doing.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-82266814412066630322011-09-24T21:03:47.675-07:002011-09-24T21:03:47.675-07:00Why evolve players separately from the world? With...Why evolve players separately from the world? With rigid body systems, my experience is it just leads to more special cases and instability.<br /><br />1. Detect penetrations and triggers<br />2. Read input<br />3. Run all rules based on triggers and input<br />4. Evolve physical simulation<br />5. Render state of worldjwatte_foodhttps://www.blogger.com/profile/16583557030926221707noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-89068457970350759422011-06-19T16:04:01.353-07:002011-06-19T16:04:01.353-07:00There's also the spillover effect. If you'...There's also the spillover effect. If you're in the mode of thinking about ordering input right to save milliseconds of input lag, you'll start catching other areas where you're allowing unnecessary lag and fix those too, and pretty soon you've eliminated three frames of lag instead of one.Aaronhttps://www.blogger.com/profile/13300224857283384872noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-1418383469476809462011-06-19T09:02:07.737-07:002011-06-19T09:02:07.737-07:00"If your game is running at 60 fps, the order..."If your game is running at 60 fps, the order of these things within a single frame is not significant. You're talking about times much shorter than 1/60th of a second. Other considerations dwarf input lag here."<br /><br />I don't agree with that. First of all, it's very rare for a game to actually run at 60 fps, the majority are 30 fps. But let's pretend for the moment that we do have a 60 fps game.<br /><br />It's very very unlikely the display is actually updated 16 millis after an input event, or even 33 millis after an input event. Only the old arcade games actually updated frames that fast.<br /><br />You probably have a frame of delay in your renderer (most people enqueue rendering these days for parallelism). Then you have a frame of delay in the page flip (nobody runs single buffered any more), and the graphics card/tv/monitor usually add at least 1 frame of delay.<br /><br />So a "60 fps" game generally has at least 50 millis of latency already, with no input lag.<br /><br />The difference in doing your input perfectly is another 10 millis or so (let's say, 2/3 of the frame time at 16 millis per frame).<br /><br />So you can either have 50 millis of lag or 60 millis of lag.<br /><br />It's unlikely that anyone would feel that difference (certainly running at 30 fps vs 60 fps is a much bigger issue), but why would you refuse it? It's a little bit less latency *for free* , all it takes is some careful thought.<br /><br />Obviously the big issue is games that have 200 millis of lag, if you're down to 60 you're already doing well, but really if you're down to 60 you're probably thinking about these issues already.<br /><br />And even if you don't really care about the 10 millis I contend that it's good to go through this kind of reasoning, because this is how you get low lag and good responsive games - you trace the effect of user input through the code processing path and see what order it effects the world and make sure the latency is what you want.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-76833740310582375582011-06-19T07:32:23.736-07:002011-06-19T07:32:23.736-07:00You mention giving the player enough time to react...You mention giving the player enough time to react to an enemy's action by rendering ASAP after input. If your game is running at 60 fps, the order of these things within a single frame is not significant. You're talking about times much shorter than 1/60th of a second. Other considerations dwarf input lag here.<br /><br />Input lag frustrates me as both a developer and a competitive gamer, but I don't think this will have the effect you're imagining.<br /><br />The notes about abstraction/decoupling are great though.rosshttps://www.blogger.com/profile/08323812510412226897noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-57539000877755644482011-06-15T16:04:00.793-07:002011-06-15T16:04:00.793-07:00If the "prepare" step has any substantia...If the "prepare" step has any substantial variance, I'm suspicious of the inconsistency in feel. For that reason I think I lean toward the simpler version.Thatcher Ulrichhttps://www.blogger.com/profile/01374419756386535175noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-31823508226619259002011-06-15T12:19:08.289-07:002011-06-15T12:19:08.289-07:00"Point #2 can be further simplified by"
..."Point #2 can be further simplified by"<br /><br />Not really. The verbose version of point #2 is important.<br /><br />There's a lot of games that do <br /><br />"Gather inputs, Simulate, Render"<br /><br />and get it wrong. Just saying that is not enough.<br /><br />For example, the simulate phase might move bullets before creating bullets.<br /><br />To minimize latency, it's crucial that those sub-steps are ordered correctly.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-87751391727181492732011-06-15T11:57:01.565-07:002011-06-15T11:57:01.565-07:00Point #2 can be further simplified by
Gather inpu...Point #2 can be further simplified by<br /><br />Gather inputs<br><br />Simulate, "time evolve the world"<br><br />Render<br /><br />All applications should follow this logic, they will be simpler for it. Even if you want to run your input polling on a separate thread (so you can get higher resolution response curves) you should "lock in" the view that the application has on the input state at a fixed point in the processing loop.-tom!https://www.blogger.com/profile/07515615876924659948noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-82428061226714782522011-06-15T08:30:36.914-07:002011-06-15T08:30:36.914-07:00"pre-building the draw buffers is problematic..."pre-building the draw buffers is problematic if the player has direct control over the camera (e.g. mouselook)"<br /><br />Ah yeah, good point, I was thinking in terms of 3rd person console game. But you can certainly still do most of the render work before the input poll (things like animating skinned characters).cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-81724504472022999662011-06-15T07:02:39.169-07:002011-06-15T07:02:39.169-07:00John Carmack speaks about inputs at about 14 minut...John Carmack speaks about inputs at about 14 minutes in this 20 minutes interview.<br />http://www.computerandvideogames.com/306236/news/id-softwares-john-carmack-20-minute-video-interview/<br /><br /><br />Input latency is something that drives me mad, and with the rise of multicore machines, my understanding as a non-programmer is that it will only get worse as long as games use multicore engines.Nino Mojohttps://www.blogger.com/profile/14761941491077975645noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-16811581701851477412011-06-15T00:56:55.699-07:002011-06-15T00:56:55.699-07:00In method 1, pre-building the draw buffers is prob...In method 1, pre-building the draw buffers is problematic if the player has direct control over the camera (e.g. mouselook), since you won't know what to draw until after processing player input.<br /><br />Hmm, there MIGHT actually be something to be said for polling the mouse position at the absolute last moment before rendering, which means separate from the rest of user input (which is usually latent through accelerations/decelerations anyway).Anonymousnoreply@blogger.com