Posts

Aiming the camera with both the mouse and Joystick simultaneously in Unity using legacy InputManager

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: 0

Note 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).

Unity first person player controllers compared

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.

Modular First Person Controller 

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:

  // Gets input and calls jump method && isGrounded
        if(enableJump && Input.GetKeyDown(jumpKey) && isGrounded)
        {
            Jump();
        }


 // Sets isGrounded based on a raycast sent straight down from the player object
    private void CheckGround()
    {
        Vector3 origin = new Vector3(transform.position.xtransform.position.y - (transform.localScale.y * .5f), transform.position.z);
        Vector3 direction = transform.TransformDirection(Vector3.down);
        float distance = .75f;

        if (Physics.Raycast(origindirectionout RaycastHit hitdistance))
        {
            Debug.DrawRay(origindirection * distanceColor.red);
            isGrounded = true;
        }
        else
             isGrounded = false;
     }

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. 

private void Jump()
    {
        // Adds force to the player rigidbody to jump
        if (isGrounded)
        {
            rb.AddForce(0fjumpPower0fForceMode.Impulse);
            isGrounded = false;
        }
        // When crouched and using toggle system, will uncrouch for a jump
        if(isCrouched && !holdToCrouch)
        {
            Crouch();
        }
    }

It uses the legacy InputManager meaning only mouse+keyboard support out of the box, but this is fixable. 

First Person V2.1.0 (new project from built-in template)

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 

float deltaTimeMultiplier = IsCurrentDeviceMouse ? 1.0f : Time.deltaTime/3;

 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:

   private void JumpAndGravity()
        {
            if (Grounded)
            {
                // reset the fall timeout timer
                _fallTimeoutDelta = FallTimeout;

                // stop our velocity dropping infinitely when grounded
                if (_verticalVelocity < 0.0f)
                     _verticalVelocity = -2f;
                // Jump
                if (_input.jump && _jumpTimeoutDelta <= 0.0f)
                    // the square root of H * -2 * G = how much velocity needed to reach desired height
                    _verticalVelocity = Mathf.Sqrt(JumpHeight * -2f * Gravity);
      
                // jump timeout
                if (_jumpTimeoutDelta >= 0.0f)
                    _jumpTimeoutDelta -= Time.deltaTime;     
            }
            else
            {
                // reset the jump timeout timer
                _jumpTimeoutDelta = JumpTimeout;
                // fall timeout
                if (_fallTimeoutDelta >= 0.0f)
                   _fallTimeoutDelta -= Time.deltaTime;
     
                // if we are not grounded, do not jump
                _input.jump = false;
            }
            // apply gravity over time if under terminal (multiply by delta time twice to linearly speed up over time)
            if (_verticalVelocity < _terminalVelocity)
                _verticalVelocity += Gravity * Time.deltaTime;
        }


Starter Assets - First Person Character Controller V1.2

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).


Mini First Person Controller V1.2.0

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:

  bool isGroundedNow = Physics.Raycast(RaycastOrigin, Vector3.down, distanceThreshold * 2);


    // Jump when the Jump button is pressed and we are on the ground.
        if (Input.GetButtonDown("Jump") && (!groundCheck || groundCheck.isGrounded))
        {
            rigidbody.AddForce(Vector3.up * 100 * jumpStrength);
            Jumped?.Invoke();
        }

It uses the legacy InputManager meaning only mouse+keyboard support out of the box, but this is fixable. 


Simple FPS Controller v1.4

The name is misleading; there's no support for shooting/aiming/etc. Aside from a grappling hook, this is just a standard first person controller that also features wall running. While the code is nice and simple making it potentially useful as a starting place, it has major issues. Moving toward a wall while in the air causes you to stick to it indefinitely, so unless you desire that mechanic, this is not for you. And to be clear, that's not how wall running works, that's just how the rigidbody behaves for all vertical surfaces.

 At least you can still jump when moving toward a wall. And you don't slide down on slopes when standing still. 

Here's how jumping works:

        if (isGrounded)
        {
            // Jump
            if (Input.GetButton("Jump") && !jumpBlocked)
            {
                rb.AddForce(-jumpForce * rb.mass * Vector3.down);
                jumpBlocked = true;
                Invoke("UnblockJump", jumpCooldown);
            }
            // Ground controller
            rb.velocity = Vector3.Lerp(rb.velocity, inputForce, changeInStageSpeed * Time.fixedDeltaTime);
        }
        else
            // Air control
            rb.velocity = ClampSqrMag(rb.velocity + inputForce * Time.fixedDeltaTime, rb.velocity.sqrMagnitude);

