Add visual offset option

[DeenyBoi]

Its just impossible to get good accuracy with a weird hit offset. I would like to request a "hit offset" slider on the options menu.

[bdach]

"Audio offset" is already a thing in the settings; per-beatmap offset is also planned (see #8787). Does this answer your request?

[DeenyBoi]

Audio offset is a bit helpful, but not that much since it just doesnt work sometimes because its just the keypress that is delayed, not the music.

[bdach]

That sounds wrong. Currently input is processed at 1000fps when multithreaded, so you shouldn't be seeing any delay. Are you using wired peripherals? Note that wireless devices can have intrinsic input delay due to having to transmit the inputs over the air.

I'm pretty sure an input offset is not something that will happen.

[abraker95]

Input offset sounds wrong. What is needed is visual offset.

[bdach]

I'm not sure I follow what this issue is asking for if that is the case. How would that even work?

[abraker95]

How would that even work

Consider you are playing on a TV that has a 100 ms latency. Everything being displayed is displayed 100 ms late, so you hit everything 100 ms late. To fix that, the map visually needs to be offset to 100 ms earlier but the time you need to hit the notes needs to remain the same.

[bdach]

100ms late relative to what? If relative to audio, then you might as well put an audio offset of +100ms to compensate, no?

[abraker95]

100 ms late relative to actual timing of the note; the point in time the game expects the note to be hit.

[bdach]

...which depends on the audio timing, does it not? Unless you're expecting compensation for input lag? I'm really struggling to understand here.

[abraker95]

No, try play osu on a TV that has all the fancy HDR features enabled, for example. Audio latency wont suffer, but the TV will take time processing visual information, causing the display to be late relative to audio.

So if you hit a key, you might hear audio 10 ms after you hit the key, but wont see it on the screen until 100 ms after you hit the key.

[Wieku]

@bdach That's a feature some VSRGs do have. They have two settings - Audio Offset and Visual Offset. In some cases audio may be in sync but if you're not solely dependent on music rhythm but visuals then display's reaction time (or your eyes OR when you have bad keyboard with 30ms+ processing delay) can be a problem. It doesn't move the hitobject timing window like audio offset, just visual representation of it.

[Wieku]

To be easier to understand: We have a hitcircle here. It's supposed to be clicked at blue arrow. What visual offset does, it moves the visual representation of hitcircle to the red arrow, but it's timing stays at the blue arrow.

[bdach]

Okay, I think I get it - you're asking for the ability for the game to send frames earlier than audio to compensate for the round trip time of GPU -> screen. (Input would be unaffected by this.)

The "100ms" figure given sounds exaggerated though to the point to which that would probably be unplayable; I imagine that latency should be half of that at most which comes out to about 3-4 frames. Which sounds like not much to me but maybe at high levels it is significant. No idea.

[abraker95]

I tried playing mania on my Samsung 4k TV and was hitting 50s on all my hits. That felt like 100ms late. Yes, it was unplayable, but if I could change visual offset it can be playable.

[Wieku]

@bdach It's not exaggerated if we're talking about TVs or projectors. I think it will also positively affect mobiles which do have 80ms+ of touch delay on average.

[peppy]

First step is to set your tv to "game mode". As osu! relies on hitsounds being in time, a visual offset is not something which will feel good.

[abraker95]

I know some tvs have a game mode. I used the tv as a supposedly relatable example to make a point across. As @Wieku mentioned earlier, visual offset would be beneficial for mobile and is more commonly used to compensate for reaction time. I don't know what hitsounds have to do with visual offset; it should not do anything to hitsounds.

[peppy]

At the point a visual offset is required, the game is running on inadequate hardware. If you can't understand how it affects hitsounds, you may need to think about offsets for a few days. Maybe do some diagrams. Offsets aren't easy to understand so if you aren't willing to do the mental work, trust that what I say is correct.

[abraker95]

Key:

• Blue line: Timing point where note is displayed
• Red line: Timing point where hitsound is played/heard
• Purple line: Timing point where sound in music associated with the note plays
• Green circle: Timing point where the game logic interprets 0 ms hiterror

Audio latency example

Player perspective: Audio latency is in effect, causing the music to be heard some amount of time after when the note needs to be hit. The player hits the note when visible, but the hit does not match the music. The map appears off-sync with the music.

Game perspective: Everything is in sync, but map needs to be moved to compensate for audio

Audio latency example with correct audio offset

Player perspective: Points when note needs to be hit and sound in music associated with the note are now in sync

Game perspective: Audio latency is compensated by shifting all of the notes in the map to match the audio as heard by the player

Visual latency example with correct audio offset

Player perspective: Visual latency is in effect, causing the note to appear later than it must actually be hit. While the timings of music and when the note needs to be hit do match, when the note appears and the player hits it, the hit is late.

Game perspective: Everything is in sync, but notes need to be displayed a bit before the point when game interprets center of hit

Visual latency example with correct audio offset and correct visual offset

Player perspective: Points when note needs to be hit and when the note appears are now in sync

Game perspective: Visual latency is compensated by shifting the visual representation of the map so notes appear earlier than they really are

[peppy]

Let me attempt to set you in the right direction, but this will be my last reply (as I have already said, offsets are hard and I don't have the time to attempt to explain this for the nth time here – it's something you'll need to come to terms with):

You are proposing visuals are forced to appear sooner, which means the song is already at a point in the future. So what happens when the user hits? The hitsounds cannot be played in the past – the point where it needs to be played has already elapsed.

I'm sure there's a term for this, but let's go with "chronologically impossible". Other games that provide visual offsets only do so because they either

• don't have hitsounds
• silence hitsounds when in effect

The true solution here is to fix what is causing latency, not adjust to it.

[LastExceed]

Peppy has a point, but unfortunately he made a very confusing mistake: The problem in this case is not hitsounds but hitanimations.

hitsounds become a problem when you change the audio offset. you can observe this in stable, when you let autoplay play a map with a global offset you will hear that the hitsounds don't line up with the music. This is why many players turn off either global offset or hitsounds entirely.

When using a visual offset you have the same problem but with the animations. To get an idea what that would look like, here's a video from StepMania: https://youtu.be/iaqs6uQg1JI

While the option does allow re-aligning the point in time where the display shows the notes reaching the receptors with the point in time where you hear the beat and need to press a button (assuming you have already synchronized those two with each other using audio offset), the receptor highlighting will still show up late (since we can't send the signal back in time), the notes will disappear too late, and long notes have this wonky teleport effect.

If you want to go to full circle we'd also need the third and last component "input offset" (shifting judgement windows in time), as the keyboard too can have input latency. However it is technically not necessary to have all 3 options (audio/video/input offset) as each one is effectively a combination of the other two.

I agree that one should always try to minimize latency rather than compensating it, but sometimes we're simply limited by the hardware we have. I have throughout the years experienced all three at some point:

• keyboards with awful input latency (eg my laptop's internal keyboard easily has 30ms+ input latency because cheap garbage)
• displays with long reaction times (unfortunately not every TV has a "gaming mode")
• speakers with high audio latency (eg my headset's audio latency increases by 12ms when i connect it over usb instead of aux)

Granted this usually means the hardware (or driver) sucks, but we can't reasonably expect the player to buy new hardware just for osu!. Compensating with side effects is still better than not being able to address the issue at all.

[DeenyBoi]

I'm back and I think i found the solution to the first problem https://youtu.be/PXoJIrueUGY and for the visual offset thing: the notes falling will still be the same, but displays the score once after (or on) the keypress. i dont know if i explained it correctly :/

[LastExceed]

The video shows a strong visual delay, but it seems to be constant (increasing the scroll speed doesnt change it, it just makes it more apparent). However visual delay is usually caused by the monitor and thus shouldn't be visible in a recording (unless you point a real camera to a screen , which you didn't). Idk what causes this, but this is definitely something that needs to be fixed rather than compensated.

Playing in windowed mode can cause a bit of visual delay due to buffering in the dwm, but i shouldn't be this bad. Still, if you were playing windowed, try exclusive fullscreen just to be sure (and use auto-play for more accurate visuals)