Bartłomiej Dach
de97660fa4
Probably closes https://github.com/ppy/osu/issues/36492. This is dumb but it's in large part my stupidity. To begin with, the immediate direct offending call that causes the observed symptoms is https://github.com/ppy/osu/blob/a401c7d5e9d6d8b05b2ec293145ad308dfe9d6d0/osu.Game/Screens/Edit/Components/FormSampleSet.cs#L296 The reason why this "invalidation" affects sample volume is that in the framework implementation, the call [removes the relevant sample factory from the sample store which is an audio component](https://github.com/ppy/osu-framework/blob/5b716dcbef6f99e03188a7a7706361fa8445c754/osu.Framework/Audio/Sample/SampleStore.cs#L65-L72). In the process it also [unbinds audio adjustments](https://github.com/ppy/osu-framework/blob/5b716dcbef6f99e03188a7a7706361fa8445c754/osu.Framework/Audio/AudioCollectionManager.cs#L37-L38), which *would* have the effect of resetting the sample volume to 100%, effectively (and I've pretty much confirmed that that's what happens). Now for why this call sometimes does the right thing and sometimes doesn't: Sometimes the call is made in response to an *actual* change to the beatmap skin, which is correct and expected, if very indirect, but sometimes it is made *over-eagerly* when there is no reason to recycle anything yet. One such circumstance is entering the setup screen, which will still "invalidate" (read: remove) the samples, but the compose tab hasn't seen any change to the beatmap skin, so when it is returned to, it has no reason to retrieve the sample again, and as such it will try to play samples which are for better or worse in a completely undefined state because they're not supposed to be *in use* anymore. Therefore, the right thing here would seem to be to take the responsibility of invalidation from a random component, and move it to a place that's *actually* correlated to every other component needing to recycle samples, e.g. `EditorBeatmapSkin` responding to changes in the beatmap resources via raising `BeatmapSkinChanged`. Unfortunately, because of the structure of everything, this recycle needs to go from targeted to individual samples, to nuking the entire store. The reason for this is that `RealmBackedResourceStore` does not provide information as to *what* resources changed, it just says that *the set of them* did. For the recycle to be smarter, `EditorBeatmapSkin` would need to know not only which samples were added or replaced, but also which ones were *removed*, so that users don't hear phantom samples that no longer exist in the editor later. That would however be a lot of hassle for nothing, so I just recycle everything here and hope it won't matter. As to why I could only reproduce this on this one beatmap - I'm not super sure. The failure does not seem to be specific to beatmaps, but it may be exacerbated by certain patterns of accessing samples which means that beatmaps with high BPM like the one I managed to reproduce this on may just be more susceptible to this. As a final note, I do realise that this is not fundamentally improving the surrounding systems and it's still a pretty rickety thing to do. It's still on the consumers to know and respond to the sample store recycle and this is likely to fail if a consumer ever doesn't. That said, I have no brighter ideas at this point in time that won't involve me spending a week refactoring audio.
osu!
A free-to-win rhythm game. Rhythm is just a click away!
This is the future – and final – iteration of the osu! game client which marks the beginning of an open era! Currently known by and released under the release codename "lazer". As in sharper than cutting-edge.
Status
This project is under constant development, but we do our best to keep things in a stable state. Players are encouraged to install from a release alongside their stable osu! client. This project will continue to evolve until we eventually reach the point where most users prefer it over the previous "osu!stable" release.
A few resources are available as starting points to getting involved and understanding the project:
- Detailed release changelogs are available on the official osu! site.
- You can learn more about our approach to project management.
- Track our current efforts towards improving the game.
Running osu!
If you are just looking to give the game a whirl, you can grab the latest release for your platform:
Latest release:
| Windows 10+ (x64) | macOS 12+ (Intel, Apple Silicon) | Linux (x64) | iOS 13.4+ | Android 5+ |
|---|
You can also generally download a version for your current device from the osu! site.
If your platform is unsupported or not listed above, there is still a chance you can run the release or manually build it by following the instructions below.
For iOS/iPadOS users: The iOS testflight link fills up very fast (Apple has a hard limit of 10,000 users). We reset it occasionally. Please do not ask about this. Check back regularly for link resets or follow peppy on twitter for announcements. Our goal is to get the game on mobile app stores very soon so we don't have to live with this limitation.
Developing a custom ruleset
osu! is designed to allow user-created gameplay variations, called "rulesets". Building one of these allows a developer to harness the power of the osu! beatmap library, game engine, and general UX for a new style of gameplay. To get started working on a ruleset, we have some templates available here.
You can see some examples of custom rulesets by visiting the custom ruleset directory.
Developing osu!
Prerequisites
Please make sure you have the following prerequisites:
- A desktop platform with the .NET 8.0 SDK installed.
When working with the codebase, we recommend using an IDE with intelligent code completion and syntax highlighting, such as the latest version of Visual Studio, JetBrains Rider, or Visual Studio Code with the EditorConfig and C# Dev Kit plugin installed.
Downloading the source code
Clone the repository:
git clone https://github.com/ppy/osu
cd osu
To update the source code to the latest commit, run the following command inside the osu directory:
git pull
Building
From an IDE
You should load the solution via one of the platform-specific .slnf files, rather than the main .sln. This will reduce dependencies and hide platforms that you don't care about. Valid .slnf files are:
osu.Desktop.slnf(most common)osu.Android.slnfosu.iOS.slnf
Run configurations for the recommended IDEs (listed above) are included. You should use the provided Build/Run functionality of your IDE to get things going. When testing or building new components, it's highly encouraged you use the osu! (Tests) project/configuration. More information on this is provided below.
To build for mobile platforms, you will likely need to run sudo dotnet workload restore if you haven't done so previously. This will install Android/iOS tooling required to complete the build.
From CLI
You can also build and run osu! from the command-line with a single command:
dotnet run --project osu.Desktop
When running locally to do any kind of performance testing, make sure to add -c Release to the build command, as the overhead of running with the default Debug configuration can be large (especially when testing with local framework modifications as below).
If the build fails, try to restore NuGet packages with dotnet restore.
Testing with resource/framework modifications
Sometimes it may be necessary to cross-test changes in osu-resources or osu-framework. This can be quickly achieved using included commands:
Windows:
UseLocalFramework.ps1
UseLocalResources.ps1
macOS / Linux:
UseLocalFramework.sh
UseLocalResources.sh
Note that these commands assume you have the relevant project(s) checked out in adjacent directories:
|- osu // this repository
|- osu-framework
|- osu-resources
Code analysis
Before committing your code, please run a code formatter. This can be achieved by running dotnet format in the command line, or using the Format code command in your IDE.
We have adopted some cross-platform, compiler integrated analyzers. They can provide warnings when you are editing, building inside IDE or from command line, as-if they are provided by the compiler itself.
JetBrains ReSharper InspectCode is also used for wider rule sets. You can run it from PowerShell with .\InspectCode.ps1. Alternatively, you can install ReSharper or use Rider to get inline support in your IDE of choice.
Contributing
When it comes to contributing to the project, the two main things you can do to help out are reporting issues and submitting pull requests. Please refer to the contributing guidelines to understand how to help in the most effective way possible.
If you wish to help with localisation efforts, head over to crowdin.
We love to reward quality contributions. If you have made a large contribution, or are a regular contributor, you are welcome to submit an expense via opencollective. If you have any questions, feel free to reach out to peppy before doing so.
Licence
osu!'s code and framework are licensed under the MIT licence. Please see the licence file for more information. tl;dr you can do whatever you want as long as you include the original copyright and license notice in any copy of the software/source.
Please note that this does not cover the usage of the "osu!" or "ppy" branding in any software, resources, advertising or promotion, as this is protected by trademark law.
Please also note that game resources are covered by a separate licence. Please see the ppy/osu-resources repository for clarifications.