Improvements to OSLTT + Latency Testing Guide
I’ve made a whole bunch of improvements to the latency tool since I last talked about it here, so I thought it was worth talking through what’s new, and also give you a brief guide on some of the quirks of the tool. Sound good? Let’s go! First, what’s new. One of the biggest things that I’ve been burning away slowly at is something you’ll likely never notice if you use the tool, but it’s the backend for selecting – and adding – test modes. The tool has three main lists of options – triggers, those being when to start timing, sensors, what to capture, and test source type, as in what you’re measuring. Prior to recently the code to handle what options were supported or not looked like this… A mess of if else else else else statements and magic numbers. That’s rough to work out what’s going on, and how to add new options. So I’ve remade it into this. A nice, easy to read, list of all allowed configurations. This is the (current) list of all the options the tool knows how to work with, and yes, there are some new ones in there, and yes, this makes it wayyyyyy easier to add new ones in later. I’ve also made the selection process a little smarter without a load of code mess – the ResolveConfiguration function not only checks if your options are valid, but returns the closest match based on as many of the options you’ve chosen as possible, so if you’ve got the button, light sensor, and game, but you want to do click testing and change the light sensor to clicks/keypresses, both the trigger and test type will change. But if you then change back to light sensor, it’ll change back to game but leave the trigger type alone. All while being much more maintainable. Score!
I mentioned adding more testing options, and I’m happy to say there are more! Mainly thanks to a prompt by Aryzon on our Discord server – the OSRTT-OSLTT support channel specifically, link in the description – which include end to end light and audio testing. As in, you tap your mouse button with the tape on it, and then the tool either listens for an in game sound, or watches for something to change on screen. The latter is what you’ll likely know as end-to-end latency, although I do have a little disclaimer to give there. Testing end-to-end latency can add variables you didn’t realise you were adding and lead to inconsistent and unreliable data. That’s not to say it isn’t a useful test or can’t be done well, it absolutely can, but it’s worth knowing what you’re doing. By clicking your mouse and waiting for your screen to change, you’re actually testing your mouse’s latency – the pre-travel in the switch, the switch itself, any microcontroller processing delay, and the polling delay, AND your system’s ability to render a new frame, AND your display’s latency too. Each one of those three parts are their own latency figures you can test separately on the tool, so if you just want to know what settings offer the lowest latency in games, have the tool be the one to click or move your mouse, that way you get much, much more consistent, reliable, and easier results. If you want to know how your mouse affects your latency, test your mouse on its own. Same for your display. The tool has options for all three of those things. But, if you really want the end-to-end results – which to be fair is the most ‘realistic’ test as that’s what the user actually experiences – then go for it, it’s now in there.
The biggest change to your user experience though is to do with peripheral testing – keyboards, mice, controllers – where if you start the test, you’ll see a graph. That’s because I’ve added a live results viewer! This is the only type of test where this makes sense as it’s the only one where the results come straight from the tool itself. As you start tapping away, you get your results shown immediately, giving you an instant look at the trends. Equally, if you start seeing results dropping to zero – or close to it – what’s happening is the tool and the software have become out of sync. What you need to do is tap the tape without triggering the switch, and keep tapping until the LED on the tool doesn’t flash immediately and you don’t get a new result on screen. Then wait three seconds for the LED on the tool to flash again and away you go again. I’m working on a fix for this that means you don’t need to keep an eye on this, but until then, keep an eye on that!
There are a bunch more behind-the-scenes changes since I’ve last shown this off, including improvements to the processing code, and a bunch of other stuff, but I’d love to hear what you think I should add next! What test methods would you like to see included that currently aren’t? What features do you want to see included? Let me know in the comments, on our Discord, or on Github. Hell, email me if you prefer! Whatever it takes, just let me know and I’ll do my best. I am doing this entirely solo, I’m both physically and mentally disabled, and have a lot else (including other tools) going on, so I can’t make any promises, but I’d love to hear what you think. Of course if you don’t have a latency tool, but want one, I make them right here at home in the UK and ship them worldwide, so grab yours at OSRTT.com, linked in the description below!
