- Nov 13, 2006
- 6,381
- 290
- 38,240
Not true. If you don't have enough GPU/CPU horsepower for your game, FPS will dip below 30, regardless of settings.
TheGreatGrapeApe
Champion
- Feb 18, 2003
- 20,040
- 0
- 50,960
While you're at it, ask you optometrist if they believe that crap. If they do, then they never took a sensation and perception course in their life.
If that crap you posted were the only aspect, then those of us who see RGB artifacts in DLPs wouldn't experience that. Also the level of refresh required depends alot on the situation, the image, and the method being used to display/convey the image.
Second, fluro lights illuminate on the peak and trough of the sinus waves, therefore they fire at 120hz, also the coating on fluro bulbs has a latent illuminative quality, both of these lead to vary rare situations where we notice them and its usually only with sympathetic flashes that it becomes an issue, unless of course the ballast is F'ed up and you have exaggerated effects.
Many many aspects are involved in the appearance of fluidity, including contrast, brightness levels, image sharpness, convergent motion, level of sequential image divergence (similar frames are easier to make fluid than those with more differences), angle of solid lines, and angle of motion, also whether or not you look straight on at something or use more of your peripheral vision (rods are more sensitive than cones).
Actually that's a false rule, since it depends alot on the game or scene as to whether or not 30fps is the min.
For something like Splinter Cell and other creeper style games 20fps would be fine because the need to refresh the scene and the view of the player is limited.
Whereas twitch FPS games have alot of motion and also require higher refresh rates to reduce the impact of entire scene motion. If your character is jumping while turning, you need far faster refresh to have fluid motion and proper visuals. Also remember that when doing something like a 180degree turn you need high refresh rate to paint scenes correctly so that you even achieve minimal refresh for the range of motion.
Effects like motion blur help reduce the number of frames required for fluidity, but it also reduces the level of accuracy for FPS games.
so imagine this scenario:
you have your system on the signature: and you are playing a game with 50~60 fps, sometimes where the game comes with a very complex scene, the fps down to 30, and in all the game the minimum fps will be 30, so you must(thats dont exist) have an option to always run with 30 fps
i think thats could be better, sorry to be boring you guys hehehehe
you have your system on the signature: and you are playing a game with 50~60 fps, sometimes where the game comes with a very complex scene, the fps down to 30, and in all the game the minimum fps will be 30, so you must(thats dont exist) have an option to always run with 30 fps
i think thats could be better, sorry to be boring you guys hehehehe
TheGreatGrapeApe
Champion
- Feb 18, 2003
- 20,040
- 0
- 50,960
I'm not understanding what you're trying to say, but if it's anything like clamping the framerate to 30fps, that's similar to what happens in consoles, where they adjust the scenes when developing them so that they can stay constant near 30fps. Unfortunately that doesn't always happen, as was seen in games like Quake4 for X360.
TabrisDarkPeace
Distinguished
- Jan 11, 2006
- 1,378
- 0
- 19,280
Besides the fact that film and TV signals are often interlaced, etc.....
Movies are passive (output only) and as such do not require < 2 ms reaction times during combat at times.
FPS Games / Simulations have:
1) A non-static frame rate (Average of 60 may mean it dips under 2 fps at times, but only for a moment, then does 200 fps down a hallway latter on).
2) Require input and output, Especially from the mouse
A one frame delay (normal for both) on a movie makes no difference, as you don't know it is one frame behind.
In a video game being 1-2 frame behind (double, or triple buffering, and/or DirectX 'render ahead') is noticeable, especially if the frame rate is under 40 fps - to most people it can be 'just' perceived at under 60fps.
In double blind tests over a group of intense FPS gamers around 15% or so will be able to feel the difference between 60 fps, and 80 fps *(minimum sustained fps, not average fps) just through the mouse delay.
This is even more true if the input resolution (sample rate) is limited to the frame rate (eg: fps_max 60 in HL2, vs fps_max 80 in HL2 does this. In double blind tests it gives highly accurate and repeatable results 8) ).
And yes, this is even if the refresh rate is 75 Hz (vs 85 Hz plus) as it affects input delay (you get this zen like state and enter a feedback loop with the game after an hour or so above 60 fps in an intense fps, like Half-Life 2 DM, or Quake 3).
Things that do not require input / fast reaction and output video + audio stream only are typically fine to view at 24 - 30 fps, even as low as 12 fps over a large area (or 8fps over a small area).
Over the last decade or so I've researched this subject quite particularly - it is most interesting that it keeps coming up - Some people swear black and blue they can't see the difference between 40 and 60 fps, however if in an interactive FPS environment they will usually complain when performance dips under 60 fps (double blind) as it seams to affect input and accuracy.
Also bear in mind that a 1-2 frame buffer at 60 fps is only 1/60th (~17ms) to 1/30th (~33ms) of a second of latency between sight and reaction, while at 40 fps it is 1/40th (25 ms) to 1/20th (50 ms).
All OpenGL and DirectX applications use at least double buffering, so your sight is always at least 1 frame 'behind'.
Some games sample input only once per frame, others multiple times using an isolated thread at very high sample resolutions.
Sound / Audio is often heard within 2 - 5 ms, where as a frame relating to the sound might not be 'seen' for another 10 - 45 ms after the audio was heard. Which is why some players can react (or pre-empt) at very high speeds (if they play to use 3D positional audio to their advantage).
SLI / Crossfire may actually buffer 2-4 frames ahead too, but if the frame rate is +70% to +90% higher for a given scene then it keeps pace. However SLI / Crossfire at the 'same' frame rate (eg: higher res, more FSAA, etc) will have more frame-draw latency (often around 50 ms before 'current action' frame is rendered) and this actually disadvantages players using high resolution / FSAA, but only in CQB, at long range higher resolution is typically more desirable.
One of the reasons I've researched so much into this, is because I once wanted to make a 3D FPS MP engine that cancelled out 'all' forms of lag, so long as network latency was 125 ms or less. Via making all even slightly accurate weapon aiming take around 50 - 125 ms to occur, much as it does in real-life and some military simulators.
Lining up a pixel with someones head, and not modelling the ballistics accurately (eg: a 250m shot requires more aim up, different style, compared to a 50m shot, and the round will take noticeable time to hit the target).
Even at muzzle velocity a round at 600 m/sec will take over 400 ms to hit its target, if the target is moving then one must 'lead' the target before letting off a round (sniper rifle or not). This is assuming the round doesn't decelerate too, which is also incorrect, but more simple to model in a fast paced MP FPS.
It is unlikely I'll ever make such a MP FPS, but with any luck, one day, maybe some-one else will use these ideas in their own FPS, or a very anti-cheat Open-Source MP FPS.
Movies are passive (output only) and as such do not require < 2 ms reaction times during combat at times.
FPS Games / Simulations have:
1) A non-static frame rate (Average of 60 may mean it dips under 2 fps at times, but only for a moment, then does 200 fps down a hallway latter on).
2) Require input and output, Especially from the mouse
A one frame delay (normal for both) on a movie makes no difference, as you don't know it is one frame behind.
In a video game being 1-2 frame behind (double, or triple buffering, and/or DirectX 'render ahead') is noticeable, especially if the frame rate is under 40 fps - to most people it can be 'just' perceived at under 60fps.
In double blind tests over a group of intense FPS gamers around 15% or so will be able to feel the difference between 60 fps, and 80 fps *(minimum sustained fps, not average fps) just through the mouse delay.
This is even more true if the input resolution (sample rate) is limited to the frame rate (eg: fps_max 60 in HL2, vs fps_max 80 in HL2 does this. In double blind tests it gives highly accurate and repeatable results 8) ).
And yes, this is even if the refresh rate is 75 Hz (vs 85 Hz plus) as it affects input delay (you get this zen like state and enter a feedback loop with the game after an hour or so above 60 fps in an intense fps, like Half-Life 2 DM, or Quake 3).
Things that do not require input / fast reaction and output video + audio stream only are typically fine to view at 24 - 30 fps, even as low as 12 fps over a large area (or 8fps over a small area).
Over the last decade or so I've researched this subject quite particularly - it is most interesting that it keeps coming up - Some people swear black and blue they can't see the difference between 40 and 60 fps, however if in an interactive FPS environment they will usually complain when performance dips under 60 fps (double blind) as it seams to affect input and accuracy.
Also bear in mind that a 1-2 frame buffer at 60 fps is only 1/60th (~17ms) to 1/30th (~33ms) of a second of latency between sight and reaction, while at 40 fps it is 1/40th (25 ms) to 1/20th (50 ms).
All OpenGL and DirectX applications use at least double buffering, so your sight is always at least 1 frame 'behind'.
Some games sample input only once per frame, others multiple times using an isolated thread at very high sample resolutions.
Sound / Audio is often heard within 2 - 5 ms, where as a frame relating to the sound might not be 'seen' for another 10 - 45 ms after the audio was heard. Which is why some players can react (or pre-empt) at very high speeds (if they play to use 3D positional audio to their advantage).
SLI / Crossfire may actually buffer 2-4 frames ahead too, but if the frame rate is +70% to +90% higher for a given scene then it keeps pace. However SLI / Crossfire at the 'same' frame rate (eg: higher res, more FSAA, etc) will have more frame-draw latency (often around 50 ms before 'current action' frame is rendered) and this actually disadvantages players using high resolution / FSAA, but only in CQB, at long range higher resolution is typically more desirable.
One of the reasons I've researched so much into this, is because I once wanted to make a 3D FPS MP engine that cancelled out 'all' forms of lag, so long as network latency was 125 ms or less. Via making all even slightly accurate weapon aiming take around 50 - 125 ms to occur, much as it does in real-life and some military simulators.
Lining up a pixel with someones head, and not modelling the ballistics accurately (eg: a 250m shot requires more aim up, different style, compared to a 50m shot, and the round will take noticeable time to hit the target).
Even at muzzle velocity a round at 600 m/sec will take over 400 ms to hit its target, if the target is moving then one must 'lead' the target before letting off a round (sniper rifle or not). This is assuming the round doesn't decelerate too, which is also incorrect, but more simple to model in a fast paced MP FPS.
It is unlikely I'll ever make such a MP FPS, but with any luck, one day, maybe some-one else will use these ideas in their own FPS, or a very anti-cheat Open-Source MP FPS.
TheGreatGrapeApe
Champion
- Feb 18, 2003
- 20,040
- 0
- 50,960
No worries, just wasn't sure if I understood you correctly.
As long as the point is understood it's all good.
Main thing to remember is that there is no hard and fast rule as for what is acceptable to everyone, it's a question of situation and the number of people who see differences. Games are adding features like motion blur to help improve the appearance of fluidity, of course it's more GPU intensive to do that, so depending on the penalty for adding that effect it may be a case of improving one aspect at the cost of another, like if the framerate drops from 45fps to 20fps due to the added stress of properly rendered motion blur, then maybe the original 45fps without motion blur may have looked better before.
Anywhoo, this question has been discussed many times here, and while alot of people think they have THE answer, there really isn't just one single answer for all scenarios/games.
As long as the point is understood it's all good.
Main thing to remember is that there is no hard and fast rule as for what is acceptable to everyone, it's a question of situation and the number of people who see differences. Games are adding features like motion blur to help improve the appearance of fluidity, of course it's more GPU intensive to do that, so depending on the penalty for adding that effect it may be a case of improving one aspect at the cost of another, like if the framerate drops from 45fps to 20fps due to the added stress of properly rendered motion blur, then maybe the original 45fps without motion blur may have looked better before.
Anywhoo, this question has been discussed many times here, and while alot of people think they have THE answer, there really isn't just one single answer for all scenarios/games.
- Nov 13, 2006
- 6,381
- 290
- 38,240
TabrisDarkPeace
Distinguished
- Jan 11, 2006
- 1,378
- 0
- 19,280
Oh these are the answers: :lol:
Recommend Firefox or MSIE v7 for easy 1:1 zooming.
While most players were on 1536/256, same ISP, and similar distance from the data centre, a different configuration can knock off 15+ ms of 'game ping'*.
*(Not to be confused with network ping, as one includes frame draw delays, etc while the other is for a packet of size 'x' bytes to get to/from two points).
8) - Tabris😀arkPeace
Recommend Firefox or MSIE v7 for easy 1:1 zooming.
While most players were on 1536/256, same ISP, and similar distance from the data centre, a different configuration can knock off 15+ ms of 'game ping'*.
*(Not to be confused with network ping, as one includes frame draw delays, etc while the other is for a packet of size 'x' bytes to get to/from two points).
8) - Tabris😀arkPeace
TheGreatGrapeApe
Champion
- Feb 18, 2003
- 20,040
- 0
- 50,960
LOL!
Yeah, but that's a different question all together.
PING rate is different from single player screen drawing. In online gaming with high ping latency your opponent moves long before you see them move, and in most cases, you're dead before you see yourself being shot at.
It's like trying to play a video game on a PC capture card that introduces a 1 second delay into the picture, absolutely terrible to watch, especially for driving games, sports games and such.
BTW, anyone with a ping rate as high as that Steve guy (300+ms) should be bumped from the server, although he's mostly hurting himself, I hate when the games get laggy and yet my ping rate is around 50ms, but it's because of a few 200+ players that everyone gets a bit slow.
Anywhooo, time for sleep or else my response time in the morning will be affected. :lol:
Yeah, but that's a different question all together.
PING rate is different from single player screen drawing. In online gaming with high ping latency your opponent moves long before you see them move, and in most cases, you're dead before you see yourself being shot at.
It's like trying to play a video game on a PC capture card that introduces a 1 second delay into the picture, absolutely terrible to watch, especially for driving games, sports games and such.
BTW, anyone with a ping rate as high as that Steve guy (300+ms) should be bumped from the server, although he's mostly hurting himself, I hate when the games get laggy and yet my ping rate is around 50ms, but it's because of a few 200+ players that everyone gets a bit slow.
Anywhooo, time for sleep or else my response time in the morning will be affected. :lol:
TabrisDarkPeace
Distinguished
- Jan 11, 2006
- 1,378
- 0
- 19,280
Network ping is just normal PING:C:\>PING www.internode.on.net
Pinging www.internode.on.net [203.16.214.17] with 32 bytes of data:
Reply from 203.16.214.17: bytes=32 time=26ms TTL=57
Reply from 203.16.214.17: bytes=32 time=27ms TTL=57
Reply from 203.16.214.17: bytes=32 time=27ms TTL=57
Reply from 203.16.214.17: bytes=32 time=26ms TTL=57
Ping statistics for 203.16.214.17:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 26ms, Maximum = 27ms, Average = 26ms
C:\>PING www.internode.on.net -l 128
Pinging www.internode.on.net [203.16.214.17] with 128 bytes of data:
Reply from 203.16.214.17: bytes=128 time=31ms TTL=57
Reply from 203.16.214.17: bytes=128 time=29ms TTL=57
Reply from 203.16.214.17: bytes=128 time=31ms TTL=57
Reply from 203.16.214.17: bytes=128 time=31ms TTL=57
Ping statistics for 203.16.214.17:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 29ms, Maximum = 31ms, Average = 30ms
C:\>PING www.internode.on.net -l 512
Pinging www.internode.on.net [203.16.214.17] with 512 bytes of data:
Reply from 203.16.214.17: bytes=512 time=46ms TTL=57
Reply from 203.16.214.17: bytes=512 time=46ms TTL=57
Reply from 203.16.214.17: bytes=512 time=47ms TTL=57
Reply from 203.16.214.17: bytes=512 time=47ms TTL=57
Ping statistics for 203.16.214.17:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 46ms, Maximum = 47ms, Average = 46ms
C:\>PING www.internode.on.net -l 2048
Pinging www.internode.on.net [203.16.214.17] with 2048 bytes of data:
Reply from 203.16.214.17: bytes=2048 time=112ms TTL=57
Reply from 203.16.214.17: bytes=2048 time=111ms TTL=57
Reply from 203.16.214.17: bytes=2048 time=113ms TTL=57
Reply from 203.16.214.17: bytes=2048 time=114ms TTL=57
Ping statistics for 203.16.214.17:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 111ms, Maximum = 114ms, Average = 112ms
PING will always differ with packet sized used, less so on 100/100 (up/downstream) Mbps full-duplex links or faster, and NETWORK PING does not incorperate any additional latencies added by a games multiplayer component, as a game is just a giant loop, with heaps of sub loops sometimes spun off as seperate threads.
For example on a 100/100 Mbps link, the delta between larger and smaller packets becomes much closer:
C:\>PING 192.168.0.20
Pinging 192.168.0.20 with 32 bytes of data:
Reply from 192.168.0.20: bytes=32 time<1ms TTL=30
Reply from 192.168.0.20: bytes=32 time<1ms TTL=30
Reply from 192.168.0.20: bytes=32 time<1ms TTL=30
Reply from 192.168.0.20: bytes=32 time=1ms TTL=30
Ping statistics for 192.168.0.20:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
C:\>PING 192.168.0.20 -l 512
Pinging 192.168.0.20 with 512 bytes of data:
Reply from 192.168.0.20: bytes=512 time=1ms TTL=30
Reply from 192.168.0.20: bytes=512 time=1ms TTL=30
Reply from 192.168.0.20: bytes=512 time=1ms TTL=30
Reply from 192.168.0.20: bytes=512 time=1ms TTL=30
Ping statistics for 192.168.0.20:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms
GAME PING by comparison includes many extra lines of code not strictly related to the universally accepted 'PING'
Games typically use UDP too.
100 identical pings tell you very little, except about fluxuations in ping over time (as it'll take ages)
10 pings of one size, and 10 pings of another size (20 in total) typically tell one much more.
8) - Tabris😀arkPeace
When comparing pings, do not compare PING to GAME PING, as packets used in games will vary from 64 to 256+ bytes in size, while standard 'network' PINGs are 32 bytes.
It is for these, and many others reasons, that the PINGs from one application (eg: Half-Life 2) can not be compared to another application (eg: the OS PING utility).
But getting back onto the subject at hand, look at the 2 screenshots above, notice my 'game ping' is a good 20 ms below everyone elses, despite having almost idential hardware (from router to ISP, to Data Centre), by going back to stock settings and similar video card to everyone else my game ping returns to 50 - 55 ms. The 2 above screenshots were taken from a quad-core (2 x dual-core) Opteron 270 on a Tyan K8WE with a Radeon X800 XL, while other players were using GeForce 6600 GT and Radeon X700 (Pro) cards.
This (the fact that system + video hardware alone can impact pings in games*) is one reason why gamers desire a higher frame rate.
*(but not PING from the command prompt).
Pinging www.internode.on.net [203.16.214.17] with 32 bytes of data:
Reply from 203.16.214.17: bytes=32 time=26ms TTL=57
Reply from 203.16.214.17: bytes=32 time=27ms TTL=57
Reply from 203.16.214.17: bytes=32 time=27ms TTL=57
Reply from 203.16.214.17: bytes=32 time=26ms TTL=57
Ping statistics for 203.16.214.17:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 26ms, Maximum = 27ms, Average = 26ms
C:\>PING www.internode.on.net -l 128
Pinging www.internode.on.net [203.16.214.17] with 128 bytes of data:
Reply from 203.16.214.17: bytes=128 time=31ms TTL=57
Reply from 203.16.214.17: bytes=128 time=29ms TTL=57
Reply from 203.16.214.17: bytes=128 time=31ms TTL=57
Reply from 203.16.214.17: bytes=128 time=31ms TTL=57
Ping statistics for 203.16.214.17:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 29ms, Maximum = 31ms, Average = 30ms
C:\>PING www.internode.on.net -l 512
Pinging www.internode.on.net [203.16.214.17] with 512 bytes of data:
Reply from 203.16.214.17: bytes=512 time=46ms TTL=57
Reply from 203.16.214.17: bytes=512 time=46ms TTL=57
Reply from 203.16.214.17: bytes=512 time=47ms TTL=57
Reply from 203.16.214.17: bytes=512 time=47ms TTL=57
Ping statistics for 203.16.214.17:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 46ms, Maximum = 47ms, Average = 46ms
C:\>PING www.internode.on.net -l 2048
Pinging www.internode.on.net [203.16.214.17] with 2048 bytes of data:
Reply from 203.16.214.17: bytes=2048 time=112ms TTL=57
Reply from 203.16.214.17: bytes=2048 time=111ms TTL=57
Reply from 203.16.214.17: bytes=2048 time=113ms TTL=57
Reply from 203.16.214.17: bytes=2048 time=114ms TTL=57
Ping statistics for 203.16.214.17:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 111ms, Maximum = 114ms, Average = 112ms
PING will always differ with packet sized used, less so on 100/100 (up/downstream) Mbps full-duplex links or faster, and NETWORK PING does not incorperate any additional latencies added by a games multiplayer component, as a game is just a giant loop, with heaps of sub loops sometimes spun off as seperate threads.
For example on a 100/100 Mbps link, the delta between larger and smaller packets becomes much closer:
C:\>PING 192.168.0.20
Pinging 192.168.0.20 with 32 bytes of data:
Reply from 192.168.0.20: bytes=32 time<1ms TTL=30
Reply from 192.168.0.20: bytes=32 time<1ms TTL=30
Reply from 192.168.0.20: bytes=32 time<1ms TTL=30
Reply from 192.168.0.20: bytes=32 time=1ms TTL=30
Ping statistics for 192.168.0.20:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
C:\>PING 192.168.0.20 -l 512
Pinging 192.168.0.20 with 512 bytes of data:
Reply from 192.168.0.20: bytes=512 time=1ms TTL=30
Reply from 192.168.0.20: bytes=512 time=1ms TTL=30
Reply from 192.168.0.20: bytes=512 time=1ms TTL=30
Reply from 192.168.0.20: bytes=512 time=1ms TTL=30
Ping statistics for 192.168.0.20:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms
GAME PING by comparison includes many extra lines of code not strictly related to the universally accepted 'PING'
Games typically use UDP too.
100 identical pings tell you very little, except about fluxuations in ping over time (as it'll take ages)
10 pings of one size, and 10 pings of another size (20 in total) typically tell one much more.
8) - Tabris😀arkPeace
When comparing pings, do not compare PING to GAME PING, as packets used in games will vary from 64 to 256+ bytes in size, while standard 'network' PINGs are 32 bytes.
It is for these, and many others reasons, that the PINGs from one application (eg: Half-Life 2) can not be compared to another application (eg: the OS PING utility).
But getting back onto the subject at hand, look at the 2 screenshots above, notice my 'game ping' is a good 20 ms below everyone elses, despite having almost idential hardware (from router to ISP, to Data Centre), by going back to stock settings and similar video card to everyone else my game ping returns to 50 - 55 ms. The 2 above screenshots were taken from a quad-core (2 x dual-core) Opteron 270 on a Tyan K8WE with a Radeon X800 XL, while other players were using GeForce 6600 GT and Radeon X700 (Pro) cards.
This (the fact that system + video hardware alone can impact pings in games*) is one reason why gamers desire a higher frame rate.
*(but not PING from the command prompt).
Blacken
Distinguished
- Aug 27, 2004
- 641
- 0
- 18,980
Thats true. When a game goes from liquid to jumpy unexpectedly, it can screw your gameplay up where-as having a constant. You get accustomed to it. Though at 30, I'd be forced to use vsync as 'ripping' becomes very noticable.
Gotta tell you though, there's nothing like playing a first person shooter @ 75fps. Realism.
The ping to fps ratio is 1ms/100fps or 100/1000. 100fps can give you a theoretical ping of 0 (yet, you'd need to be on the same network to achive that) where as 70fps give you 30ms, 50fps/50ms. 23fps/77ms.
Gotta tell you though, there's nothing like playing a first person shooter @ 75fps. Realism.
The ping to fps ratio is 1ms/100fps or 100/1000. 100fps can give you a theoretical ping of 0 (yet, you'd need to be on the same network to achive that) where as 70fps give you 30ms, 50fps/50ms. 23fps/77ms.
TRENDING THREADS
-
-
-
-
Discussion What's your favourite video game you've been playing?- Started by amdfangirl
- Replies: 4K
-
News Introducing the Tom’s Hardware Premium Beta: Exclusive content for members
- Started by Admin
- Replies: 43
-
-
Facebook
Twitter
Instagram