Slider bodies doesn't appear in gameplay

[hazelcode]

Type

Game behaviour

Bug description

Environment

Android 16

Explanation

The sliders doesnt appear in gameplay for a strange reason. I open the game and start playing osu!, tested both lazer and argon skins and same result. This happens on the latest version 2026.804.2-lazer, yesterday I've played without this issue, this happens on this new release.

I've noticed of #38411 but still present...

Screenshots or videos

Bug report video

Version

2026.804.2-lazer

Logs

compressed-logs.zip

[bdach]

It works on my device so it's probably something to do with specific vendors / chipsets, and I have no answer to that other than reverting ppy/osu-framework#6776 wholesale. cc @EVAST9919

At least in the log attached the device is claiming to support the GL_EXT_color_buffer_float extension which is supposed to be pulling in the R32f format. In practice, no clue.

[bdach]

Possibly the cause is missing GL_OES_texture_float_linear extension. Waiting for more data points to definitively confirm. (edit: almost definitely true, 3 users reporting this broken don't have that extension, 2 users reporting this not broken do have that extension)

Apparently extensions are so modular that some chipsets can support R32f textures but not linearly sampling them.

[EVAST9919]

By reverting ppy/osu-framework#6776 we are bringing back aliasing in path self-intersections.
By reverting ppy/osu-framework#6767 we are bringing back aliasing in all cases.
So I'm thinking if we are going to revert stuff it's probably better to just go back to pre ppy/osu-framework#6658 (depth buffer approach). Worked for everyone for ages. Performance will be worse due to increased vertex count per path but oh well. Still better than stable though due to optimizations in ppy/osu-framework#6603.
I can't think of any other approach at least for now and I'm not knowledgeable enough (read at all) about GL extensions and whatnot.

Edit: branch with a revert is ready and can be pr'd if needed.

[bdach]

Edit: branch with a revert is ready and can be pr'd if needed.

Don't see any other options remaining at this point so you might as well.

[smoogipoo]

Can we try using half-precision textures? I.e. R16f.

At least in OPs case here, texture_half_float_linear is supported.

[bdach]

Half precision would not be any improvement over the 16-bit depth buffer that the revert option uses, presumably (and compatibility wise depth buffer wins because it doesn't need any extensions). But @EVAST9919 can test and see if so inclined.

[EVAST9919]

The only reason I would like to keep the SDF approach if possible due to noticeable performance win in comparison with the depth buffer one since we can reduce vertex count by a lot. Though it only has noticeable effect on constant redraw such as snaking/moving/scaling and with stupidly abused ones (aka aspire). Here's a performance/visual comparison between the 3:

master (R32f)	R16F	Depth Buffer

There's no perceivable difference between R32f and R16f. Depth buffer version looks smoother due to the whole slider being linearly filtered upon drawing whereas with current approach only path texture strip is being filtered.
Can proceed with any approach but if you were asked me then I'd like to try half-float version first (also least intrusive) and if there are still affected users - full revert due to the lack of choices.

[bdach]

I guess half can be tried if nobody else is against it.