TeamRizu / OutFox

The Bug Reporting Repository for OutFox LTS 0.4, Alpha V and Steam Early Access Builds
https://projectoutfox.com
Apache License 2.0
178 stars 3 forks source link

[BUG] [Feature Request] DTX/PMS/BM* Charts do not support non 2/3/4 based Timing Signatures due to Hardcoded 192 rows/measure #703

Open SomeWeirdDude opened 9 months ago

SomeWeirdDude commented 9 months ago

Is there an existing issue for this?

Operating System

Windows 11 Pro 22H2

CPU

No response

GPU

No response

Storage

No response

Game Version

5.0.0-041

Game Mode

be-mu

Theme

No response

Describe the problem

So, what's happening?

Essentially, I am playing the Beatmania III BMS pack from BMSWorld and some song charts will basically freeze up and stay that way, thus making them impossible to play.

https://github.com/TeamRizu/OutFox/assets/122554978/284b54f8-0ad1-4ceb-88e0-95cc5872d3a7

What the video shows:

  1. Keep On Liftin's HYPER chart freezing.
  2. Restarting to show that it freezes in the exact same spot.
  3. The same bug happening on a different chart.

An extra point I gorgot to show in the video:

As I just mentioned, I said that Keep On Liftin's HYPER chart keeps freezing. However, if you play it's other chart, the bug doesn't happen.

A theory on what the problem could be (not certain) I think that this could simply be a BMS parsing bug.

In general, most BMS charts have regular time signatures, something like 4/4, 3/4, 6/4, etc. However, the BMS files in the video are apparently arcade rips of the beatmania games and these files do not have proper time signatures. So, instead of having a 4/4 time signature, they have approximations of that (Example: Keep On Liftin has time signatures that alternate between 175/174 and 695/696), which I assume doesn't play well with OF.

Also, different charts of the same song share the same time signatures, but obviously have different note data, which probably plays a role in whether this bug happens or not.

I haven't encountered this bug when playing BMS files with proper time signatures.

Describe what should happen

No response

Relevant Log output

No response

Scraticus commented 9 months ago

This one is a biggie, and requires us to rewrite most of the internals to fix... it is something we will do, but i will leave this issue open so we can reference it and work on it as we improve support.

you are quite right! if a timing signature requires us to go over 192 rows a measure, which those tight timing signatures do, we will move into 'undefined behaviour' in this case, the game thinks the song has concluded due to the 'measure' run ending, hence the freeze. If you look at the measure bars in your video, you can see the game has sadly become very confused where measures begin and end due to the row system in the game.

Our engine was built on MSD/BM98 which only needed 192 rows - this is worked out as in a normal measure, we have 48 rows available per beat x 4 beats a measure (for 4/4 timing) and this is at the moment hardcoded. For us to ensure our support for BMS-like modes is up there with raja or LR2, you are correct, we need to expand this greatly to ensure we have the fidelity of MIDI events, (192000 potential rows/measure), but this will need some serious work, as we will need to add a new pathway for the non-MSD like DDR/Dance based games.

Sorry to disappoint on this being not a quick fix, but I hope i've been transparent enough on what we need to do. Issues which get the 'Rabbit Hole' bonus shows it's going to be several months to years of work.

Thanks for reporting!