Smoothed cursor trail #626
Conversation
There was a problem hiding this comment.
I don't think this should be done in general. The only reason you need to consider movements across multiple pixels, is that the standard input handler only provides pixel-accurate coordinates. Raw input will for instance not run into this issue, because it will give accurate sub-pixel coordinates.
Imho there should be some inputhandler-specific code that gives smoothly interpolated coords rather a specialized implementation inside cursor trail.
|
For me (on wine) it happens in normal osu with raw input too. I think doing this smoothing inside the input handler will result in a few pixels of lag, at least with this implementation I did here. On the cursor trail those few pixels of lag are just not visible because the gap is filled with the cursor. They could get shown as a "ghost" line from the last actual trail position to the current real cursor position that doesn't really add the positions but instead just draws a straight line. Another improvement that could be done on the cursor trail is drawing a line instead of spawning like 20 dots, it would just look a bit different, especially with a very small or noisy particle texture. Not sure if that is really more efficient than the current implementation of having a dynamic draw vertex buffer though. |
|
What I suggested was not to replace the input handlers' coords with smoothed versions, but to additionally allow querying smoothed versions. The input handlers themselves should detect whether their resolution is much higher than the pixels or not, and should then accordingly either supply these smooth coordinates in some form similar to what you did, or by just using the raw coordinates. The main problem I have with flatout doing this for all input handlers, is that it'll be to the detriment of input handlers which actually have high-res coords. |
|
Regarding drawing cursor trails as lines instead of points: We discussed this at some point and are totally open to it. It seems like a nicer general approach in some cases; we just never got around to implement it. Shouldn't be much of a difference to the current one. Can probably make an ICursorTrail interface or an abstract class, and then implement it either via point samples or a piecewise-linear (or cubic or whatever) curve. |
|
Hm right, an additional input handler is a good idea. I'm not sure about how to implement finding out if it is a HD input. Just checking if the x/y has a fraction might not be accurate if the entire coordinate system of the input is moved by for example 0.5,0.5 - Checking for varying fractions is a possibility but that should only be done in the first few events of movement or just when not in gameplay, a fps slowdown by mouse resolution calculation is something that shouldn't happen. I don't think occasional false results are a problem though considering this is purely aesthetic. |
|
Hm I checked through the code now and I would either need to add a state variable in input manager that keeps track of the last "corner position" or I would need to extend IMouseState. Both options don't really sound that great to me. Maybe adding a helper class which just takes the mouse position from the mouse event and constructs the other events out of that would be a better idea instead of adding this into the input manager. Also it doesn't feel general enough to be added as event to Drawable and be added in InputManager, I don't see any other use case than cursor trail right now either, maybe for storing the pointer data in replays more efficiently but that's all I can think of. Should the helper class be added to osu or to osu-framework? |
|
Closing this as it has been superseded by ppy/osu-framework#641 (which will require a different osu-side implementation than this). |
Before:
After:
It basically only adds a position now after a threshold of 10 pixels has been reached. If the user moves the cursor back or too far up or down (about ±20 degrees relative to the current direction) it will place another position there to, to ensure that corners are properly drawn.