Saving a legacy beatmap truncates decimal instead of rounding

[peppy]

Raising from issue because rounding does seem like what we probably want (and would fix the issue mentioned by the user).

Is there a reason we're truncating instead?

Discussed in #31237

^{Originally posted by cihe13375 December 22, 2024}
An advantage of lazer is the support of decimal coordinates. However, since stable does not support it, these decimals must be converted into integers before uploading (and that seems to be the case for the lazer map submission system too ppy/osu-server-beatmap-submission#1). However, currently there are two issues related to the conversion:

1. currently the conversion is done by truncating the decimal parts instead of rounding (e.g. 13.99 -> 13, not 14). It introduces at most 1x1 pixel of error on a single object, and 2x2 for the relative location of two objects. I think it makes more sense to round the numbers instead, which means the maximum error is halved. Sometimes my map get mods saying the geometrical patterns being 1~2 pixels off, and I think this is one of the reasons.
2. for some reason, sometimes objects that supposed to perfectly overlap are not really being so. For example try this:
   1. create a new map and set stack leniency to 0
   2. create a circle at (512,384) by first creating an object at anywhere and drag to the right bottom
   3. save
   4. select the circle tool, move cursor to the first circle and make sure the display indicates that the new circle would perfectly overlap with the first circle, and click to place it down
   5. save
   6. edit externally

and I found that the position of two circle are like this:

[HitObjects]
512,384,0,5,0,1:0:0:0:
512,383.99994,62.5,1,0,1:0:0:0:

note that the y coordinates are 0.00006 off. It's fine by itself, but due to the truncation it's possible that they will be 1 pixel off after compatibility export (100% happening in the current case because of the issue 1). This also happens in other cases, e.g. two objects snapped to the same grid point.

Furthermore, I believe some mappers don't like their notes being randomly moved by 0~1 pixel when uploading (e.g. #29907). So maybe it's useful to add a mode where objects are allowed only on integer coordinates. This could also help alleviate the two issues above.

[bdach]

I had this on my private todo list to look into as part of bss stuff but I guess issue works.

Is there a reason we're truncating instead?

Probably https://github.com/peppy/osu-stable-reference/blob/2280c4c436f80d04f9c79d3c905db00ac2902273/osu!/GameplayElements/HitObjectManager_LoadSave.cs#L837-L838.

But I do agree that in a compatibility export context we can probably afford to round, and leave the decoder flooring unchanged.