- Joined
- Oct 7, 2000
- Messages
- 75,967
something like this?
https://blurbusters.com/crt-simulation-in-a-gpu-shader-looks-better-than-bfi/
https://blurbusters.com/crt-simulation-in-a-gpu-shader-looks-better-than-bfi/
![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
-
Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.
Would a modern CRT make any sense?
- Thread starter wandplus
- Start date
- Joined
- May 5, 2006
- Messages
- 5,785
HDR is a "brighter range of colors" , or "brighter color volume ceiling". HDR has a much higher and wider color volume ceiling than SDR (Standard Dynamic Range). SDR is around 100 to 150 nit technically, and up to maybe 300 nit functionally for modern screens in bright room usage.
What you'd get out of an aged fw900 crt now, without compromising parameters, even after refreshing (according to google) :
"
FW900’s maximum brightness remains relatively uniform across the screen: [1, 2]
Usage Context in 2026:
Because these monitors are now decades old, actual performance depends entirely on the cathode tube's wear. Degraded tubes or units needing G2 voltage/WinDAS calibration often max out lower (60-80 nits). To preserve the remaining lifespan of the components, most users calibrate to about 80–100 nits and use the monitor in dim ambient lighting. [1, 2, 3, 4, 5]
"
HDR color
Modern screens have an enormously larger palette of colors that provides much more details in colored objects, details that aren't even there otherwise, and provides much more contrast with the color-brightness range. I think people diminish the impact of HDR when they just say "it's brighter" as if it was SDR's colors remaining relative to each other and just being ramped up a little higher. I don't know if people imply that intentionally or not, or are in some cases just not being very knowledgeable about how HDR works, or maybe just assuming people know what they mean, - but the end result when people just say "brighter" is that it often comes off as a major downplaying to me. CRT doesn't even have HDR brightness and contrast, and it is at 16.7 million colors instead of 1.07 billion colors of a modern 10-bit HDR gaming display. A 12-bit capable display would be able to show 68.7 billion colors.
. . . .
I think the fw900 crt gets max around 2560x1600 at 75hz, so 75 fpsHz of motion definition/pathing articulation/smoothness at a sub 4k resolution on a small screen size. Even if it gets really good motion clarity/blur reduction, that's another big tradeoff. Depending on the age of the phosphors, it might get 1ms to 3ms persistence.
Every time you double the Hz (on an oled), you cut the sample-and-hold "persistence" blur by half.
If you start off with a 100fps native before you amplify the frame rate x5 or 10x , your base is ~ 10ms frames in regard to when you see new (native) motion states and have a window to react/see your reaction (locally). It would also be 1/2 crt level blur at ~ 2ms when amplified x5 to 500 fpsHz on a 500hz capable OLED, which is still quite good, and when amplified to 1000fpsHz on a 1000Hz capable OLED it would be 1ms persistence/blur which is comparable to a crt (especially aged phosphors ones that remain) , so you wouldn't need to emulate anything as far as reducing blur to crt levels once you hit 1000fpsHz, though you might want to emulate the crt "look" for low bit arcade games or something, but you could get that with filters more or less instead I think, (and that is kind of niche, anyway).
image from: Blur Busters Law: The Amazing Journey To Future 1000Hz Displays
. . . . . . .
Amplifying a strong base native frame rate like 100fps solid would:
- keep frame lag reasonable for most not-extremely-competitive games at ~ 10ms , which is where 120Hz OLED gaming TVs input lag were at for quite some time, and if not competing in a LAN gaming competition, online gaming server dynamics reduces how meaningful extreme local fpsHz is vs the server relationship physics and tick rates, since you have a "displacer beast" type effect on locations/time, plus your local game is simulating action state frames while waiting on the server's low tick rate updates of interpolated results, among other things. Nvidia has some lag reducing tech tricks, too, as someone mentioned. The version I saw was mainly for sideways movement "doom" like shooters panning left and right, where it was using projection type guesswork to reduce input lag (which appeared to be similar to some of the tech VR headsets use).
- that 100fps native x5 or x10 would be keeping a solid amplified frame rate of 500 or 1000, so no VRR would be necessary. The frame durations would all be the same (2ms or 1ms), and there would also be no OLED VRR flicker.
- 100fps solid would provide a smaller gap of time that AI/machine learning would have to guess between in order to "tween" manufactured frames. The higher the native frame rate and the higher the native resolution of the screen and the resolution you are amplifying from (1440p upscaled via DLSS quality on a 4k screen, or nearly 4k (4096x2034) upscaled via DLSS quality on a 6k screen), the higher the % accuracy of the manufactured frames will be. In other words, the less that has changed between frames due to having a higher frequency and finer detail, the better it will end up. "you can't get blood from a stone", at least not without worse results (bad input lag, more artifacting, + more obvious artifacts with lower resolutions). I recently saw someone saying something like : "dlss+MultiFrameGen makes good frame rate gaming better, it doesn't make bad frame rate gaming good".
.
Last edited:
Yes exactly - mprt from electron beam / phosphor fade simulation is very cool, and I have tried it on my 240hz oled. With 480hz you can see the improvements and at 960 it should be perfect.
The beam tracing / per pixel impulse based method of crt illumination is what gives CRTs such sharp motion clarity at lower refresh rates (no sample and hold effect) and recreating this on an oled using per pixel phosphor fade has the same exact “feel” as CRTs. It’s not about motion interpolation and making up data, it’s using an accurate simulation to solve the psycho-visual effects of seeing the same lit pixels fixed in space over an extended period of time. Two different approaches, but I am definitely looking forward to this method as an alternative to frame interpolation alone at high frame rates. It’s a very good use of that high frame rate possible on upcoming Oleds.
- Joined
- Jun 7, 2007
- Messages
- 13,738
I know other technical problems would be introduced, but I wonder if dual gun CRTs would have found success in TVs/monitors if the tech had continued to advance.
Theoretically, it could have allowed almost double the refresh rate, at the cost of signal (and beam) complexity.
https://vintagetek.org/dual-beam-crt-guns/
Theoretically, it could have allowed almost double the refresh rate, at the cost of signal (and beam) complexity.
https://vintagetek.org/dual-beam-crt-guns/
- Joined
- May 5, 2006
- Messages
- 5,785
.
That is interesting, but it points out that - yes the refresh rate is poor on crts. Blur reduction from higher hz is part of the gain for LCD and OLED, but the other gain is motion definition/pathing articulation/smoothness (and even animation cycle frames) from higher fpsHz. That aspect overall probably has appreciable gains to at least 500fpsHz if not higher.
warning: photo "gallery" inside this quote
.
1000 fpsHZ using brute force multiFrameGen is the goal. 1000 fpsHz would be crt clarity then, without using crt emulation, bfi, partial scan, etc.. Before we can achieve that (1000 Hz OLEDs), having ~ 500 fpsHZ solid at 4k, 4k+ would be only 2ms / 2pixel persistence which would very close, even if not pristine yet.
1000 fpsHz once available will be game over, at least for crt persistence / image clarity comparisons, and that without any (especially HDR) image brightness reduction, flicker (conciously visible or not can cause fatigue over time), etc.
"According to Blur Busters, eliminating motion blur on a non-strobed LCD or OLED (sample-and-hold) display requires reaching 1000 Hz natively. [1, 2, 3]
The transition thresholds define this path to perfect CRT-level clarity: [1]
-------------------------------------
If you have post DLSS quality boosting your native frame rate to 133fps (7.5ms), after applying MultiFrameGen x4 you'd end up with 505 fpsHz (average, not solid).
A few versions with realistic numbers below :
That is interesting, but it points out that - yes the refresh rate is poor on crts. Blur reduction from higher hz is part of the gain for LCD and OLED, but the other gain is motion definition/pathing articulation/smoothness (and even animation cycle frames) from higher fpsHz. That aspect overall probably has appreciable gains to at least 500fpsHz if not higher.
warning: photo "gallery" inside this quote
.
1000 fpsHZ using brute force multiFrameGen is the goal. 1000 fpsHz would be crt clarity then, without using crt emulation, bfi, partial scan, etc.. Before we can achieve that (1000 Hz OLEDs), having ~ 500 fpsHZ solid at 4k, 4k+ would be only 2ms / 2pixel persistence which would very close, even if not pristine yet.
1000 fpsHz once available will be game over, at least for crt persistence / image clarity comparisons, and that without any (especially HDR) image brightness reduction, flicker (conciously visible or not can cause fatigue over time), etc.
"According to Blur Busters, eliminating motion blur on a non-strobed LCD or OLED (sample-and-hold) display requires reaching 1000 Hz natively. [1, 2, 3]
The transition thresholds define this path to perfect CRT-level clarity: [1]
- 60 Hz: Standard non-strobed sample-and-hold display; maximum motion blur.
- 120 Hz to 240 Hz: Reduces motion blur by roughly 50% to 75% compared to 60 Hz.
- 480 Hz: Considered the minimum threshold to simulate near-perfect, blur-free motion without flickering.
- 1000 Hz: The mathematical equivalent to human-perceived CRT motion clarity without any strobing or Black Frame Insertion (BFI)
-------------------------------------
If you have post DLSS quality boosting your native frame rate to 133fps (7.5ms), after applying MultiFrameGen x4 you'd end up with 505 fpsHz (average, not solid).
A few versions with realistic numbers below :
.
Last edited:
XoR_
2[H]4U
- Joined
- Jan 18, 2016
- Messages
- 2,137
After carefully thinking about this I came to the conclusion that the best summary to what FG is is single word: SCAM
It would not be and might have its use cases like these suggested by some people if it was reprojection. Otherwise trading latency for fake frames is just... ridiculous.
Like why would I even like such smooth motion?
Why wouldn't I like more cinematic look?
CRT doesn't make image overly smooth in an artificial way but makes motion sharp in an artificial way. That is something completely different. Incomparable.
It would not be and might have its use cases like these suggested by some people if it was reprojection. Otherwise trading latency for fake frames is just... ridiculous.
Like why would I even like such smooth motion?
Why wouldn't I like more cinematic look?
CRT doesn't make image overly smooth in an artificial way but makes motion sharp in an artificial way. That is something completely different. Incomparable.
Last edited:
- Joined
- Aug 18, 2006
- Messages
- 11,473
Not to mention you need even more hardware to support this. Meanwhile CRT just makes clear motion naturally.
Reject modernity. Embrace tradition.
- Joined
- May 5, 2006
- Messages
- 5,785
. .
XoR_
2[H]4U
- Joined
- Jan 18, 2016
- Messages
- 2,137
I wouldn't call strobing "natural".
Also needing more hardware... not an issue if we have hardware.
I just don't like these fake frames because the fake frames that we got are pretty bad because they make games more laggy.
When Oculus did frame gen I loved it because it solved the main issue. When my PC wouldn't keep up producing 90 frames per second I would get game running 45 fps and there would be more lag but I wouldn't feel that lag at all because what I interacted with and which was used for e.g. aiming would run at 90fps.
If we had proper reprojection frame gen and it would eliminate perceived latency instead of increasing it then flock yeah, let's all get excited about it.
And even then I wouldn't say it would be any reason why we don't need or want strobed displays or even that we should use it because it is always better to have more fps.
Because it looks more realistic? Real life doesn't have a frame rate, if you follow a moving object with your eyes, it is clear and smooth. Well, get a high enough frame rate and that is what it looks like on a screen too. When you get in the 1000fps range, you are starting to talk completely imperceptible frames, the motion will just be smooth.
That sounds like the "30 fps is enough for anyone" argument. Deciding that low FPS is the "right" was of doing things and then that we should use old tech to make it look less blurry. I mean if you want cinematic gaming I guess you can cap your framerate at 24fps, play on CRT or something else with strobing (actual film projectors generally strobe the whole image with a shutter at 72hz, not a line-by-line drawing like a CRT) and be happy.
You'll have to forgive me, and most of the rest of the world, if we don't want to join you though and wan tot enjoy high FPS gaming, and even just high FPS desktop.
XoR_
2[H]4U
- Joined
- Jan 18, 2016
- Messages
- 2,137
If frame rate was something you chose in separation to anything else or something only limited by monitor then there is rarely any point to not using highest fps you can use.
In reality fps is not free lunch and FG is terrible compromise which causes massive input lag. In this case its better to just forego it and play with 'cinematic look'.
Of course even 120fps is more cinematic in how it looks compared to much higher fps.
In reality fps is not free lunch and FG is terrible compromise which causes massive input lag. In this case its better to just forego it and play with 'cinematic look'.
Of course even 120fps is more cinematic in how it looks compared to much higher fps.
- Joined
- May 5, 2006
- Messages
- 5,785
multi frame gen lag is directly tied to your native frame rate. If you have a healthy frame rate on a higher resolution screen, dlss+multiFrameGen will work better, and cleaner, and with less effective lag. 100fps minimum (native) would be 10ms, which is what gaming tvs had at first, which is not "laggy".
. . . . . .
Online gaming servers, rather than LAN tournaments, have 128 tick rate at best, which is 7.8 ms per tick from server and the rate you send your local action state to the server. Once in awhile, a tick or a frame can arrive mid-tick or mid-frame on either end of the system though, causing an additional frame or tick delay when that happens.
In online gaming, for example on an optimized game - as long as you keep over 128fpsHz native as your minimum (post dlss upscale but pre-mFrameGen) - you will get something like 72ms of online "temporal gap". That "Temporal gap" thing in games is most obvious in things like "rubberbanding" at worst (happens more often on lower tick servers), and it's also experienced as, and more commonly known as, "peeker's advantage". It can also have the side effect of high fire-rate weapons in online games delivering it's high fire rate bullets packed all together as a "super bullet".
By comparison, if you had 60fpsHz solid, you'd get 100ms of that temporal gap. That would be worse throughout if those 128fpsHz or 60fpsHz were averages instead of minimums. It would also be worse for everyone when the tick rate of the server is worse than 128, which surprisingly many still are, some a lot worse.
Online gaming is not a 1:1 relationship to your local simulation. It's always got a temporal gap, it's just a matter of by how much and how noticeable that temporal gap is. It's sort of a "displacer beast", where what you are aiming at on your screen isn't even necessarily exactly where you think it is at any given time, as far as the server is concerned. .
. . . .
To get that optimal 128fpsHz minimum for playing on a 128 tick server :
If you are still using VRR rather than setting a cutoff at your low end, then you might have a graph something like
(100 to 110 microstutter .1%) ... 128fpsHz lows <<<<..(150 to 170 fps) 160fpsHz average.............>>> 190 to 200 fpsHz (looking at walls, small rooms, etc)
( 10ms frame render lag) ... 7.8ms lows <<<<<..................................6.25 ms average............. >>>> 5.26ms to 5ms
. . . . .
In regard to online gaming, if you are that worried about input lag, then you should be worried about that server temporal gap and keeping your frame rate around 160fps native average (post DLSS upscale, but pre-multi-framegen) already for a 128 tick server. Therefore your dlss+MultiFrameGen render time lag should be pretty small as shown in ranges listed in the previous few lines above this.
Where people get obnoxious frame render lag from DLSS+mFrameGen is when they are trying to make a low native frame rate " a good number" (using framegen beyond what dlss can do), instead of making a good frame rate better. (and even with powerful gpus on certain games, keeping path tracing on, esp. at 4k rez) .
. . .
For local adventure games, and even very challenging souls/souls-like games where timing is critical - you could probably do 120 to 140 fps native and have decently low frame render lag, and appreciable motion definition gains.
If you had post quality DLSS upscale frame rate of 120 (8.3ms). to 140 fps (7.14ms), you could multiply your 100fps (10ms) minimum x5 to 500fpsHz, or perhaps in the future x10 to 1000 fpsHz. Then no VRR necessary, 2ms persistence at 500fpsHZ, 1ms persistence (crt equivalent) at 1000 fpsHz. That, or you could keep VRR on, and get the benefits of the whole graph's frame render time variance being at that 8.3ms to 7.14ms average.
. . . . .
regarding something like a fw900 CRT :
Say you are running your Sony FW900 at 2304x1440 @ 80Hz, (or its optimal recommended widescreen resolution 1920x1200 at 85Hz)
If you want a sort -of modern rez, you are at 2304x1440 at 80fpsHz max, so you are much worse than the smallest "peeker's advantage" temporal gap that you could get on a 128tick online gaming server if you had a a screen that did over 128hz, like a 144hz screen or higher, (when you are keeping over 128fps as your lows on such a high hz screen, for example).
Your motion definition ~ pathing articulation/shaping, smoothness of motion, and even animation cycle states shown will also be lower, limited to 80fps, where you can obviously see appreciable gains at 120 - 240, and really I think likely up until at least 500fpsHz.
Worth noting that your local game "simulation" is not waiting around for the next tick, either... it's predicting and simulatiing frames of action states until the next adjudicated tick from the ultimate authority of the server hits, which may retcon reality some amount, depending on how it all resolves, and also the biased flavor of the server code. The more "behind" the tick rate you are, the more difference your local simulation might have to predict and "make up", so the more drawing outside of the lines it might be.
Google result:
. .
This is the peekers advantage / "temporal gap" breakdown again, which still happens ~ 72ms even when a best case scenario of over 128fps on a 128 tick server. Note that this assumes solid frame rate, so where it's an average, those ms will swing to the worse a bit throughout the graph when the fps is in the zones beneath 128.
. . . . . .
Online gaming servers, rather than LAN tournaments, have 128 tick rate at best, which is 7.8 ms per tick from server and the rate you send your local action state to the server. Once in awhile, a tick or a frame can arrive mid-tick or mid-frame on either end of the system though, causing an additional frame or tick delay when that happens.
In online gaming, for example on an optimized game - as long as you keep over 128fpsHz native as your minimum (post dlss upscale but pre-mFrameGen) - you will get something like 72ms of online "temporal gap". That "Temporal gap" thing in games is most obvious in things like "rubberbanding" at worst (happens more often on lower tick servers), and it's also experienced as, and more commonly known as, "peeker's advantage". It can also have the side effect of high fire-rate weapons in online games delivering it's high fire rate bullets packed all together as a "super bullet".
By comparison, if you had 60fpsHz solid, you'd get 100ms of that temporal gap. That would be worse throughout if those 128fpsHz or 60fpsHz were averages instead of minimums. It would also be worse for everyone when the tick rate of the server is worse than 128, which surprisingly many still are, some a lot worse.
Online gaming is not a 1:1 relationship to your local simulation. It's always got a temporal gap, it's just a matter of by how much and how noticeable that temporal gap is. It's sort of a "displacer beast", where what you are aiming at on your screen isn't even necessarily exactly where you think it is at any given time, as far as the server is concerned. .
. . . .
To get that optimal 128fpsHz minimum for playing on a 128 tick server :
To realistically maintain a 128 FPS minimum, your hardware should be pushing an average frame rate of 150 to 170 FPS (roughly 15-30% higher than your target). This headroom ensures that intense visual effects, crowded servers, or sudden frame drops do not push your performance below the crucial 128 FPS threshold.
Achieving this level of performance requires a capable setup, especially to prevent "1% lows" (the lowest 1% of frames measured during gameplay) from dipping below your target.
Why Target 128 FPS?
- High-Refresh Gaming: 128 FPS perfectly complements 144Hz monitors, keeping gameplay fluid.
- Engine-Specific Ticks: Many competitive titles (such as Apex Legends or VALORANT) and custom servers run on tick rates where syncing your FPS to multiples of 64 or 128 provides tighter, more responsive registration.
If you are still using VRR rather than setting a cutoff at your low end, then you might have a graph something like
(100 to 110 microstutter .1%) ... 128fpsHz lows <<<<..(150 to 170 fps) 160fpsHz average.............>>> 190 to 200 fpsHz (looking at walls, small rooms, etc)
( 10ms frame render lag) ... 7.8ms lows <<<<<..................................6.25 ms average............. >>>> 5.26ms to 5ms
. . . . .
In regard to online gaming, if you are that worried about input lag, then you should be worried about that server temporal gap and keeping your frame rate around 160fps native average (post DLSS upscale, but pre-multi-framegen) already for a 128 tick server. Therefore your dlss+MultiFrameGen render time lag should be pretty small as shown in ranges listed in the previous few lines above this.
Where people get obnoxious frame render lag from DLSS+mFrameGen is when they are trying to make a low native frame rate " a good number" (using framegen beyond what dlss can do), instead of making a good frame rate better. (and even with powerful gpus on certain games, keeping path tracing on, esp. at 4k rez) .
. . .
For local adventure games, and even very challenging souls/souls-like games where timing is critical - you could probably do 120 to 140 fps native and have decently low frame render lag, and appreciable motion definition gains.
If you had post quality DLSS upscale frame rate of 120 (8.3ms). to 140 fps (7.14ms), you could multiply your 100fps (10ms) minimum x5 to 500fpsHz, or perhaps in the future x10 to 1000 fpsHz. Then no VRR necessary, 2ms persistence at 500fpsHZ, 1ms persistence (crt equivalent) at 1000 fpsHz. That, or you could keep VRR on, and get the benefits of the whole graph's frame render time variance being at that 8.3ms to 7.14ms average.
. . . . .
regarding something like a fw900 CRT :
Say you are running your Sony FW900 at 2304x1440 @ 80Hz, (or its optimal recommended widescreen resolution 1920x1200 at 85Hz)
If you want a sort -of modern rez, you are at 2304x1440 at 80fpsHz max, so you are much worse than the smallest "peeker's advantage" temporal gap that you could get on a 128tick online gaming server if you had a a screen that did over 128hz, like a 144hz screen or higher, (when you are keeping over 128fps as your lows on such a high hz screen, for example).
Your motion definition ~ pathing articulation/shaping, smoothness of motion, and even animation cycle states shown will also be lower, limited to 80fps, where you can obviously see appreciable gains at 120 - 240, and really I think likely up until at least 500fpsHz.
Worth noting that your local game "simulation" is not waiting around for the next tick, either... it's predicting and simulatiing frames of action states until the next adjudicated tick from the ultimate authority of the server hits, which may retcon reality some amount, depending on how it all resolves, and also the biased flavor of the server code. The more "behind" the tick rate you are, the more difference your local simulation might have to predict and "make up", so the more drawing outside of the lines it might be.
Google result:
╔════════════════════════════════════════════════╗
║ SERVER STATE (128-Tick Baseline) ║
║ Updates game data every 7.81 milliseconds ║
╚════════════════════════════════════════════════╝
│
┌────────────────────────┼──────────────────────────────┐
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ 60 FPS Solid │ │ 80 FPS Solid │ │ 128 FPS Solid │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │
▼ ▼ ▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ Render: 16.67 ms │ │ │ Render: 12.50 ms │ │ Render: 7.81 ms │
└──────────────────┘ └──────────────────┘ └──────────────────┘
Core Metrics Comparison
Metric 60 FPS Solid 80 FPS Solid 128 FPS Solid Frame Delivery Time 16.67 ms 12.50 ms 7.81 ms Ticks per Frame ~2.13 server ticks ~1.60 server ticks Exactly 1 server tick Interpolation Window Heavy (Needs 2+ ticks) Moderate (Ticks drift) None (1:1 alignment) Max Visual Delay ~17 ms behind server ~13 ms behind server ~8 ms behind server
The "Outside the Lines" Effect
60 FPS Solid: Heavy Smearing
- The State: Your PC throws away more than half of the server's updates.
- The Visuals: Heavy simulation. The client constantly guesses positions across two whole ticks.
- The Result: You are drawing far outside the server lines. You see a smoothed path of where the enemy was, missing their sharpest direction changes.
80 FPS Solid: Jagged Drift
- The State: The math is uneven (\(128 \div 80 = 1.6\)).
- The Visuals: Unbalanced simulation. Frame 1 aligns with a tick, Frame 2 drops between ticks, Frame 3 lands on a completely different tick interval.
- The Result: You draw closer to the lines, but the line thickness fluctuates. This creates micro-stuttering in visual information freshness.
128 FPS Solid: Perfect Tracing
- The State: Absolute harmony (\(128 \div 128 = 1\)).
- The Visuals: Zero simulation. Every single frame displays a brand-new, unique server update packet.
- The Result: You draw perfectly inside the lines. What you see is exactly what the server calculates.
Gameplay Impact
Input Latency
- 60 FPS: Your clicks can wait up to 16.67 ms to register on your screen before sending to the server.
- 80 FPS: Latency drops to 12.50 ms. It feels snappier, but commands still bottle up between ticks.
- 128 FPS: Minimum possible latency (7.81 ms). Your mouse inputs slice cleanly into the server's update windows.
Hit Registration & "Ghost Misses"
- 60 FPS: High risk. You click an enemy head. On your screen, it aligns. On the server, that player already changed directions 8 ms ago. The server rejects your shot.
- 80 FPS: Medium risk. The desync window is smaller, but uneven frame times still cause occasional phantom misses on fast-moving targets.
- 128 FPS: Zero risk. If your crosshair is on the pixel, the server registers the hit. No spatial desync occurs.
. .
This is the peekers advantage / "temporal gap" breakdown again, which still happens ~ 72ms even when a best case scenario of over 128fps on a 128 tick server. Note that this assumes solid frame rate, so where it's an average, those ms will swing to the worse a bit throughout the graph when the fps is in the zones beneath 128.
╔═════════════════════════════════════════════════╗
║ AGGRESSIVE PEEKER APPROACHES ║
║ Clears the corner on a 128-Tick Server ║
╚═════════════════════════════════════════════════╝
│
┌───────────────────────────┼──────────────────────┐
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ 60 FPS Holde r │ │ 80 FPS Holder │ │ 128 FPS Holder │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │
▼ ▼ ▼
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ Total Delay: │ │ Total Delay: │ │ Total Delay: │
│ ~100 ms │ │ ~85 ms │ │ ~72 ms │
└────────────────┘ └────────────────┘ └────────────────┘
This breakdown assumes a pristine network environment where both the peeker and the angle-holder have an identical 20 ms ping (10 ms one-way).
Delay Component 60 FPS Holder 80 FPS Holder 128 FPS Holder Network Transit (Both Pings) 20.00 ms 20.00 ms 20.00 ms Server Processing (1 Tick) 7.81 ms 7.81 ms 7.81 ms Client Frame Time (GPU) 16.67 ms 12.50 ms 7.81 ms Network Interpolation Buffer 23.43 ms (3 Ticks) 15.62 ms (2 Ticks) 7.81 ms (1 Tick) Monitor Scan-Out & Input Lag ~32.00 ms ~29.00 ms ~28.00 ms Total Peeker's Advantage ~100 ms ~85 ms ~72 ms
Last edited:
- Joined
- May 5, 2006
- Messages
- 5,785
If interested in further reading, here are more details about what I called the "termporal gap", etc., explained again in detail by google. I find this kind of thing an interesting read, personally.
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
| Metric [1, 2, 3, 4, 5, 6, 7] | 60 FPS Client | 80 FPS Client | 128 FPS Client | LAN Tournament | Single Player |
|---|---|---|---|---|---|
| Server Desync Window | ~100ms behind | ~87ms behind | ~72ms behind | ~5ms to 10ms behind | 0ms (Perfect Sync) |
| What Your Screen Sees | Past state of the match | Closer past state | Closest to online state but still behind | The functional present | The absolute present |
| Server's Action | Rewinds time 100ms to check your crosshair. | Rewinds time 87ms to check your crosshair. | Rewinds time 72ms to check your crosshair. | Micro-rewinds time (<10ms). | Instantly applies damage. |
. . .
| Feature | 60 FPS Client (100ms) | 80 FPS Client (87ms) | 128 FPS Client (72ms) | LAN Player (<10ms) |
|---|---|---|---|---|
| "Dying Behind Walls" Severity | High (Dying multiple steps past cover) | Moderate (Dying just inside cover) | Low (Dying at the exact edge of cover) | Non-Existent (True synchronization) |
| Peeker's Advantage Vulnerability | Defending is highly punishing | Defending is slightly more manageable | Optimal online defense window | No artificial advantage for the peeker |
| Visual Desync Penalty | Forced to play 28ms further in the past than a 128 FPS opponent. | Forced to play 15ms further in the past than a 128 FPS opponent. | Baseline standard for competitive online play. | Absolute absolute real-time reality. |
. . .
Last edited: