Bug Report: Strums sprites are slightly different shape than the colored notes and are positioned slightly above than the middle of the hit window, leading player to percepting the hit window's position wrong

[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]

https://github.com/FunkinCrew/Funkin/assets/88308663/6d3126af-6189-4b07-9fe5-45a1c093f705

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

https://github.com/FunkinCrew/Funkin/assets/88308663/b13a0fd0-feac-4e6d-8fd4-f245847ca9b0

[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 https://github.com/FunkinCrew/Funkin/blob/27bf88c11e1a4941f1bc3663d63de8ba403c1a56/source/funkin/play/notes/Strumline.hx#L30

[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:

https://github.com/FunkinCrew/Funkin/blob/27bf88c11e1a4941f1bc3663d63de8ba403c1a56/source/funkin/play/notes/Strumline.hx#L359

[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

https://github.com/FunkinCrew/Funkin/assets/87707926/1a378317-e739-4947-ba71-36868366e17c

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?

[Lasercar]

Hmm, after getting a bunch of images, this one stood out to me: It gave a good rating for this. The note diff was 54 for this one, so no wonder why. Compared to this hit for this one, which appears further ahead but is actually closer:

Ok that's really bad:

Here's the rest of images

[Lasercar]

~~I have found a fix: https://github.com/FunkinCrew/funkin.assets/pull/142~~

Nope

[Lasercar]

I tested my change of adding an offset again, and I can now say it is not definitely not a solution.

Basically, perfect note hits aren't in the same visual spot between say, a fps of 60 and an fps of 300.

For example, an offset of 18 y, at 60 fps perfect note hits are here:

But now, at 300 fps perfect note hits are here:

If only there was a way to make it so a perfect hit is always on the mark no matter your framerate....