Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design a better beatmap format #46

Closed
fmang opened this issue Jan 20, 2018 · 1 comment
Closed

Design a better beatmap format #46

fmang opened this issue Jan 20, 2018 · 1 comment

Comments

@fmang
Copy link
Owner

fmang commented Jan 20, 2018

The format of the .osu files is silly, and sometimes I think it might be worth the effort to make a beatmap compiler.

Because compiling a beatmap doesn't require any kind of performance, this could be written in a super high and slow language, and generate a MessagePack with all the computations done. oshu! would then just load it naively.

In particular:

  • No more silly unit: use seconds or pixels, rather than stars-ish.
  • No more inheritance: keep the sample set explicit.
  • No more mystic constants: write 'clap' for clap, not 8.
  • Normalized paths, instead of keeping a separate path length.
  • Simpler arcs: one center and two angles, rather than three points.
  • Colors defined as #RRGGBB.

That format could hopefully become a candidate for a future official format!

If the MessagePack is limited to scalars, lists and maps, it might as well be JSON, YAML or whatever. The serialization in itself is irrelevant, yay. gzip could be added on top of it, if needed.

But first, I should finish my work on the .osu wiki article: ppy/osu-wiki#811

Maybe then #44 comes first still, to ensure the current parser could be used as a reference. Alternatively, this issue might become handy because comparing a serialized MessagePack with a reference result is super easy.

@fmang
Copy link
Owner Author

fmang commented Mar 15, 2018

I now feel like it's unrelated to oshu!, because we have to support the osu! beatmap format anyway. Once the parser is isolated into a simple load function, it's the same to the caller whether it's a smart format or not.

If there was a significant performance gain from pre-compiling the beatmaps, that's another story, but I don't think it'd be significant.

https://xkcd.com/927/

@fmang fmang closed this as completed Mar 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant