a fun fact

every time you dart your eyes around, not only does your brain automatically erase the data of "that smeared blur i saw for a moment", it also takes what you see when your eyes stop moving and retroactively inserts it as a memory for that moment. that's why if you look at your watch, it seems to take longer for the second hand to tick the first time

human senses are garbage

if you watch a video where the sound is slightly delayed behind the picture, your brain will basically fix it in post. if you watch a video where the picture is slightly delayed behind the sound, your brain will freak the fuck out

if you set up a computer program to listen for a keystroke, delay for a short amount of time, and then flash the screen, a human that presses the keys will eventually stop perceiving that delay

then if you remove the delay, the human will believe that the computer is anticipating their keystrokes

human senses are garbage

roasting discord 

@monorail if this computer one is true then discord must be slow as FUCK since I can actually perceive the keystroke delay
@monorail also, this is interesting in the context of the game osu, which plays a sound through headphones at the moment that you press a key.

except if you analyse the audio output it comes about 50 ms after the key click sound due to computer latency
Follow

@cadence @monorail don't get me started on rhythm games and latency syncing - you have input latency, video latency, and audio latency, which are all different!

@ChlorideCull @monorail osu: "we have one slider that doesn't specify which it is. we also have fine adjustment per-map, which is the exact same setting but its measurement is negative."
@ChlorideCull @monorail I have literally ranted for 30 minutes about why osu is a disappointing rhythm game do NOT get me started

@cadence @monorail have yet to see a rhythm game handle it well

The Rock Band 4 guitar has a microphone and optical sensor so it can handle the calibration automatically by putting it against the TV

except they forgot it's over Bluetooth so there's a somewhat random delay of 5-50 ms

@ChlorideCull @cadence the rb/gh games do honestly handle it well if you do it manually as opposed to using the automatic calibration

it's just a hard problem to solve

@cadence @ChlorideCull @monorail video latency is rarely needed since its a rhythm game, unless its really high which it basically never is
useful for predicting rhythms youve never heard, though our brains react to audio way quicker than video so its not feasable to play without audio

input latency is really hard to calibrate, but still is important

audio latency is the most important one, and easy to calibrate AS LONG AS input latency is calibrated properly

most games dont care about video latency, and count audio and input latency as one thing because, why wouldnt they
the only case where input latency differs is on keyboards with low polling rates

im guessing per-map latency is offsets? which is just as important, however in most cases if your bpm isnt doing weird changes youre safe automatically detecting it and then adjusting via assistticks and waveform alignment

@cadence @ChlorideCull @monorail im not defending osu, it still sucks
but one offset is the standard rhythm game treatment
youll find it in itg, arcaea, basically anywhere

@oat @cadence @ChlorideCull also unless i'm seriously misunderstanding

a positive change in two of the three is equivalent to a negative change in the last one. like +5 +10 +0 plays exactly the same as +0 +5 -5

so if visual latency isn't super important to you, you should be mostly okay with just the adjustment for audio latency

@monorail @cadence @ChlorideCull yeah, input latency is a part of audio latency
if you press a button and 50ms later you hear a sound, theres either 50ms of audio latency, 50ms of input latency, or its something inbetween

if you have 50ms of audio latency, you can offset the song by 50ms so that when you hit the key, the song has already went 50ms ahead to account for the latency

if you have 50ms of input latency however, you cant just offset the input. you cant really just sleep(-50ms), only count that input as if it was 50ms ago, but thats really complicated and ""fun"" to implement in its own ways
doing the same method as audio latency would work however, and you can just sum up the input and audio latency and offset the song by that much

plus its easier to understand and calibrate from the player side. assuming 25ms of input latency and 25ms of audio latency, how do you tell which of the 50ms total latency is audio and which is input? aligning a picture blinking to player inputs is still input + video latency, and aligning a beat to player inputs is input + audio latency, so most just calibrate the sum of both at once and use that

Sign in to participate in the conversation
Fuzzy Systems Masto

Instance run by a non-profit association, with a mission to encourage an open internet, welcoming to everyone.