Bug Report: "Sick" hit window feels offset

[Dorentix]

basically when you hit what's on the left you get a "good" but when you hit what's on right you get "sick!!" (image recreated from memory)

[JackXson-Real]

I reported this in #2877 , they thought I was insane, but it’s real

[JackXson-Real]

Also thanks for the visualization, it was hard to describe with only words

[Hundrec]

Good to have confirmation on this issue.
Can someone post a slowed down video that rigorously tests the Sick offset?

[JackXson-Real]

Good to have confirmation on this issue. Can someone post a slowed down video that rigorously tests the Sick offset?

I’ll make one tomorrow

[Dorentix]

bug.mp4

game and video recorded in 144 fps

[Hundrec]

Great demonstration, thank you!

Can you send the same video with the score counter showing? I'm curious how many points you're getting per note.

[Dorentix]

here's fullscreen

bug.fullscreen.mp4

[Dorentix]

also the first image is not very accurate but it explains the point

[Hundrec]

Thanks for the videos!

I just tested this and replicated the issue.

It looks to me like a visually perfect hit (arrow on arrow) is scored perfectly (500 points), but the window is tighter above the arrow and looser below the arrow.

I must not have noticed this before due to my own input delay, but this should definitely be addressed for better input accuracy.

[JackXson-Real]

I wonder if this happens because the strum line is visually positioned higher than the code for the hit windows checks for?

[Hundrec]

I wonder if this happens because the strum line is visually positioned higher than the code for the hit windows checks for?

This is probably the cause, but I have no idea what part of the code handles the placement of the hit window

If someone finds it, please send it here!

[Dorentix]

it might be this? idk much about coding but this is my suggestion

Funkin/source/funkin/play/notes/Strumline.hx

Line 30 in 27bf88c

static final INITIAL_OFFSET = -0.275 * STRUMLINE_SIZE;

[Hundrec]

That looks like the one! I'll see if I can run the game without that strumline offset.

[Hundrec]

After testing, INITIAL_OFFSET does change the position of the strumline (and not the notes themselves).

However, a few things broke when I removed the offset, so it may take a bit of fine-tuning to find the right placement for the strumline.

This image was when I removed the offset for x rather than y (whoops!)

Alternatively (and probably preferably), we could just move the hit window itself a little higher.

[EliteMasterEric]

@DoReNtOs If you can reliably reproduce this, can you try going into Options -> Input Offsets and changing your visual offsets, and see if it improves after doing that?

After testing, INITIAL_OFFSET does change the position of the strumline (and not the notes themselves).

@Hundrec This is incorrect, the notes themselves are affected by the INITIAL_OFFSET, see below:

Funkin/source/funkin/play/notes/Strumline.hx

Line 359 in 27bf88c

note.y = this.y - INITIAL_OFFSET + calculateNoteYPos(note.strumTime, vwoosh);

[Hundrec]

Ah, thanks for the clarification!

Good thing their positions are handled together.

[lemz1]

I was able to test something.
Input Offset 160ms
Visual Offset 0ms

Input.Offset.Test.mp4

Notice how if I press just a little bit above the strum it counts as a miss, which is correct behaviour. However, the judgement is still Sick, even though it would need to be Shit, since I would have hit the note just barely.

Meaning somewhere here should be the problem:

function goodNoteHit(note:NoteSprite, input:PreciseInputEvent):Void
  {
    // Calculate the input latency (do this as late as possible).
    // trace('Compare: ${PreciseInputManager.getCurrentTimestamp()} - ${input.timestamp}');
    var inputLatencyNs:Int64 = PreciseInputManager.getCurrentTimestamp() - input.timestamp;
    var inputLatencyMs:Float = inputLatencyNs.toFloat() / Constants.NS_PER_MS;
    // trace('Input: ${daNote.noteData.getDirectionName()} pressed ${inputLatencyMs}ms ago!');

    // Get the offset and compensate for input latency.
    // Round inward (trim remainder) for consistency.
    var noteDiff:Int = Std.int(Conductor.instance.songPosition - note.noteData.time - inputLatencyMs);

    var score = Scoring.scoreNote(noteDiff, PBOT1);
    var daRating = Scoring.judgeNote(noteDiff, PBOT1);
    
    ...

I guess just adding Conductor.instance.inputOffset to the noteDiff, should fix it.

var noteDiff:Int = Std.int(Conductor.instance.songPosition - note.noteData.time - inputLatencyMs + Conductor.instance.inputOffset);

[lemz1]

just tried this and it seems to fix it.
im just gonna open a pr and link it to this issue.

[Dorentix]

@DoReNtOs If you can reliably reproduce this, can you try going into Options -> Input Offsets and changing your visual offsets, and see if it improves after doing that?

I just tried trying getting a perfect score from a hit (500 point) with visual offset set to 100 and -100, and it doesn't affect the hit window. I still needed to hit a little lower than strumline to get 500 points

[Dorentix]

Made something
I made a chart with 0.5x scroll speed and recorded opponent hitting the note (because I think opponent always hits the notes for 500 points) in 144 fps, and here's what I did

First image shows note 2 frames before it being hit, and the second image show note 1 frame before it being hit (the next frame is note being hit)

So I added the lines to show off something

Blue lines are the tips of the strum
Green lines are the tips of the note 1 frame before being hit
Orange lines are the tips of the note 2 frames before being hit

I took the distance between green and orange lines, and added this distance above them, to show the LATEST (because note hit could have happened before, but couldn't be shown before the next frame) position of the tips of the note being hit

If the opponent doesn't hit notes perfectly (very unlikely) then all I wrote in this comment makes no sense

Also the strum is vertically longer than the notes themselves

[Dorentix]

@DoReNtOs If you can reliably reproduce this, can you try going into Options -> Input Offsets and changing your visual offsets, and see if it improves after doing that?

I just tried trying getting a perfect score from a hit (500 point) with visual offset set to 100 and -100, and it doesn't affect the hit window. I still needed to hit a little lower than strumline to get 500 points

By the way, input offset doesn't change anything either. You still need to press in one exact position to get 500 points

[Dorentix]

So this means that the problem with hit window being tighter on top and looser below is caused by strumline being longer than the notes and slightly above, and player percepting it like that, and not with timing or something, because

The game's code specifies hit windows based on percentages. Unless there's another section of code offsetting the window, it's treating early and late inputs equally.

[Dorentix]

That means that the REAL solution to this issue is to tweak strumline's sprites a little so they match the actual notes, and move it a little lower. But AFAIK devs don't accept pull requests with fan-made or edited official art

[Hundrec]

Thanks for the super detailed analysis! I'd like to see what the devs think about this and which solution they like best.

[EliteMasterEric]

But AFAIK devs don't accept pull requests with fan-made or edited official art

This has been a very interesting thread so far.

For the record, we will consider approving minor tweaks to the official art such as positioning fixes, but not "meaningful" fixes like adding new sprites.

[Dorentix]

I think that notes are manually sized in the code so they are smaller than strums

[Hundrec]

This is still a thing, right?
Has anyone found a solution to this yet?