Advanced First-Person Controller

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.

        public virtual void Accelerate () {
            LookingForGround ();
            MoveTorwardsAcceleration ();
            if (!isMovementAvailable) return;
            if (!rb) return;
            if (System.Math.Abs(movementInputValues.x) < epsilon & System.Math.Abs(movementInputValues.y) < epsilon) return;
            if (!isAirControl) {
                if (!isGrounded) return;
            }
            if (rb.velocity.magnitude > 1.0f) {
                rb.interpolation = RigidbodyInterpolation.Extrapolate;
            }
            else {
                rb.interpolation = RigidbodyInterpolation.Interpolate;
            }
            delta = new Vector3 (movementInputValues.x, 0, movementInputValues.y);
            delta = Vector3.ClampMagnitude (delta, 1);
            delta = rb.transform.TransformDirection (delta) * currentAcceleration;
            vector3_Target = new Vector3 (delta.x, rb.velocity.y, delta.z);
            rb.velocity = Vector3.SmoothDamp (rb.velocity, vector3_Target, ref vector3_Reference, Time.smoothDeltaTime * movementSmoothing);
        }


It uses the legacy InputManager meaning only mouse+keyboard support out of the box, but this is fixable. 

The C Ternary Operator ?: is for (lisp) lovers

 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");


Fake TI ADS1115 ADC sold as ADS1015 - BOGI vs BRPI marking

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.


I've seen several boards marked "12-bit ADS1015" that actually had the BOGI chip on it. Sadly, more recently, I've even seen a chip marked BRPI that turned out to be a ADS1115 - or more likely a cheap clone of the ADS1115 that is not only slow like the 1115, but doesn't really have the 16 bit resolution either. Worst of both worlds. 

So to conclude: check the chip, if it's marked BOGI it's definitely not a ADS1015. And if it's marked BRPI you may have a real ADS 1015, but you'll need to check that it can actually support the full 3300hz sampling rate by connecting to an i2c bus and setting it to the max sample rate. 





Samsung UN65TU7000 TV Review for gamers: input lag from 480i to 4kp60

Summary: This 4k TV (3840x2160) has very low lag but makes up for it with long response times, making the overall speed just ok.

Image quality? 

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).

Input Lag

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.

Full input lag results

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.

topbottom
1st (average)full response1st responsefull response
23.038.037.052.0
6.021.020.035.0
6.021.020.035.0
6.021.020.035.0
6.021.020.035.0

Results compared to other displays

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.

DisplayYear made (TV?)Native Resnative min lagnative real lag480i real lag480p real lag720p real lag1080p real lagnative response timenative scan out
Vizio VO370M20101080p2.523.683.049.047.024.35.4715.67
TCL 40S32520211080p6.527.360.629.027.927.76.0014.83
TCL 49s40320184k6.130.276.830.930.330.78.0016.13
Panasonic TH-58PE75U2008720p28.034.034.034.034.034.06.000.00
Panasonic TH-42PX75U2008720p28.034.034.034.034.034.06.000.00
Panasonic TH-50PZ80U2008720p28.034.034.034.034.034.06.000.00
Corprit D157 (hdmi)20211080p3.134.534.934.834.633.916.2515.13
Samsung UN65TU700020214k6.035.052.035.035.035.015.0014.00
Samsung S27C23020141080p2.936.036.636.136.118.1014.97
Vizio E470VL (vga)20111080p22.039.039.039.039.09.008.00
Samsung LN32D4032012720p20.941.258.942.440.740.75.5014.83
TCL50s42320214k14.042.075.042.042.042.013.0015.00
Dell U2410 (sRGB)20101080p20.542.862.445.043.143.16.1316.13
ACER AT326520121080p19.543.862.745.343.843.88.0016.27
sony XBR 43X800D20174k24.544.346.546.044.644.75.0014.83
Element elst5016s20171080p21.445.163.546.445.145.38.0015.73
Sony 32L50002010720p21.145.780.147.346.145.69.0015.63
RCA L40FHD4120101080p20.346.665.048.047.046.09.6816.63
Sony 40VL130 (game)20081080p22.847.366.349.047.347.39.0815.43
Polaroid FLM-373B2007720p28.049.082.049.049.049.07.0014.00
Philips 42PFL3603D/F720091080p29.050.084.050.050.050.05.0016.00
Sony KDL-40V300020081080p22.250.168.450.650.549.811.0016.93
LG 42LC2D2006720p28.350.654.650.850.46.3015.95
GPX TDE3245W2016720p28.051.0102.051.051.051.08.0015.00
Sony KDL-46EX40020101080p28.052.087.052.052.052.08.0016.00
Toshiba 40L2200U20141080p30.056.074.056.056.056.010.0016.00
Vizio E261VA2012720p19.359.061.160.459.258.925.0014.67
LG 32DL655H2012720p35.059.0105.859.059.059.09.0015.00
Emprex HD 32022007720p27.066.0126.051.050.062.024.0015.00
Samsung LN32B3602010720p37.660.062.161.860.560.18.0014.40
Vizio VO22L FHDTV10A2008720p28.061.094.061.061.061.018.0015.00
Vizio E261VA2007720p28.062.095.062.062.062.018.0016.00
Samsung P2570HD20101080p37.062.062.062.062.062.010.0015.00
Sharp LC-C3234U2009720p33.064.683.666.664.615.0016.60
Samsung LN46B61020121080p53.066.082.066.066.066.05.008.00
LG 42PT35020121080p63.567.785.968.967.767.74.200.00
Mitsubishi LT-4614420081080p51.068.075.068.068.068.09.008.00
Toshiba 46L5200U20131080p55.071.089.076.071.074.08.008.00
Sony 40S20L12007720p48.472.090.172.973.49.6014.00
Samsung LN46C63020121080p54.572.190.790.388.572.310.007.63
SANYO DP507492010720p67.075.0103.094.079.075.07.001.00
Samsung HP-T425420111080p69.775.794.176.075.75.001.00
LG 47LW6500-UA20121080p66.680.7149.7149.081.780.92.2711.83
Vizio E470VL (hdmi)20111080p69.086.0128.095.095.086.09.008.00
Vizio xvt4735v20111080p67.688.688.889.288.688.69.0012.00


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 support > 60hz). This is important - if you sorted instead by input lag alone, this would be nearly the fastest TV I've ever tested. But when response time is included, it's merely average for a 4k/high end TV.  That's why you have to test both input lag and response time.


