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