Quite a bit to cover today!

Optimised player retry logic

Until now, when triggering a retry during play the game would actually be nesting a new screen inside the old player. While this was a very easy way to implement retry logic quickly, it also cause what could be classified as a memory leak if you retry too many times.

ocboogie is a new contributor who has been working over the past few days on fixing this problem. With a bit of guidance he succeeded in improving this process by a fair amount.

I also took the opportunity to clean up the transitions a bit (a touch faster metadata display too, for those of you complaining about having to wait the whole two seconds it displayed for).

Song rankings no longer display

If you’ve been using lazer, you may have noticed that online beatmap rankings are no longer being displayed. This is due to some changes in the backend API that I’ve been working through with nekodex which got pushed live today. The API changes will allow for things like country flags, mods and more to also be displayed.

I will be working on bringing the lazer code up-to-date with these changes tomorrow.

Conversion engine updates

smoogipooo has been hard at work on following up the modular rulesets with better support for converting between rulesets. This allows for some awesome possibilities, like converting from mania to taiko.

Song progress refactor

The song progress bar that has been sitting at the bottom of the play interface since last week was actually quite restricted in how it could be used. You couldn’t change the vertical height, it couldn’t be displayed in any location other than the bottom of the screen and it had a fixed height.

I took a fair amount of time today refactoring it to be more flexible and re-usable, primarily to make it also work on the results screen. In this refactor I also fixed the display to correctly scale the the maximum density value, where before it would just clip higher values off the display (causing 100% filled displays on harder maps).

Results screen

We’re almost there. While the design is not yet fully realised, the remaining elements are going to take some more work on the framework (masking and shaders). As such, I’ve submitted my results screen code for review and we should be seeing this go live this week, all going well!

Here’s another preview showing the latest improvements.

Smaller stuff

• Taiko barlines have had some bug fixes applied. There’s still some outstanding taiko fixes which should arrive this week.
• Autoplay now activates the key counter’s animation more like a real player would. Basically auto now has a key-up delay, rather than having perfect 0ms key presses. You should be able to see this change in the last video above.

No release today

Tomorrow, I’d say. There’s gonna be plenty of new stuff in the next build!

Back at you with another week of updates!

Rulesets are now completely modular

Until now, adding a new ruleset (previously known as a game mode) required manually changing the osu.Game project in many places. Now the registration and tracking of rulesets is completely automatic. For the time being, any ruleset following the standard naming structure (osu.Game.Rulesets.Taiko.dll for instance) will be loaded at startup. This will likely change going forward, but it’s a step up from what we had.

This is part of the ongoing refactoring to make things as flexible as possible, so implementing future game modes can be done seamlessly. It should make those few people out there working on their own rulesets very happy too, as they no longer need to maintain custom forks of the main project to load their modes for testing.

Continuing on this path, smoogipooo is working on the conversion system between multiple rulesets. We are working towards a point where conversion is possible on two directions, based on defining some basic conditions which are required before conversion can take place. This should be ready over the next few days, completing this refactor.

Quite a bit of work to make this happen. Didn’t get much else done today!

No release today

While there’s a few bugfixes that could have been pushed out, I’m hoping to get these modular changes in before doing the next build.

Bringing you the latest in osu! development

A slightly shorter post today as I have been busy with non-lazer tasks and drinking (it’s a friday after all!).

New HUD layout

While the visual finish pass is not complete yet, this build completed movement of HUD elements to roughly their final locations. Do keep in mind this will be user customisable, before you start complaining about change. The largest change here is that the combo is now at the top of the screen in a more centered display.

The main reason to get this in even without polish applied was to also allow for…

Song progress display

Not only tracking the current position in the song, this control will also show map density (may be configurable as to what it shows in the future) and also has a draggable seeker, which will be hooked up to replay control in the near future. This control is also lacking visual finish, but I am currently pushing to get these components live in a working state then iterate on the design to bring it up to scratch with my own expectations.

New release with all the above (and changes from yesterday)

2017.415.0 is now available from github releases (or via auto-update if you already have lazer installed)!

Bringing you the latest in osu! development

Fixes to screen interoperability

I had a lot planned today, but ended up spending most of my time following a yellow brick road to fix a reported bug which saw the game in a state of both paused and failed… at the same time. This, as you’d expect, should not be possible!

I spent almost five hours resolving this! It involved some very complex intertwined threading logic (which unfortunately is unavoidable in this context) and saw me finding at least three vaguely related bugs in the process:

• Game screens were handling escape keys even when they were not the active screen.
• The actual threading issues, caused by escape key presses being handled one level higher in the draw hierarchy than expected, in tandom with audio objects (when trated as an interpolating clock source) not correctly querying a cached IsRunning value.

If you didn’t understand any of what I just said, don’t worry! Explaining in words is hard… this was a complex situation.

Thanks to ocboogie for helping test this and finding an easily reproducible test scenario!

Fixes to gameplay cursor positioning

Until now, the gameplay cursor would start in a default position, not correctly updating it to the user’s current cursor position until the next time the input device was moved. This is really ugly, so I spent some time figuring out how to fix it up.

For a bit of background: all of our input events are event based. This unfortunately means that we can’t get an “initial” state for new screens/objects which are created, like the Player’s HitRenderer. As a temporary solution, we added an interface called IRequireHighFrequencyMousePosition. Anything implementing this interface would be guaranteed at least one MouseMove event per frame, regardless of whether the cursor was moved or not.

Inside a Player instance, we have a nested InputManager which is used to do key mapping (keys to mouse, mouse to keys etc.) and replay handling (injecting input frames from an external source). The bug here was caused by the fact that nested InputManagers weren’t implementing this interface correctly, which meant they wouldn’t correctly propagate it down to their children.

Before:

After:

May seem insignificant, but every detail counts!

Fixes to cursor trail display

Until now, the gameplay cursor’s trail has been using the audio clock, which can lead to some unexpected results, especially after pausing or on retrying a map. I decoupled the trail from the audio clock in order to fix this, so it should behave a lot closer to how you’d expect it to, regardless of the state of audio playback.

API in the background…

Have been working with nekodex on bringing the new API up to speed so we can begin to populate more data in-game. This includes beatmap ratings, fail/retry times, user flags, personal best scores and more. We’re almost ready to set things up for testing, so stay tuned for further progress on that.

Oh and yes, these API changes will eventually be exposed for public consumption. We’re aiming to provide a much more feature rich API and address the concerns people have with the existing public API over the coming months.

No release today

While fixing the above issues was some major forward progress as far as stability is concerned, the code has not yet been reviewed so there will be no release today!

Bringing you the latest in osu! development

Sliderbar sound improvements

Fixed sliderbars making sounds when they shouldn’t, and added extent-specific sounds, so you know when you’ve hit the end (minimum or maximum) value of a setting.

Beatmap details page goes live!

After an arduously long code review, things are finally in a usable state. Note that there is code present for online stats, but as the API isn’t yet prepared to send those to the client they are not yet visible. You can see a preview in my post yesterday.

Fixes galore

• Fixed a long-standing issue in OpenTK where the game window would receive keyboard input when it wasn’t focused. This generally happened when the window was not focused at startup.
• Added more searchable fields at song select (tags, source). #621
• Fix crash when typing in chat overlay while not logged in. #620
• BufferedContainers no longer run needless updates on their children when they are in a cached state. framework #637

New release with all the above (and changes from yesterday)

2017.412.0 is now available from github releases (or via auto-update if you already have lazer installed)!