5fde4f2c0c
Changes to lifetime calculation in scrolling rulesets introduced in #7367, which aimed to account for the distance between hit objects' origin and its edge entering the scrolling area, fixed some issues with hitobjects appearing abruptly, but also regressed some other scenarios. Upon investigation, the regression was localised to the overlapping scroll algorithm. The reason for this was two-fold: * The previous code used TimeAt() to calculate the time of travel from the hit object's edge to its origin. For other algorithms, that time can be accurately reconstructed, because they don't have periods of time where there are multiple hit objects scrolling at different velocities. That invariant does not hold for the overlapping algorithm, therefore it is possible for different values to be technically correct for TimeAt(). However, the only value that matters for the adjustment is the one that's indicated by the control point that applies to the hit object origin, which can be uniquely identified. * Additionally, the offset returned (even if correct) was applied externally to the hit object's start time and passed to GetDisplayStartTime(). In the overlapping algorithm, the choice of control point used in GetDisplayStartTime() is important, since the value of the speed multiplier is read within. Externally rewinding the hit object's start time meant that in some cases the speed multiplier of the *previous* control point is applied, which led to hit objects appearing too late if the scrolling rate decreased. Because of the above, modify GetDisplayStartTime() to take the offset into account in all algorithms, and apply the adjustment correctly inside of them. The constant and sequential algorithms needed no adjustment from the previous logic, since: * the constant algorithm disregarded control points, and * the sequential algorithm would effectively rewind to time = 0, calculate the absolute distance from time = 0 to the hit object start, apply the origin offset *to the absolute distance*, and then convert back to time, applying all control points in sequence. Due to this it was impossible for control points to get mixed up while calculating. As for the overlapping algorithm, the high-level logic is as follows: * The distance that the origin has to travel is the length of the scroll plus the distance from the origin to the object edge. * The above distance divided by the scroll length gives the relative scroll lengths that the object has to travel. * As one relative scroll length takes one time range, the relative travel length multiplied by the time range gives the absolute travel time of the object origin. * Finally, the control point multiplier applicable at origin time is applied to the whole travel time. Correctness of the above is demonstrated by visual tests added before and headless unit tests of the algorithms themselves. The sequential scroll algorithm was not covered by unit tests, and remains uncovered due to floating-point inaccuracies that should be addressed separately. |
||
|---|---|---|
| .config | ||
| .github | ||
| .idea | ||
| .vscode | ||
| assets | ||
| build | ||
| CodeAnalysis | ||
| fastlane | ||
| osu.Android | ||
| osu.Desktop | ||
| osu.Game | ||
| osu.Game.Benchmarks | ||
| osu.Game.Rulesets.Catch | ||
| osu.Game.Rulesets.Catch.Tests | ||
| osu.Game.Rulesets.Catch.Tests.Android | ||
| osu.Game.Rulesets.Catch.Tests.iOS | ||
| osu.Game.Rulesets.Mania | ||
| osu.Game.Rulesets.Mania.Tests | ||
| osu.Game.Rulesets.Mania.Tests.Android | ||
| osu.Game.Rulesets.Mania.Tests.iOS | ||
| osu.Game.Rulesets.Osu | ||
| osu.Game.Rulesets.Osu.Tests | ||
| osu.Game.Rulesets.Osu.Tests.Android | ||
| osu.Game.Rulesets.Osu.Tests.iOS | ||
| osu.Game.Rulesets.Taiko | ||
| osu.Game.Rulesets.Taiko.Tests | ||
| osu.Game.Rulesets.Taiko.Tests.Android | ||
| osu.Game.Rulesets.Taiko.Tests.iOS | ||
| osu.Game.Tests | ||
| osu.Game.Tests.Android | ||
| osu.Game.Tests.iOS | ||
| osu.Game.Tournament | ||
| osu.Game.Tournament.Tests | ||
| osu.iOS | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| app.manifest | ||
| appveyor_deploy.yml | ||
| appveyor.yml | ||
| cake.config | ||
| Directory.Build.props | ||
| Gemfile | ||
| Gemfile.lock | ||
| global.json | ||
| InspectCode.ps1 | ||
| LICENCE | ||
| osu.Android.props | ||
| osu.Android.slnf | ||
| osu.Desktop.slnf | ||
| osu.iOS.props | ||
| osu.iOS.slnf | ||
| osu.licenseheader | ||
| osu.sln | ||
| osu.sln.DotSettings | ||
| osu.TestProject.props | ||
| README.md | ||
osu!
Rhythm is just a click away. The future of osu! and the beginning of an open era! Commonly known by the codename osu!lazer. Pew pew.
Status
This project is still heavily under development, but is in a state where users are encouraged to try it out and keep it installed alongside the stable osu! client. It will continue to evolve over the coming months and hopefully bring some new unique features to the table.
We are accepting bug reports (please report with as much detail as possible). Feature requests are welcome as long as you read and understand the contribution guidelines listed below.
Detailed changelogs are published on the official osu! site.
Requirements
- A desktop platform with the .NET Core 3.1 SDK or higher installed.
- When running on Linux, please have a system-wide FFmpeg installation available to support video decoding.
- When running on Windows 7 or 8.1, additional prerequisites may be required to correctly run .NET Core applications if your operating system is not up-to-date with the latest service packs.
- When developing with mobile, Xamarin is required, which is shipped together with Visual Studio or Visual Studio for Mac.
- When working with the codebase, we recommend using an IDE with intelligent code completion and syntax highlighting, such as Visual Studio 2019+, JetBrains Rider or Visual Studio Code.
Running osu!
Releases
If you are not interested in developing the game, you can still consume our binary releases.
Latest build:
| Windows (x64) | macOS 10.12+ | iOS(iOS 10+) | Android (5+) |
|---|
- Linux users are recommended to self-compile until we have official deployment in place.
If your platform is not listed above, there is still a chance you can manually build it by following the instructions below.
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
Build 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 VisualTests project/configuration. More information on this is provided below.
- Visual Studio / Rider users should load the project via one of the platform-specific
.slnffiles, rather than the main.sln.This will allow access to template run configurations. - Visual Studio Code users must run the
Restoretask before any build attempt.
You can also build and run osu! from the command-line with a single command:
dotnet run --project osu.Desktop
If you are not interested in debugging osu!, you can add -c Release to gain performance. In this case, you must replace Debug with Release in any commands mentioned in this document.
If the build fails, try to restore NuGet packages with dotnet restore.
Due to a historical feature gap between .NET Core and Xamarin, running dotnet CLI from the root directory will not work for most commands. This can be resolved by specifying a target .csproj or the helper project at build/Desktop.proj. Configurations have been provided to work around this issue for all supported IDEs mentioned above.
Testing with resource/framework modifications
Sometimes it may be necessary to cross-test changes in osu-resources or osu-framework. This can be achieved by running some commands as documented on the osu-resources and osu-framework wiki pages.
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, which is only supported on Windows. Alternatively, you can install ReSharper or use Rider to get inline support in your IDE of choice.
Contributing
We welcome all contributions, but keep in mind that we already have a lot of the UI designed. If you wish to work on something with the intention of having it included in the official distribution, please open an issue for discussion and we will give you what you need from a design perspective to proceed. If you want to make changes to the design, we recommend you open an issue with your intentions before spending too much time to ensure no effort is wasted.
If you're unsure of what you can help with, check out the list of open issues (especially those with the "good first issue" label).
Before starting, please make sure you are familiar with the development and testing procedure we have set up. New component development, and where possible, bug fixing and debugging existing components should always be done under VisualTests.
Note that while we already have certain standards in place, nothing is set in stone. If you have an issue with the way code is structured, with any libraries we are using, or with any processes involved with contributing, please bring it up. We welcome all feedback so we can make contributing to this project as painless as possible.
For those interested, we love to reward quality contributions via bounties, paid out via PayPal or osu!supporter tags. Don't hesitate to request a bounty for your work on this project.
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.