It also depends a bit on your Monitor set up, some just have a slower response time than others. Most monitors these days are fine with it, but some others are more build for colour quality and not framerate. In those there is some ghosting going on, which in turn makes it harder to see the difference between 30 and 60 or even 120.
.
That game has been patched so much on the 360, Idle, it may not be a good example of what you mean but I think I understand where you're coming from. Same with Anderson, although his is a somewhat different definition. To me the difference between 30fps and 60fps in a passive sense could be called coarse and fine. Severe framerate drops and input lag caused by a lot of things going on all at once on the screen, is what I would describe as sluggish. This sort of thing can happen at any framerate, and often looks the worst at a lower fps.
How does dropping the framrate down to 30fps make it more responsive than 60fps? It never is. Pushing a button on the controller will get a response from the game twice as fast always.
Actually input speed and registration is independent of FPS. FPS is just the visual output results rendered out. Yes, higher FPS comes across as more responsive visually, but input response itself is independent, what people are referring to is part perception and a reflection of their own reaction speed to what is going on. Then again it is all how the game is coded, one could code to poll input in or out of step with FPS..
Are you ever going to tell me your point? The only impression I have from what you have said is that, in your opinion, 30fps games 'feels' more responsive? But wouldn't that just be a case of you forcing yourself to see what isn't even there. 60fps games always respond faster, regardless of feelings. Is what you are saying something along the lines of Call of Duty's "raise handgun sight" animation is faster than Halo's "raise heavy rocket launcher" animation? Because that still doesn't change that the 60fps game will always respond to the input faster unless your character is in the middle of performing an uninterruptible animation.
Actually you only told me your point once before. The other times were just saying "that's not my point." But you are saying that a 30fps games can be more responsive than a 60fps game. Why not explain how and why? I keep trying to decipher your posts, but you won't explain yourself adequately.
No. I had my original post and 2 after that to you specifically, so 3 times
I can only assume you're doing this on purpose at this point though., cause no where have I said that
Saying "30 FPS can be almost be as responsive as 60 FPS to the point which you wouldn't really be able to notice the difference" is exactly saying "a 30fps game can be smoother than another 30fps game but never actually more than a 60fps game." I'm just going to assume its a drunk evening for you and let you read your posts back over in the morning.
Actually that is another sham lately by the Gaming Bullies that ruin our fine hobby. A framerate does not have to have anything to do with the controller response. It all depends on how it is programmed. Yes it would have if the controller only is checked after the start/end of each drawn frame for changes. Like how many times has button A been pushed in the time it took the system to draw this frame.
. But since controller updates usually are not that heavy on a CPU, that almost never is a problem.
Puppeteer?Actually that is another sham lately by the Gaming Bullies that ruin our fine hobby. A framerate does not have to have anything to do with the controller response. It all depends on how it is programmed. Yes it would have if the controller only is checked after the start/end of each drawn frame for changes. Like how many times has button A been pushed in the time it took the system to draw this frame.
This however is not the best way to handle input, yes in the old days it might have when there really wasn't a way of having true multitasking running on your computer/console. But ever since multi core CPU's are a thing, or there are true multitasking solutions for single core solutions for single core systems. For instance when you buy a hard drive controller that isn't reliant on your CPU (rare these days, as so many SATA controllers are CPU dependant). But I'm digressing.
Now if you wish you could poll the controllers at 60hz, thus having the controller's changes read out at that framerate, if you then also update the state of the game on a separate thread. Running things like the controller, AI responses, physics calculation on a separate threads is actually far smarter to do than doing all of that after a draw cycle is complete. As such it doesn't matter if the game even runs at 15 FPS, as the input is handled separately and the graphics are only showing the state of the game rather than dictating the frequency of updates.
Now this isn't feasible for every game out there, some might actually wish for a tight coupling between the frame updates and controller input. But for most games that require speedy interaction, without having the speed of your GPU influence your game play input (like First person shooters), it is better to decouple them. So that during a small hiccup in frame rate your reflexes will still be read properly. It does however have a drawback, that if there somehow is a reason that your controler input is being read slower, like if the thread suffocates, it might appear that there is an even larger input lag
This is kind of how I've always imagined it worked. It's nice we have a source like Gaming Bullies to confirmed this.Actually that is another sham lately by the Gaming Bullies that ruin our fine hobby. A framerate does not have to have anything to do with the controller response. It all depends on how it is programmed. Yes it would have if the controller only is checked after the start/end of each drawn frame for changes. Like how many times has button A been pushed in the time it took the system to draw this frame.
This however is not the best way to handle input, yes in the old days it might have when there really wasn't a way of having true multitasking running on your computer/console. But ever since multi core CPU's are a thing, or there are true multitasking solutions for single core solutions for single core systems. For instance when you buy a hard drive controller that isn't reliant on your CPU (rare these days, as so many SATA controllers are CPU dependant). But I'm digressing.
Now if you wish you could poll the controllers at 60hz, thus having the controller's changes read out at that framerate, if you then also update the state of the game on a separate thread. Running things like the controller, AI responses, physics calculation on a separate threads is actually far smarter to do than doing all of that after a draw cycle is complete. As such it doesn't matter if the game even runs at 15 FPS, as the input is handled separately and the graphics are only showing the state of the game rather than dictating the frequency of updates.
Now this isn't feasible for every game out there, some might actually wish for a tight coupling between the frame updates and controller input. But for most games that require speedy interaction, without having the speed of your GPU influence your game play input (like First person shooters), it is better to decouple them. So that during a small hiccup in frame rate your reflexes will still be read properly. It does however have a drawback, that if there somehow is a reason that your controler input is being read slower, like if the thread suffocates, it might appear that there is an even larger input lag
Actually that is another sham lately by the Gaming Bullies that ruin our fine hobby. A framerate does not have to have anything to do with the controller response. It all depends on how it is programmed. Yes it would have if the controller only is checked after the start/end of each drawn frame for changes. Like how many times has button A been pushed in the time it took the system to draw this frame.
This however is not the best way to handle input, yes in the old days it might have when there really wasn't a way of having true multitasking running on your computer/console. But ever since multi core CPU's are a thing, or there are true multitasking solutions for single core solutions for single core systems. For instance when you buy a hard drive controller that isn't reliant on your CPU (rare these days, as so many SATA controllers are CPU dependant). But I'm digressing.
Now if you wish you could poll the controllers at 60hz, thus having the controller's changes read out at that framerate, if you then also update the state of the game on a separate thread. Running things like the controller, AI responses, physics calculation on a separate threads is actually far smarter to do than doing all of that after a draw cycle is complete. As such it doesn't matter if the game even runs at 15 FPS, as the input is handled separately and the graphics are only showing the state of the game rather than dictating the frequency of updates.
Now this isn't feasible for every game out there, some might actually wish for a tight coupling between the frame updates and controller input. But for most games that require speedy interaction, without having the speed of your GPU influence your game play input (like First person shooters), it is better to decouple them. So that during a small hiccup in frame rate your reflexes will still be read properly. It does however have a drawback, that if there somehow is a reason that your controler input is being read slower, like if the thread suffocates, it might appear that there is an even larger input lag
Some very dense text. Reading it felt like wading through molasses, but like Anderson said, it makes sense. Reminded me of the old forums and our absent tech-heads.
Who is puppeteer? No, I just feel a bit that there are some people really overstating the importance of graphics lately on several forums on the Internet. I usually am not this serious, but really do enjoy my gaming hobby. Lately however I feel it is being run into the ground by "bullies" that tend to just feel it is needed to be complete buffoons to each other. For instance on NeoGaf the amount of people just posting animated gifs and keeping replies to two nonsensical words, while before asking an actual developer to comment on something... is just shocking.
Indeed, it all comes down to how often you poll the input from the controllers, or have it generate an interrupt each time there is a state change. However that all comes down to how the game was coded.
