LG 32MN60T as a retro-gaming CRT replacement (using OSSC for upscaling)
The intersection of Cognitive Science, Psychophysics, and technology, broadly construed
2021 model IPS LCD/LED monitor, 1080p at up to 75hz. Actually refreshes at 75hz if that's the signal you give it.
Input lag at screen's top was 2.5ms. Response Time was another 8ms on top of that. The screen has several "modes" including game mode, none of which change anything. It also has a Response Time option, with 3 levels of speed. Increasing the response speed increased the brightness overshot in a black to white transition, but didn't really make the slope of the transition any faster, so the response time stayed about the same: 8ms. Perhaps other transitions fare better, but I can see no reason to use anything other than the normal "response time" setting, as that overshot surely leads to visual artifacts (I didn't test real input to see how much of an effect that was).
VESA mountable, good viewing angles. Enormously too large for 1080p on your desktop. This is meant for more of a living room setting where you are sitting further away (coop gaming?) but why not just use a good TV instead? Perhaps because 2.5ms lag is hard to match without going very high end in the TV space.
I tested a used ViewSonic VA2759, made in 2016. Only seems to support 75hz refresh rates and below (but does scan out at 75hz).
It offers a "game" mode, but this only changes the color profile, all timing is identical across all "modes".
It does offer an option to change response time, from "standard" to "ultrafast". This did change response time, but not input lag.
Input lag in the upper corner is 2.5ms. Response time in standard mode is an additional 10ms. Switching to Ultrafast it drops to 7ms. The luminance curves over time show no ugly artifacts in "ultrafast", at least in the black to white transition.
It accepts interlaced video, which is displayed using BOB deinterlacing.
Colors looked fine, but viewing angles seemed a tad narrow for an IPS.
Many Unity games just support mouse and keyboard (WASD) for first person control. But if you are using the legacy input manager (most if not all the free first person controllers do) it's easy to make the gamepad right joystick work for to aim the camera and still support mouse look too!
The secret is the name of an axis (such as mouse y) can refer to multiple input devices. Unity will respond to whichever is being moved. So you just need to add a definition in the input manager for Mouse Y & X that also refers to the joystick. You can use the GUI for this (Edit > Project Settings > Input Manager), or you can edit the file directly, which is what I describe here.
Right click on The Assets folder in the Project tab and select Show in explorer. From here open the ProjectSettings folder and then edit InputManager.asset using your favorite text editor.
Go to the bottom of the file and add a new line just above the last line, which should be
m_UsePhysicalKeys: 0
then paste this code into that empty line:
- serializedVersion: 3
m_Name: Mouse X
descriptiveName: R_Joy_x
descriptiveNegativeName:
negativeButton:
positiveButton:
altNegativeButton:
altPositiveButton:
gravity: 0
dead: 0.1
sensitivity: 1
snap: 0
invert: 0
type: 2
axis: 3
joyNum: 0
- serializedVersion: 3
m_Name: Mouse Y
descriptiveName: R_Joy_y
descriptiveNegativeName:
negativeButton:
positiveButton:
altNegativeButton:
altPositiveButton:
gravity: 0
dead: 0.1
sensitivity: 1
snap: 0
invert: 0
type: 2
axis: 4
joyNum: 0Note the spaces matter. the - has to be on the same column as the m in m_UsePhysicalKeys
Tested and working in Unity 2021.2.33f1 (latest LTS version as of 2023).
This is a roundup of Unity C# first person controllers. A controller is the code that makes your player move based on keyboard/gamepad/mouse input. For now, only free options are included.
This is a good starting place for your own controller, as everything is simple and well labeled in a single script file. It will need some work, however, as the actual control has problems.
Horizontal movement has a major issue: it's easy to get stuck on a wall just by walking at it on a 45 degree angle (this also happens when jumping, meaning you can cling to walls). Jumping has major issues too - if you push against a wall and try to jump it won't let you. Jumping when moving downhill isn't possible, either. Steps are hard, but not impossible; the step size just has to be very short, and this is not tunable. It uses a Rigidbody to do most of the work, so the problems can probably be fixed by changing how that is configured.
Here's the jumping code:
you can help (but not fix completely) the issue with not being able to jump going downhill by increasing the distance value, as I have already done above.
It uses the legacy InputManager meaning only mouse+keyboard support out of the box, but this is fixable.
You get this from the Unity Hub instead of the asset store. It uses the new input system, and as such is much more complex than the previous example. But with that complexity comes controller + mouse + keyboard support. Movement is smooth, with no catching on walls, and no more problems with jumping going down hill. No issues with walking into the ceiling pushing you thru the floor, either. Unfortunately when a jump hits a ceiling it behaves quite weird - either you get stuck against it for a couple frames and then drop normally, or you slowly slide along them and then drop.
The mouse + keyboard support feels well tuned, but the gamepad input is super twitchy. The new input system spreads things out over a lot of different files and UIs, so it's far from obvious how to fix this, but I did find the following hack that works ok: change line 138 of FirstPersonController.cs to
Also, movement in the air is very floaty (basically the same as moving on the ground) which makes any kind of platforming very hard. The code for the controller is very short, but doesn't really explain its logic, eg. here's the jump code:
Seems to be nearly identical to the controller you get from the built-in templet described above, despite the very different version number (1.2 vs 2.1).
Maybe useful as a starting point, but too broken for anything beyond that.
Movement is nice and smooth. If you walk into a wall you glide along it as you would expect, not getting stuck, and you can't slip thru narrow gaps. You can glide up steps if they are not too steep, which seems to come from the fact that a capsule collider is used, which means that it's not particularly tunable. Also, if you stand close enough to an edge (so that your capsule's lowest point is over open space) you start to drift over the edge. At least when standing squarely on a slope there's no problem with slipping down, and you can jump when walking down a slope.
If you jump while moving toward a wall you get stuck on it, almost like wall jumping. Indeed, if you jump into the air and then push against a wall you stick to it, slowly drifting down. That could be a fun mechanic for some games if it were optional. Worse, however, pushing against any kind of surface, be it a wall or an overly high step, prevents you from jumping at all.
At least jumping and hitting your head works as expected - you immediately bounce back downwards. With so much broken (and with most of the behavior stemming from using a rigid body) I'm not sure it's worth showing the fairly minimal source. Here's a couple of very familiar lines, though:
It uses the legacy InputManager meaning only mouse+keyboard support out of the box, but this is fixable.
Maybe useful as a starting point, but too broken for anything beyond that.
The major thing this brings is a HUD (health bar, etc) and camera shake when you land. Neither are great; the HUD often clips into geometry and half-disappears. The camera shake is really neat and effective AT FIRST, and then you'll be shouting how do I turn this effect off?!
Movement is fairly nice and smooth. If you walk into a wall you glide along it as you would expect, not getting stuck, and you can't slip thru narrow gaps. Occasionally though, you bounce off a little, which feels like a glitch. You can glide up steps if they are not too steep, which seems to come from the fact that a capsule collider is used, which means that it's not particularly tunable. Unfortunately, rather than climbing up a step, it's more like a little "jump" and thus you usually get the camera shake effect after each step. Also, if you stand close enough to an edge (so that your capsule's lowest point is over open space) you start to drift over the edge.
Slopes are problematic. You start to drift downwards whenever standing on slope of any magnitude. If it's moderately steep and you start walking down you actually move forward a little and then drop, causing another camera shake. At least you can jump while walking down a slope.
Hitting your head mostly works as expected - you do get pushed back a little if it's sloped at all, but the effect is mild and somewhat realistic (assuming your head is made of rubber). Most of the bounce is directed down. And if you walk into a sloped ceiling it doesn't push you thru the floor.
Much of this behavior stems from the use of a rigidbody, but the code still manages to be complex, and not particularly well layed out or commented.
The C/C++/JAVA Ternary Operator (or inline if as I like to call it):
(test) ? do-if-true : do-if-false
as in:
printf("x is %s than y", (x > y) ? "larger" : "smaller");
Also legal is to place the parentheses around the whole thing:
(test ? if-true : if-false)
All the hits on google start with half a page of blather before they get to a complete example like the one above. Which is probably how they get traffic, but what a waste. I'm putting the blather here where it's easy to skip!
I love this operator because of that short LISP detour I took in my 20s (after the Smalltalk detour of my teens, and before my main path of being a Matlab hacker in my 30s). Like an s-expression it allows you to do things that would otherwise require temporary variables, or lots of duplicate code. People criticize the ternary operator because it's confusing, which is fair. So is Lisp if you don't use it often (and goodness knows I haven't written Lisp in more than a decade so I can really sympathize with that one).
And yes there's a bug in my example. Consider x = y = 1;
You could do this, however:
(x > y ? "larger" : (x == y ? "equal" : "smaller"))
but I have to admit at that point I start to agree with the detractors that it's too hard to read. On the other hand, the equivalent if statement either has 3 printfs or a temporary variable, which isn't that great either.
Bonus chatter:
lisp syntax (from memory, untested):
(if (> x y) "larger" (if (= y x) "equal" "smaller" ))
and the equivalent if-based solution in c:
if (x > y)
printf("x is larger than y");
else if (x == y)
printf("x equals y");
else
printf("x is smaller than y");
These days it's getting almost impossible to get a functioning ADS1015, a great high-speed ADC (analog to digital converter) made by TI. AdaFruit makes a very nice board featuring it that I've used in a lot of projects. Or rather, I've used their board design, but ordered it from Chinese manufactures on aliexpress and ebay, who used the open source schematics to make much cheaper boards. For the first 20-30 I purchased there was no problem, but lately all the boards that are supposed to be ADS1015s have actually had the ADS1115. This might seem like an upgrade, because the ADS 1015 only has 12 bit resolution, and the ADS1115 offers 16 bits. But higher resolution has to come at a cost, and in this case the cost is speed - the ADS1115 maxes out at 860 samples per second, whereas the 1015 can take measurements 3300 times a second - almost 4 times faster.
Since the 1015 and 1115 and electrically compatible, the same board design works with both, meaning that you can't tell at a glance which you have. The chip has microscopic markings on it that identify which version it is; reading the datasheets around page 40 you can determine that the ADS 1115 is marked BOGI, and the ADS1015 is marked BRPI.
Summary: This 4k TV (3840x2160) has very low lag but makes up for it with long response times, making the overall speed just ok.
This is a capsule review since the unit I tested had a significant crack, lowering my acquisition cost to zero but preventing any in depth tests of image quality. I did check the upscaling performance on 480i content and was very unimpressed; everything was very blurry and there seemed to be some kind of post processing filter applied to smooth the edges and curves with an effect much like 2xSaI. Heavy blur plus post-processing is a bad combo; though I'd be happy enough if these were toggleable options. They are not, however; indeed there seem to be almost no picture processing options (and what there are, are disabled in gaming mode).
I used a piLagTesterPRO to measure input lag. This device sends a frame of video over HDMI and measures how long it takes to display it.
All tests were in game mode. For progressive content the input lag and response time was the same across all resolutions, from 4k, to 480p. The brightness level, however, had a noticeable effect on apparent lag. For higher brightness levels (around 50 and above), the display is illuminated constantly. With this configuration a displayed image starts to appear at the top of the screen around 6ms after it is sent to the TV over HDMI (aka input lag). But that image takes a full 15ms to reach full brightness (aka response time), which more than undoes any perceptual advantage from the low input lag.
The numbers are rather different when the brightness level is lower; in order to reduce the brightness the TV strobes the backlight to reduce the total light and in doing so they cleverly time the dark part to coincide with the start of the input lag, thus hiding the slow change. Now input lag is roughly 10ms (at the top of the screen) but after just 3 additional MS the brightness level is maybe 70% of the way to full brightness. While this this is a little below the standard I use for measuring response time (I usually use 80% of full brightness) it's close enough perceptually, and the result is a much clearer moving image. Of course the TV is rather dark at this point, so using it in this mode is best for dark rooms. As a bonus, the TV's backlights will last longer with the brightness turned down.
Of course this is all measured at the top of a screen. At 60hz it should take about 16ms for the image to be drawn all the way to the bottom of the screen, if the TV draws at the rate pixels are received. However, lag is only about 14ms longer at the bottom of the screen than the top, suggesting that the input is buffered some and then when drawing commences it goes somewhat faster to catch up, but the effect is small. The TV does accept signals at up to 75hz (depending on the resolution) but just drops frames, still showing only 60 frames per second, so there's no advantage and definite disadvantage to going above 60hz.
As you might expect the TV is slower for interlaced content, such as 480i: take everything above and add 17ms (yes, slightly more than a frame length). Worryingly, several times when I switched on a 480i input (in game mode!) an additional 16ms was added on top of this (for a total of 33ms for deinterlacing). I found that toggling game mode on and off would return it to the "faster" 17ms, and when I tried to reproduce the problem I could not, suggesting it might have to do with the first time a new device outputs a new resolution, but that's entirely a guess based on too little data.
I report two kinds of values. 1st response measures how long it takes for the TV to start responding (I use a 5% change in display brightness). This overly optimistic value doesn't tell how long it takes to see anything useful, but matches what other reviewers call input lag. full response is a more realistic measure of lag, and requires the display to reach 80% of full brightness. This combines both input lag and response time, and is closer to what you would actually experience in a game. I'm using the values from full brightness when the TV isn't strobing here, and I'm assuming the variable 480i result was just a configuration glitch that wouldn't be seen once everything was set up properly.
| top | bottom | ||
| 1st (average) | full response | 1st response | full response |
| 23.0 | 38.0 | 37.0 | 52.0 |
| 6.0 | 21.0 | 20.0 | 35.0 |
| 6.0 | 21.0 | 20.0 | 35.0 |
| 6.0 | 21.0 | 20.0 | 35.0 |
| 6.0 | 21.0 | 20.0 | 35.0 |
To allow quick comparison between many displays I've summarized the results across all the displays I've personally tested with the piLagTester Pro. Min lag is the time to the first response, measured where the screen starts drawing (typically, the top); real lag is the time to the full response, measured where drawing finishes (usually the screen bottom), i.e. input lag + scan out + response time. Numbers in red denote average values that can vary by up to 8ms between power cycles.
| Display | Year made (TV?) | Native Res | native min lag | native real lag | 480i real lag | 480p real lag | 720p real lag | 1080p real lag | native response time | native scan out |
| Vizio VO370M | 2010 | 1080p | 2.5 | 23.6 | 83.0 | 49.0 | 47.0 | 24.3 | 5.47 | 15.67 |
| TCL 40S325 | 2021 | 1080p | 6.5 | 27.3 | 60.6 | 29.0 | 27.9 | 27.7 | 6.00 | 14.83 |
| TCL 49s403 | 2018 | 4k | 6.1 | 30.2 | 76.8 | 30.9 | 30.3 | 30.7 | 8.00 | 16.13 |
| Panasonic TH-58PE75U | 2008 | 720p | 28.0 | 34.0 | 34.0 | 34.0 | 34.0 | 34.0 | 6.00 | 0.00 |
| Panasonic TH-42PX75U | 2008 | 720p | 28.0 | 34.0 | 34.0 | 34.0 | 34.0 | 34.0 | 6.00 | 0.00 |
| Panasonic TH-50PZ80U | 2008 | 720p | 28.0 | 34.0 | 34.0 | 34.0 | 34.0 | 34.0 | 6.00 | 0.00 |
| Corprit D157 (hdmi) | 2021 | 1080p | 3.1 | 34.5 | 34.9 | 34.8 | 34.6 | 33.9 | 16.25 | 15.13 |
| Samsung UN65TU7000 | 2021 | 4k | 6.0 | 35.0 | 52.0 | 35.0 | 35.0 | 35.0 | 15.00 | 14.00 |
| Samsung S27C230 | 2014 | 1080p | 2.9 | 36.0 | 36.6 | 36.1 | 36.1 | 18.10 | 14.97 | |
| Vizio E470VL (vga) | 2011 | 1080p | 22.0 | 39.0 | 39.0 | 39.0 | 39.0 | 9.00 | 8.00 | |
| Samsung LN32D403 | 2012 | 720p | 20.9 | 41.2 | 58.9 | 42.4 | 40.7 | 40.7 | 5.50 | 14.83 |
| TCL50s423 | 2021 | 4k | 14.0 | 42.0 | 75.0 | 42.0 | 42.0 | 42.0 | 13.00 | 15.00 |
| Dell U2410 (sRGB) | 2010 | 1080p | 20.5 | 42.8 | 62.4 | 45.0 | 43.1 | 43.1 | 6.13 | 16.13 |
| ACER AT3265 | 2012 | 1080p | 19.5 | 43.8 | 62.7 | 45.3 | 43.8 | 43.8 | 8.00 | 16.27 |
| sony XBR 43X800D | 2017 | 4k | 24.5 | 44.3 | 46.5 | 46.0 | 44.6 | 44.7 | 5.00 | 14.83 |
| Element elst5016s | 2017 | 1080p | 21.4 | 45.1 | 63.5 | 46.4 | 45.1 | 45.3 | 8.00 | 15.73 |
| Sony 32L5000 | 2010 | 720p | 21.1 | 45.7 | 80.1 | 47.3 | 46.1 | 45.6 | 9.00 | 15.63 |
| RCA L40FHD41 | 2010 | 1080p | 20.3 | 46.6 | 65.0 | 48.0 | 47.0 | 46.0 | 9.68 | 16.63 |
| Sony 40VL130 (game) | 2008 | 1080p | 22.8 | 47.3 | 66.3 | 49.0 | 47.3 | 47.3 | 9.08 | 15.43 |
| Polaroid FLM-373B | 2007 | 720p | 28.0 | 49.0 | 82.0 | 49.0 | 49.0 | 49.0 | 7.00 | 14.00 |
| Philips 42PFL3603D/F7 | 2009 | 1080p | 29.0 | 50.0 | 84.0 | 50.0 | 50.0 | 50.0 | 5.00 | 16.00 |
| Sony KDL-40V3000 | 2008 | 1080p | 22.2 | 50.1 | 68.4 | 50.6 | 50.5 | 49.8 | 11.00 | 16.93 |
| LG 42LC2D | 2006 | 720p | 28.3 | 50.6 | 54.6 | 50.8 | 50.4 | 6.30 | 15.95 | |
| GPX TDE3245W | 2016 | 720p | 28.0 | 51.0 | 102.0 | 51.0 | 51.0 | 51.0 | 8.00 | 15.00 |
| Sony KDL-46EX400 | 2010 | 1080p | 28.0 | 52.0 | 87.0 | 52.0 | 52.0 | 52.0 | 8.00 | 16.00 |
| Toshiba 40L2200U | 2014 | 1080p | 30.0 | 56.0 | 74.0 | 56.0 | 56.0 | 56.0 | 10.00 | 16.00 |
| Vizio E261VA | 2012 | 720p | 19.3 | 59.0 | 61.1 | 60.4 | 59.2 | 58.9 | 25.00 | 14.67 |
| LG 32DL655H | 2012 | 720p | 35.0 | 59.0 | 105.8 | 59.0 | 59.0 | 59.0 | 9.00 | 15.00 |
| Emprex HD 3202 | 2007 | 720p | 27.0 | 66.0 | 126.0 | 51.0 | 50.0 | 62.0 | 24.00 | 15.00 |
| Samsung LN32B360 | 2010 | 720p | 37.6 | 60.0 | 62.1 | 61.8 | 60.5 | 60.1 | 8.00 | 14.40 |
| Vizio VO22L FHDTV10A | 2008 | 720p | 28.0 | 61.0 | 94.0 | 61.0 | 61.0 | 61.0 | 18.00 | 15.00 |
| Vizio E261VA | 2007 | 720p | 28.0 | 62.0 | 95.0 | 62.0 | 62.0 | 62.0 | 18.00 | 16.00 |
| Samsung P2570HD | 2010 | 1080p | 37.0 | 62.0 | 62.0 | 62.0 | 62.0 | 62.0 | 10.00 | 15.00 |
| Sharp LC-C3234U | 2009 | 720p | 33.0 | 64.6 | 83.6 | 66.6 | 64.6 | 15.00 | 16.60 | |
| Samsung LN46B610 | 2012 | 1080p | 53.0 | 66.0 | 82.0 | 66.0 | 66.0 | 66.0 | 5.00 | 8.00 |
| LG 42PT350 | 2012 | 1080p | 63.5 | 67.7 | 85.9 | 68.9 | 67.7 | 67.7 | 4.20 | 0.00 |
| Mitsubishi LT-46144 | 2008 | 1080p | 51.0 | 68.0 | 75.0 | 68.0 | 68.0 | 68.0 | 9.00 | 8.00 |
| Toshiba 46L5200U | 2013 | 1080p | 55.0 | 71.0 | 89.0 | 76.0 | 71.0 | 74.0 | 8.00 | 8.00 |
| Sony 40S20L1 | 2007 | 720p | 48.4 | 72.0 | 90.1 | 72.9 | 73.4 | 9.60 | 14.00 | |
| Samsung LN46C630 | 2012 | 1080p | 54.5 | 72.1 | 90.7 | 90.3 | 88.5 | 72.3 | 10.00 | 7.63 |
| SANYO DP50749 | 2010 | 720p | 67.0 | 75.0 | 103.0 | 94.0 | 79.0 | 75.0 | 7.00 | 1.00 |
| Samsung HP-T4254 | 2011 | 1080p | 69.7 | 75.7 | 94.1 | 76.0 | 75.7 | 5.00 | 1.00 | |
| LG 47LW6500-UA | 2012 | 1080p | 66.6 | 80.7 | 149.7 | 149.0 | 81.7 | 80.9 | 2.27 | 11.83 |
| Vizio E470VL (hdmi) | 2011 | 1080p | 69.0 | 86.0 | 128.0 | 95.0 | 95.0 | 86.0 | 9.00 | 8.00 |
| Vizio xvt4735v | 2011 | 1080p | 67.6 | 88.6 | 88.8 | 89.2 | 88.6 | 88.6 | 9.00 | 12.00 |
This TV comes in a ton of sizes, from the 43" UN43TU7000FXZA to the really obscenely large 85" UN85TU7000FXZA:
| Size | US Model |
| 43" | UN43TU7000FXZA |
| 50" | UN50TU7000FXZA |
| 55" | UN55TU7000FXZA |
| 58" | UN58TU7000FXZA |
| 60" | UN60TU7000FXZA |
| 65" | UN65TU7000FXZA |
| 70" | UN70TU7000FXZA |
| 75" | UN75TU7000FXZA |
| 82" | UN82TU7000FXZA |
| 85" | UN85TU7000FXZA |
I tested the 65" version, which was also larger than I'd ever want to use personally. As to whether the same lag results would be found across all these models, I don't know. RTings tested the 55" UN55TU7000FXZA and got results about 2ms slower than I report here, however their methods are rather different than mine so that's within the level of difference I would expect caused by sensor location, backlight levels, etc, and not actually hardware differences. In fact I'm amazed we agree as well as we do, given the flickering backlight on this model, which can cause the estimated lag to differ by as much as 5ms between frames depending on where the dark section falls with respect to the drawing of a new input.
This is a 1080p75 TN monitor from 2020. It does not have an adjustable stand; the default height and angle are fixed. It does offer a VESA mount if you need more flexibility. Power is supplied via an external 14w DC supply. Like most TN monitors it has little lag, but it does suffer from somewhat high response time.
Good upscaling is critical for retro gaming. Ideally, all pixels should appear equally sharp and bright (no aliasing), and angled lines should appear smooth, with no jagged, irregular steps. On computer monitors this is less of an issue than TVs, but it's still worth testing.
| resolution | quality |
| 480p/i | A+ Minimal but detectable blur. Could only display progressive input, interlaced was not supported. |
| 720p | A- Sharp, almost as good as 1080p. Some very slight jaggedness and pixel re-arranging that only really shows up on diagonal lines and 1-pixel wide checkerboards. |
| 1080p | 100% of pixels displayed, all sharp |
Unfortunately this is a TN display which means limited viewing angles - from above everything is washed out and from below it's all too dark. Side to side is actually pretty uniform, with minimal color shifts.
The display has 1 HDMI and 1 VGA input. I only tested HDMI.
I used a piLagTesterPRO to measure input lag. This device sends a frame of video over HDMI and measures how long it takes to display it. This display has a game mode, and with it off input lag was about 4ms at the top of the screen. Turning game mode on did not change input lag any, but did improve response time. I toggled all the other display quality settings as well, but did not see any further improvements, however the tests reported below with every "enhancement" set to off, except for game mode which was on.
I report two kinds of values. 1st response measures how long it takes for the TV to start responding (I use a 5% change in display brightness). This overly optimistic value doesn't tell how long it takes to see anything useful, but matches what other reviewers call input lag. full response is a more realistic measure of lag, and requires the display to reach 80% of full brightness. This combines both input lag and response time, and is closer to what you would actually experience in a game.
| top | bottom | |||||
| Resolution | 1st (average) | full response | 1st response | full response | scan out | |
| 480i | 4.4 | 14.4 | 19.3 | 29.3 | 14.9 | |
| 480p | 4.4 | 14.4 | 19.3 | 29.3 | 14.9 | |
| 720p | 3.6 | 13.6 | 19.3 | 29.3 | 15.7 | |
| 1080p60 | 3.6 | 13.6 | 19.2 | 29.2 | 15.6 | |
| 1080p75 | 3.4 | 13.4 | 16.2 | 26.2 | 12.8 | |
The input lag is about 4ms across all resolutions and refreshrates. Scan out is about 15ms for 60hz, and about 13ms for 75hz.
Interestingly, the display supports refresh rates above the recommended 60hz, even at 1080p. This is with proper sync: that is to say the monitor doesn't drop frames, but actually increases the redraw rate to keep up with the rate that data is sent to it. If you "overclock" the display it can handle 75hz at 1080p; this is really a misapplication of the term overclocking; what I really mean is if you force your videocard to output 1080p75, the screen will sync with it just fine. You can also go slower, down to 50hz.
One issue is the response time is quite variable depending on the transition the LCD has to make. Black to white is fast (5ms) and fairly clean, whereas other transitions often happen in 2-steps, where the LCD gets close to the desired brightness, pauses for half a frame, and then steps the rest of the way. This made the typical response time 15ms in normal mode, and 10ms in game mode. I'm sure this two-step process causes some motion artifacts when viewed on a high speed camera, and probably results in moving stimuli looking more muddy to the human eye than they would otherwise, so my chart uses the slower 10ms transistions rather than the 5ms from the fastest. I'm not going to be too hard on the display, however, as this is a common issue.
To allow quick comparison between many displays I've summarized the results
across all the displays I've personally tested with the piLagTester Pro. Min
lag is the time to the first response, measured where the screen starts
drawing (typically, the top); real lag is the time to the full response,
measured where drawing finishes (usually the screen bottom), i.e. input lag +
scan out + response time. Numbers in red denote average values that can vary by
up to 8ms between power cycles.
This list is sorted by real lag for each display's native resolution and max
refresh rate (usually 1080p60 but some sets are 720p60, and other monitors, like
this one,
support > 60hz). It is a subset of the screens I've tested, mostly monitors,
but a few TVs thrown in for comparison.
| Display | Year made (TV?) | Native Res | native min lag | native real lag | 480i real lag | 480p real lag | 720p real lag | 1080p real lag | native response time | native scan out |
| Dell E198FPb | 2008 | 1024p | 2.7 | 20.4 | 39.0 | 35.0 | 5.00 | 12.70 | ||
| Planar PLN2200 | 2021 | 1080p | 2.4 | 22.6 | 24.1 | 23.3 | 22.9 | 22.8 | 5.00 | 15.17 |
| Samsung 2494sw | 2011 | 1080p | 2.8 | 22.7 | 26.5 | 26.5 | 26.5 | 8.00 | 13.30 | |
| Vizio VO370M | 2010 | 1080p | 2.5 | 23.6 | 83.0 | 49.0 | 47.0 | 24.3 | 5.47 | 15.67 |
| Dell S199WFP | 2009 | 900p | 3.6 | 24.2 | 28.5 | 27.8 | 27.3 | 27.1 | 8.00 | 12.60 |
| Dell E228WFP | 2010 | 1050p | 3.0 | 24.2 | 26.5 | 26.7 | 5.00 | 16.90 | ||
| LG W1953T | 2010 | 768p | 2.6 | 25.6 | 28.7 | 28.7 | 10.00 | 13.00 | ||
| Samsung S22F350 | 2020 | 1080p | 3.6 | 26.2 | 29.3 | 29.3 | 29.2 | 10.00 | 12.80 | |
| Dell U2410 (game) | 2010 | 1080p | 4.0 | 26.2 | 62.2 | 28.3 | 26.5 | 26.5 | 6.00 | 16.20 |
| TCL 40S325 | 2021 | 1080p | 6.5 | 27.3 | 60.6 | 29.0 | 27.9 | 27.7 | 6.00 | 14.83 |
| TCL 49s403 | 2018 | 4k | 6.1 | 30.2 | 76.8 | 30.9 | 30.3 | 30.7 | 8.00 | 16.13 |
| AOC/Envision G19LWK | 2010 | 900p | 3.1 | 31.2 | 39.5 | 38.7 | 38.4 | 37.8 | 15.50 | 12.60 |
| Dell E2211H | 2014 | 1080p | 3.0 | 33.6 | 34.7 | 34.5 | 34.1 | 33.8 | 15.00 | 15.57 |
| Panasonic TH-58PE75U | 2008 | 720p | 28.0 | 34.0 | 34.0 | 34.0 | 34.0 | 34.0 | 6.00 | 0.00 |
| Dell 1907FPc | 2008 | 1024p | 3.0 | 34.0 | 35.9 | 34.8 | 15.00 | 16.00 | ||
| Panasonic TH-42PX75U | 2008 | 720p | 28.0 | 34.0 | 34.0 | 34.0 | 34.0 | 34.0 | 6.00 | 0.00 |
| Panasonic TH-50PZ80U | 2008 | 720p | 28.0 | 34.0 | 34.0 | 34.0 | 34.0 | 34.0 | 6.00 | 0.00 |
| Corprit D157 (hdmi) | 2021 | 1080p | 3.1 | 34.5 | 34.9 | 34.8 | 34.6 | 33.9 | 16.25 | 15.13 |
| Samsung S27C230 | 2014 | 1080p | 2.9 | 36.0 | 36.6 | 36.1 | 36.1 | 18.10 | 14.97 | |
| Vizio E470VL (vga) | 2011 | 1080p | 22.0 | 39.0 | 39.0 | 39.0 | 39.0 | 9.00 | 8.00 | |
| Samsung LN32D403 | 2012 | 720p | 20.9 | 41.2 | 58.9 | 42.4 | 40.7 | 40.7 | 5.50 | 14.83 |
| TCL50s423 | 2021 | 4k | 14.0 | 42.0 | 75.0 | 42.0 | 42.0 | 42.0 | 13.00 | 15.00 |
| Dell U2410 (sRGB) | 2010 | 1080p | 20.5 | 42.8 | 62.4 | 45.0 | 43.1 | 43.1 | 6.13 | 16.13 |
| ACER AT3265 | 2012 | 1080p | 19.5 | 43.8 | 62.7 | 45.3 | 43.8 | 43.8 | 8.00 | 16.27 |
| sony XBR 43X800D | 2017 | 4k | 24.5 | 44.3 | 46.5 | 46.0 | 44.6 | 44.7 | 5.00 | 14.83 |
| Element elst5016s | 2017 | 1080p | 21.4 | 45.1 | 63.5 | 46.4 | 45.1 | 45.3 | 8.00 | 15.73 |
| Sony 32L5000 | 2010 | 720p | 21.1 | 45.7 | 80.1 | 47.3 | 46.1 | 45.6 | 9.00 | 15.63 |
| RCA L40FHD41 | 2010 | 1080p | 20.3 | 46.6 | 65.0 | 48.0 | 47.0 | 46.0 | 9.68 | 16.63 |
| Sony 40VL130 (game) | 2008 | 1080p | 22.8 | 47.3 | 66.3 | 49.0 | 47.3 | 47.3 | 9.08 | 15.43 |
You can see that this display is quite competitive, like all TNs But stepping back for a moment: pretty much every screen on this list has acceptable lag. The difference between starting to respond 2.7ms vs 6ms after receiving the signal is meaningless. What's more meaningful is the response time, where lower values mean less blurry visuals. The spread is larger there, with this display being decidedly average. But certainly good enough.
Like most computer monitors this display is fast, much faster than most TVs. For most gamers it is plenty fast enough. It is kind of small, and the lack of adjustable stand is a real downer. At least it is VESA mountable, making it a good choice for a second monitor. If you like to share your monitor with a 2nd person the poor viewing angles could be a issue.
I tested the smallest model, the S22F350. There are several more sizes: S24F350, S27F350, and even a huge S32F351. I don't expect them to perform identically to this model as the larger ones have freesync which probably means entirely different electronics. Indeed, the spec sheets do differ significantly. Given the large space of possible model numbers available to them I don't think they should have used the F350 postfix for all these models.