forum

Wrong sampleset sometimes used

posted
Total Posts
12
Topic Starter
mm201
If a note is placed close to a sampleset-changing timing section, it will sound the wrong sampleset if the player has poor timing or machine lag occurs.

The obvious workaround of not placing sampleset changes close to notes fails if there is either/both a long, fast stream of notes during the change or if there are many changes to set different samplesets for notes close together.

Offenders include Spice Girls - Goodbye, April Harmony - Survivor, and Hatsune Miku - Aka Hinoha.

Ideally, the sampleset/volume choice for a hitcircle should be determined by which section it lies within rather than which section is currently active. If a note lies exactly on a sampleset change (bad practice), it should use the newly set sampleset to maintain the current (usual) behaviour in those circumstances.
peppy
Already on my list of things to consider at some point. Will require a fair amount of restructuring. At the moment there is already 50ms leeway on sample changes, so you really have to suck to hear the wrong one.
Topic Starter
mm201
How does this "50ms leeway" work? Is it just a constant offset to the sampleset changes, or is it applying magic to make the right sample hit even if the user is 50ms late?

If it's the former, then that could be part of what's causing the problems, since a mapper will usually place the sampleset change exactly between two notes. 1/4s at 120bpm are 125ms apart. A 50ms offset would mean there's only a 75ms tolerance on one side, but a 175ms tolerance on the other.
Echo
I think by 50ms peppy just means that even if you hit the note 50ms earlier, it'll still come out with the right effect.
anonymous_old

MetalMario201 wrote:

How does this "50ms leeway" work? Is it just a constant offset to the sampleset changes, or is it applying magic to make the right sample hit even if the user is 50ms late?

If it's the former, then that could be part of what's causing the problems, since a mapper will usually place the sampleset change exactly between two notes. 1/4s at 120bpm are 125ms apart. A 50ms offset would mean there's only a 75ms tolerance on one side, but a 175ms tolerance on the other.
I think what peppy meant was this:

When a timing section asks for a sample change, the sample is loaded. When the game is playing a map, it looks 50 ms ahead to see if any loading needs to be done due to timing sections. If so, the new samples are loaded.

Thus, if you hit a note 51 ms before the timing section (and thus 1 ms before the preload) you'll get the old sample. Anything at or after 50ms before would have the new sample.

Major problems would occur if timing sections and hits were less than 50 ms apart, but I doubt that'd happen in any (ranked) map. (I haven't looked at the maps in question yet, though, so something else may be up.)
Echo
This map has been deleted on the request of its creator. It is no longer available.
peppy
Echo is of course correct, as I optimise to the maximum and he knows it.
Topic Starter
mm201
"Constant offset to the sampleset changes" it is then.

Then the bug would be that instead of calling .Get(int time), there should be a new function along the lines of .GetLastSectionBeforeHitObject(HitObject object)

And this +50 could make the problem worse in cases like I mentioned in my last post, favouring clicking early at the cost of clicking late.
peppy
uhuh
FurukawaPan
It's *mostly* human nature to tend toward clicking early anyway, especially when the player is less confident about their timing. Notes also sound "less wrong" when early, as compared to late, when persons are more likely to perceive their lateness.

I think it's a smart choice, actually, and nothing that should be changed.
Echo
wouldn't it be better if you just did

void PlaySampleSound(HitObject object)
{
SampleSetType sample = Audio.TimingSections.Get(object.Time).SampleSet;
Audio.Play(Audio.Samples.Get(sample, object.Sound));
}
peppy
uhuh

for some reason when i see someone post code on the forums i don't even read it anymore >.>
Please sign in to reply.

New reply