26 Commits

• Fix replays being misrecorded if an action is pressed and released in one update frame

  Closes https://github.com/ppy/osu/issues/33465 probably.
  
  This reverts the replay frame de-duplication logic to what it was before
  https://github.com/ppy/osu/pull/33148#discussion_r2091549388.
  
  I don't have good reproduction steps. I tried to write a test case for
  this that isn't just "press and release a key in the same frame",
  thinking that maybe there was some loophole in the osu! touch input
  mapper that may produce this situation artificially, but I could not in
  many configurations. So I have to assume that this just *can happen*
  organically.

  Bartłomiej Dach · 2025-06-06 09:10:51 +02:00
  12cc8e38da
• Also perform time-based frame de-duplication at frame bundle level

  See https://github.com/ppy/osu/pull/33148#discussion_r2092467082

  Bartłomiej Dach · 2025-05-16 09:39:29 +02:00
  baf069ccf7
• Do not emit multiple consequent replay frames with the exact same data

  With judgements occurring forcing emission of important frames, there's
  the question of emitting redundant frames. In a majority of cases
  still, a judgement *will* be tied to a specific user input, which means
  that there's a high likelihood of duplicate frames, as one will be
  emitted by the input change, and another by the judgement.
  
  To a degree this is a pre-existing issue. The replay recording code
  responds to both mouse movement and key presses by recording frames, so
  depending on the intrinsic (basically undefined) ordering between
  handling mouse move and key presses, it was possible for multiple frames
  to be emitted with the same timestamp to the replay, each containing
  partial input state changes (e.g. first frame with mouse position
  changed, and the second with a key pressed).
  
  The extent to which this increases the frame count will obviously depend
  on the beatmap, but in my ballpark testing across all rulesets on a
  single "relatively standard" beatmap (think no aspire chicanery), around
  4-10% of frames can end up being duplicates / not meaningful. This has
  implications both on replay size and on playback performance.
  
  This commit therefore performs de-duplication of the frames based on
  timestamp - only the last frame with a given timestamp ends up in the
  final replay.
  
  The CPU cost of this is negligible to the point of not being useful to
  profile - it's a single condition gated behind a single float comparison

  Bartłomiej Dach · 2025-05-16 08:40:07 +02:00
  cd4ab9307c
• Emit important replay frames on every judgement

  - Closes https://github.com/ppy/osu/issues/4287
  - Probably closes https://github.com/ppy/osu/issues/25405 (but not
    retroactively)
  
  Up until now, whether or not a replay frame is emitted depended solely
  on the user's input, i.e. mouse movement or key presses/releases. This,
  intersected with the replay playback system which is given allowance to
  perform interpolation between replay frames, leads to potential
  situations wherein a replay can play inaccurately when a judgement takes
  place without user input meaningfully changing. One such case is slider
  ends with their 36ms of judgement leniency; see
  https://github.com/ppy/osu/issues/25405#issuecomment-2879031106 for
  details on that.
  
  To that end, this commit aims to counteract that issue by *forcing* an
  important replay frame to be emitted on every new judgement recorded
  during gameplay. This will only benefit rulesets wherein judgements can
  occur that are not inherently tied to user input changing, which are
  going to be osu! as mentioned above, and maybe possibly catch. I don't
  foresee this doing anything relevant for taiko or mania.

  Bartłomiej Dach · 2025-05-15 11:43:09 +02:00
  9f91c2e25c
• Remove unnecessary replay recorder depth hack

  Addresses https://github.com/ppy/osu/pull/33102#discussion_r2087963889.

  Bartłomiej Dach · 2025-05-14 11:25:31 +02:00
  acebf3e95e
• Fix rate adjustments changing the spacing between replay frames
  Dean Herbert · 2025-01-09 13:30:04 +09:00
  c8f72fdbe9
• Partial everything
  Dan Balasescu · 2022-11-27 00:00:27 +09:00
  7bc8908ca9
• Move spectator begin/end playing to SubmittingPlayer
  Dan Balasescu · 2022-07-28 20:44:04 +09:00
  ce694123eb
• Automated #nullable processing
  Dan Balasescu · 2022-06-17 16:37:17 +09:00
  f8830c6850
• Remove unused using
  Dan Balasescu · 2022-02-10 14:22:08 +09:00
  ebd105422f
• Simplify disposal
  Dan Balasescu · 2022-02-10 14:21:51 +09:00
  f7fb7825cc
• Remove allowance of null dependency
  Dan Balasescu · 2022-02-10 14:21:50 +09:00
  a3896a8ebd
• Give SpectatorState a user state
  Dan Balasescu · 2022-02-01 21:51:05 +09:00
  41007169f7
• Replace all basic usages
  Dean Herbert · 2021-10-02 02:22:23 +09:00
  32afd3f426
• Update with keybinding changes
  smoogipoo · 2021-09-16 18:26:12 +09:00
  f9d5abff8a
• Rename SpectatorStreamingClient -> SpectatorClient
  smoogipoo · 2021-05-20 15:55:07 +09:00
  6beeb7f7c4
• Record every 60fps interval
  smoogipoo · 2021-04-16 19:42:44 +09:00
  d26fa46ef2
• Add header class and basic flow for propagating data updates
  Dean Herbert · 2020-12-14 17:33:23 +09:00
  64a2526678
• Pass a score to the replay recorder to allow reading more general scoring data
  Dean Herbert · 2020-12-14 16:52:14 +09:00
  1793385e96
• Fix mania crashing due to spectator client handling frames with unconverted beatmap
  Bartłomiej Dach · 2020-10-27 00:35:25 +01:00
  7392876b5f
• Add spectator state object support
  Dean Herbert · 2020-10-22 17:48:15 +09:00
  05697dfe68
• Add begin/end session logic
  Dean Herbert · 2020-10-22 17:48:15 +09:00
  96049c39c9
• Send frames to streaming client from replay recorder
  Dean Herbert · 2020-10-22 17:48:15 +09:00
  175fd512b0
• Fix catch positional data being incorrectly recorded
  Dean Herbert · 2020-03-24 15:38:54 +09:00
  388cf5c83a
• Add proper screen space - gamefield mapping
  Dean Herbert · 2020-03-23 20:06:18 +09:00
  14a85a84bf
• Move replay recorder to final location
  Dean Herbert · 2020-03-23 20:04:15 +09:00
  6d48068061