Closes#23862.
Score V2 is a scoring algorithm, which aside from the raw numerical
values of each judgement, incorporates a combo component, wherein each
judgement's "combo score" is derived from both the raw numerical value
of the object and the current combo after the given judgement. In
particular, this means that Score V2 is sensitive to the _order_ of
judging objects, as if two objects with the same start time are judged
using different ordering, they can end up having a different "combo
score".
The issue that this change is fixing is an instance of one such
reordering. Upon inspection, it turned out that the simulated autoplay
run, which is used to determine max possible score so that it can be
standardised to 1 million again, was processing a slider repeat before a
slider tail circle, while actual gameplay was processing the same slider
repeat _after_ the slider tail circle.
The cause of that behaviour is unfortunately due to `LegacyLastTick`.
The sliders which cause the issue are extremely short. Stable had a
behaviour, in which to provide leniency, slider tails were artificially
offset back by 36ms. However, if the slider is not long enough to make
this possible, the last tick is placed in the middle of the slider. If
that slider also happens to have exactly 1 repeat, then this means that
the last tick and the repeat have the same time instant.
Because of the time equality, what begins to matter now is the _order_
of processing the elements of the drawable slider in the hierarchy. For
the purposes of legacy skins, tail circles were moved below ticks in
fce3eacd7de3254ce75619efaa2d15d59d564623 - but in this particular case,
it means that the order of processing the slider elements is now
inadvertently inverted, causing the entire debacle.
While the fact that scoring depends on order of processing of visuals is
suboptimal, there isn't a great way to address this without significant
restructuring. Due to the structure of processing judgements currently
in place, in which each judgement is processed independently from others
by its corresponding drawable hit object, this is probably the best that
can be done for the time being at least.
Unfortunately breaks a few classes (which is fixable), and also breaks
Moq/Castle dynamic proxies (which is unfortunate).
Relevant error:
System.TypeLoadException : Method 'GetPanelBackground' in type 'Castle.Proxies.IWorkingBeatmapProxy' from assembly 'DynamicProxyGenAssembly2, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.
Stack Trace:
at System.Reflection.Emit.TypeBuilder.CreateTypeNoLock()
at System.Reflection.Emit.TypeBuilder.CreateTypeInfo()
at Castle.DynamicProxy.Generators.Emitters.AbstractTypeEmitter.BuildType()
at Castle.DynamicProxy.Generators.BaseInterfaceProxyGenerator.GenerateType(String typeName, INamingScope namingScope)
at Castle.DynamicProxy.Generators.BaseProxyGenerator.<>c__DisplayClass13_0.<GetProxyType>b__0(CacheKey cacheKey)
at Castle.Core.Internal.SynchronizedDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
at Castle.DynamicProxy.Generators.BaseProxyGenerator.GetProxyType()
at Castle.DynamicProxy.DefaultProxyBuilder.CreateInterfaceProxyTypeWithoutTarget(Type interfaceToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options)
at Castle.DynamicProxy.ProxyGenerator.CreateInterfaceProxyTypeWithoutTarget(Type interfaceToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options)
at Castle.DynamicProxy.ProxyGenerator.CreateInterfaceProxyWithoutTarget(Type interfaceToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options, IInterceptor[] interceptors)
at Moq.CastleProxyFactory.CreateProxy(Type mockType, IInterceptor interceptor, Type[] interfaces, Object[] arguments) in C:\projects\moq4\src\Moq\Interception\CastleProxyFactory.cs:line 50
In theory it would be possible to fix this via application of
[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]
onto the `osu.Game` assembly, but I think this would be bad precedent.
While `EndTime + tickSpacing` _was_ closer to what stable was using, it
could cause undesirable edge cases wherein a tick would be spawned
outside of the drum roll's duration
(see https://github.com/ppy/osu/pull/23768/files#r1222073027).
For this reason, stick with the old code for now, as it is not as
susceptible to that sort of breakage.
This is an effort to improve general performance at song select. At
least on the metal renderer, I can notice very high draw frame overheads
related to texture uploads.
By reducing the size of the texture uploads to roughly match what is
actually being displayed on screen (using a relatively inexpensive crop
operation), we can bastly reduce stuttering both during initial load and
carousel scroll.
You might ask if it's safe to disable mipmapping, but I've tested with
lower resolutions and bilinear filtering seems to handle just fine.
Bilinear without mipmaps only falls apart when you scale below 50% and
we're not going too far past that at minimum game scale, if at all.
