Snaking sliders initial implementation.

[Bigpet]

regarding #133

Not ready for merging yet (mmsliders needs to be optimized). This is mainly for discussion around things like the pop-in of "repeat" arrows and other complications.

Draws curves in a range from 0 to x (where x is a value between 0 and 1), instead of always drawing the full curve

[itdelatrisu]

Oh wow, that was fast, thanks!

The repeat arrows in osu! seem to fade in after the curve is fully faded in/expanded, and very quickly (around 100-200ms, but it's kind of hard to tell). The ticks also seem to fade in at the same rate/time as the repeat arrows -- though maybe starting around 50ms later (again, it's hard to tell). While you're at it, if you want, the ticks also get scaled from half size to full size while fading in, and with the AnimationEquation.OUT_BACK easing. Everything else looks fine to me.

There should be an on/off flag in the game options for this, so just add this line:

SNAKING_SLIDERS ("Snaking sliders", "SnakingSliders", "Sliders gradually snake out from their starting point.\nThis should run fine unless you have a low-end PC.", true),

And I'd add it right below the IGNORE_BEATMAP_SKINS option in OptionsMenu.java.

Lastly, I've just been calling every [0,1] parameter t, and I'd clamp all the drawUpTo definitions to the interval be safe. There's also a Javadoc warning on CurveRenderState.java:84 in a @link tag since you changed a method signature.

[Bigpet]

I'm not so sure about the performance impact with optimizations.

It might be a toss up or a trade-off. Since now the spike in draw calls when a new curve is rendered is lessened a bit (since the whole curve does not need to be drawn in 1 frame), but there is more frames in which the framebuffer needs to be switched to draw the next few segments of the slider.

(btw. I still need to do some cleanup and the return arrow blend in, so not ready for merging)

[itdelatrisu]

Do you think performance will actually be an issue? And I don't think it's much of a problem anyway, since we'll have the on/off switch.

Let me know if there's any part of this you want me to do, too.

[Bigpet]

@itdelatrisu no, I don't think performance will be an issue, hence my comment. I was just trying to say that "This should run fine unless you have a low-end PC" might be inaccurate and there might actually be some more stuttering without snaking slider in some cases.

[itdelatrisu]

Oh, sorry, I misread that then. We can take that line out; I just copied the text from osu!.

[Bigpet]

Alright, I think I got the most important things down.

You can start reviewing I guess.

Just one question, do you want
0.5f + 0.5f*AnimationEquation.OUT_BACK.calc(decorationsAlpha); or AnimationEquation.OUT_BACK.calc(0.5f+0.5f*decorationsAlpha); ?

Also, I might have asked this once already, but do you prefer things squashed into one commit?

edit: oh and I set the blend-in for ticks and return arrows as twice as fast as fadeInTime for now to test it

[itdelatrisu]

I think it looks good. I'd just rewrite the tick code to avoid recalculating values:

        if (ticksT != null) {
            float tickScale = 0.5f + 0.5f * AnimationEquation.OUT_BACK.calc(decorationsAlpha);
            Image tick = GameImage.SLIDER_TICK.getImage().getScaledCopy(tickScale);
            Colors.WHITE_FADE.a = decorationsAlpha;
            for (int i = 0; i < ticksT.length; i++) {
                Vec2f c = curve.pointAt(ticksT[i]);
                tick.drawCentered(c.x, c.y, Colors.WHITE_FADE);
            }
            Colors.WHITE_FADE.a = alpha;
        }

I don't really care if you squash or not. I'll merge this shortly if you're done. Thanks for doing this!

[Bigpet]

@itdelatrisu yeah, I think that should be it for now.