Currently, anchor points in Osu! can only be integer values. My suggestion is to not change the in-game editor at all, but to change the parsing of .osu files to allow for double-level precision values for anchor locations. This will allow those who create sliders using the .osu file directly to create much more precise sliders much more quickly. An in-depth overview of the problems at play is given below.
Only being able to place bezier control points on an integer lattice is extremely limiting. With this constraint, creating precise shapes is nearly impossible. I have created a mixed-integer linear programming optimization solution to this, but it's extremely computationally expensive to come up with anything requiring more than 40 anchor points. As whoever coded the bezier path approximator knows (this is publicly available in the osu!Lazer src), an optimal bezier approximation without integer constraints is simple to construct by using the evaluation of the desired function representing the path at evenly spaced points between 0 and 1 as the Bernstein polynomial coefficients. Such a solution even converges uniformly (and quite quickly, might I add) to the function itself. Doing this and rounding the resulting Bernstein coefficients (which make up the coordinates of all the anchor points) to integers is quite terrible, especially for small shapes, so the only way to do this is to use extremely high degree beziers with anchor points extremely far away from the origin (thousands to millions of units from the playfield). It's worth stating again how difficult it is to find these anchor points. It requires my computer (which is quite beefy) 30 minutes to find a way to represent a circle of radius 75 within 0.004 of a perfect circle at its maximum. A circle is even relatively simple to construct this way - spirals and more advanced shapes are nearly impossible.
As anyone who is familiar with Aspire 2018 will know, a large part was experimentation with accelerating sliders. This is another time where extremely small movements are required, and it's quite visible that the slider is vibrating when it's moving at its slowest. Fixing this requires tiny 'tumors' as the mapping community has come to call them, which are largely restricted currently by the fact that red anchor points must be placed on the integer lattice. To closely represent the shape, the integer lattice is simply way to granular and creates visible imperfections, particularly making what should look like a smooth curve into something which looks piecewise linear (which, of course, it is, but on a much finer scale than on an integer lattice).
The loading time for maps with fancy sliders such as these would be greatly reduced if double level precision was allowed when parsing the .osu file, as fewer recursive steps to create "flat" bezier segments would be required in general when used properly, and otherwise is just as good as what Osu! does normally anyway.
This change would not affect those using the osu! editor, but would be extremely huge for those who map using the .osu file for the reasons mentioned above. I'm currently constructing a better approximation of a circle with radius 75 using 25 control points, which is an optimization problem in over 400 dimensions and will likely require days or even weeks of constant computation to reach the optimal solution using only integer control points. Compare this to the simple bezier approximation of a continuous curve, which would take any computer less than a second to compute bezier control points within 0.00001 (likely less if desired) of the perfect curve.
Special thanks to Karoo13, OliBomby, and Voltaeyx for being other slider fanatics working on this and similar problems.
Only being able to place bezier control points on an integer lattice is extremely limiting. With this constraint, creating precise shapes is nearly impossible. I have created a mixed-integer linear programming optimization solution to this, but it's extremely computationally expensive to come up with anything requiring more than 40 anchor points. As whoever coded the bezier path approximator knows (this is publicly available in the osu!Lazer src), an optimal bezier approximation without integer constraints is simple to construct by using the evaluation of the desired function representing the path at evenly spaced points between 0 and 1 as the Bernstein polynomial coefficients. Such a solution even converges uniformly (and quite quickly, might I add) to the function itself. Doing this and rounding the resulting Bernstein coefficients (which make up the coordinates of all the anchor points) to integers is quite terrible, especially for small shapes, so the only way to do this is to use extremely high degree beziers with anchor points extremely far away from the origin (thousands to millions of units from the playfield). It's worth stating again how difficult it is to find these anchor points. It requires my computer (which is quite beefy) 30 minutes to find a way to represent a circle of radius 75 within 0.004 of a perfect circle at its maximum. A circle is even relatively simple to construct this way - spirals and more advanced shapes are nearly impossible.
As anyone who is familiar with Aspire 2018 will know, a large part was experimentation with accelerating sliders. This is another time where extremely small movements are required, and it's quite visible that the slider is vibrating when it's moving at its slowest. Fixing this requires tiny 'tumors' as the mapping community has come to call them, which are largely restricted currently by the fact that red anchor points must be placed on the integer lattice. To closely represent the shape, the integer lattice is simply way to granular and creates visible imperfections, particularly making what should look like a smooth curve into something which looks piecewise linear (which, of course, it is, but on a much finer scale than on an integer lattice).
The loading time for maps with fancy sliders such as these would be greatly reduced if double level precision was allowed when parsing the .osu file, as fewer recursive steps to create "flat" bezier segments would be required in general when used properly, and otherwise is just as good as what Osu! does normally anyway.
This change would not affect those using the osu! editor, but would be extremely huge for those who map using the .osu file for the reasons mentioned above. I'm currently constructing a better approximation of a circle with radius 75 using 25 control points, which is an optimization problem in over 400 dimensions and will likely require days or even weeks of constant computation to reach the optimal solution using only integer control points. Compare this to the simple bezier approximation of a continuous curve, which would take any computer less than a second to compute bezier control points within 0.00001 (likely less if desired) of the perfect curve.
Special thanks to Karoo13, OliBomby, and Voltaeyx for being other slider fanatics working on this and similar problems.