Other sizes, same speeds?

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. 

 

 

SAMSUNG S22F350 review: input lag, deinterlacing and upscaling using the piLagTesterPRO

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.

Image quality and upscaling

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.

Input Lag

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.

Input Lag Test Results

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.

Results compared to other displays

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.

DisplayYear made (TV?)Native Resnative min lagnative real lag480i real lag480p real lag720p real lag1080p real lagnative response timenative scan out
Dell E198FPb20081024p2.720.439.035.05.0012.70
Planar PLN220020211080p2.422.624.123.322.922.85.0015.17
Samsung 2494sw20111080p2.822.726.526.526.58.0013.30
Vizio VO370M20101080p2.523.683.049.047.024.35.4715.67
Dell S199WFP2009900p3.624.228.527.827.327.18.0012.60
Dell E228WFP20101050p3.024.226.526.75.0016.90
LG W1953T2010768p2.625.628.728.710.0013.00
Samsung S22F35020201080p3.626.229.329.329.210.0012.80
Dell U2410 (game)20101080p4.026.262.228.326.526.56.0016.20
TCL 40S32520211080p6.527.360.629.027.927.76.0014.83
TCL 49s40320184k6.130.276.830.930.330.78.0016.13
AOC/Envision G19LWK2010900p3.131.239.538.738.437.815.5012.60
Dell E2211H20141080p3.033.634.734.534.133.815.0015.57
Panasonic TH-58PE75U2008720p28.034.034.034.034.034.06.000.00
Dell 1907FPc20081024p3.034.035.934.815.0016.00
Panasonic TH-42PX75U2008720p28.034.034.034.034.034.06.000.00
Panasonic TH-50PZ80U2008720p28.034.034.034.034.034.06.000.00
Corprit D157 (hdmi)20211080p3.134.534.934.834.633.916.2515.13
Samsung S27C23020141080p2.936.036.636.136.118.1014.97
Vizio E470VL (vga)20111080p22.039.039.039.039.09.008.00
Samsung LN32D4032012720p20.941.258.942.440.740.75.5014.83
TCL50s42320214k14.042.075.042.042.042.013.0015.00
Dell U2410 (sRGB)20101080p20.542.862.445.043.143.16.1316.13
ACER AT326520121080p19.543.862.745.343.843.88.0016.27
sony XBR 43X800D20174k24.544.346.546.044.644.75.0014.83
Element elst5016s20171080p21.445.163.546.445.145.38.0015.73
Sony 32L50002010720p21.145.780.147.346.145.69.0015.63
RCA L40FHD4120101080p20.346.665.048.047.046.09.6816.63
Sony 40VL130 (game)20081080p22.847.366.349.047.347.39.0815.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.

Conclusion

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.

Other models 

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.

Email me

Name

Email *

Message *