Yesterday, apart from revealing the new profile cover image system, I made a commit which should satisfy the needs of a lot of players out there that have been requesting the ability to remove slider start or end circles.

You are now able to skin (or remove) each of these separately, along with their overlay counterparts. In short, the four new skinnable files were added:

• sliderstartcircle
• sliderstartcircleoverlay
• sliderendcircle
• sliderendcircleoverlay

This allows for effects such as this:

It’s not actually the first time I’ve tried to fulfil this feature request, but due to the way sliders are rendered internally – and how convoluted the code is behind them – I’ve always stopped halfway. Even with this implementation, there are a few shortcomings which I will address in the future (animation and rotation related).

As an update on osu!keyboards, the production of the next batch has now begun (finally!), which means I should have more regular updates for you over the coming weeks.

Tom has also been busy pushing many graphic related optimisations to the cutting-edge branch, so do make sure to check that out if you have previously had issues with the cutting-edge (opengl) implementation. Any feedback is much appreicated, as always.

Recently I’ve been abusing Google Inbox to schedule distracting tasks from the week until the Monday of the week after, which makes Mondays into a kind of catch-up day. Hot weather continue in Tokyo, with mid-30s maximums (apparent temperature hits 43-45 due to the insane humidity levels) and not much of a break at night either.

A few brief updates:

• There’s currently a poll open to choose which t-shirt designs should be produced next. Feel free to go vote if you haven’t already, although the winners this round already seem to have been decided.

• Got some new arrivals to jizz user profiles, with user pages making a reappearance today and more to come likely tomorrow. Keep your eyes peeled!

• Making progress on the next osu!keyboard order (here’s a sneak peak of one of the changes we’re making next batch). Doing business internationally can be a truly gruelling process; the last few days of follow-up just to get money where it needs to be have been quite exhausting.

As far as progress on the next osu! release goes, I’ve been spending a good part of my time merging in bug fixes that have been piling up over the last month. We still have a lot to fix, but part of getting things right is understanding exactly which users are experiencing problems, and whether those problems need to be fixed at our end or the user’s end.

Got the new public release out the door, and already have some metrics to work with. So let’s take a look at the picture as it is now. It’s not as optimistic as it could be, but my expectations weren’t high.

Total sample size: 27,360 (this will increase over time)

Hardware OpenGL context availability

Two of every hundred users will be unable to run the next public release, due to having incorrect drivers installed. They may have been able to scrape by until now using the generic “Microsoft Basic Display Adapter” - which provides very limited hardware support for DirectX - but this just doesn’t cut it as far as OpenGL is considered.

For the most part, the answer here is user awareness. Users need to install graphics card drivers where they are not yet present on their system. There is already a pop-up in osu! (as of today) which informs users of this problem and directs them to a wiki page with useful details on fixing it.

.NET 4.0 availability

Even more alarming, almost four in every hundred users don’t have .NET 4.0 (or higher) available on their system. This is also a cause of nor being able to run future osu! builds. osu! has had a pop-up for some time now which allows the user to click to install a newer .NET framework, but it looks like we still have some way to go here.

It’s also important to keep in mind that some of these users are wine users, which are unable to present .NET 4 to osu! until we release a new osu! bundle for OS X.

GL FBO availability

Frame Buffer Objects are useful for drawing to textures at very high performance. We use them for slider and game-wide filter optimisations and plan to use them more going forward. They are pretty well supported, but the game will still need to work without them for the foreseeable future.

GL VBO availability

Vertex Buffer Objects are useful to reduce draw calls and CPU-GPU memory bandwidth usage by sending large buffers containing everything you want to draw, while also only updating what you change. It gives the GPU more independence. While we have a working branch with VBO support, we are still analysing whether this will be of benefit for a game like osu!.

Fall-back support would still be available even if VBOs were used. We already use VBOs for cursor trail rendering where available, as it helps drastically with performance.

Conclusion

We still have some work ahead of us before the next public release is feasible. Not only do the above statistics say this, but there are reports of “stuttering” and general sub-par performance with certain GPUs. We are working with users to solve these. If you can reproduce lower performance on cutting-edge when comparing to the latest stable (direct x OR opengl) then jump on slack and help us help you in #cuttingedge!

Yes, I missed yesterday due to spending far too much time catching up on communications and financials and passing out before I got to posting. These things happen.

Okay, let’s get some information flowing! We are trying our best to get a public release out, but it’s not as simple as we hoped. There are still performance issues with certain users when running the next OpenGL based framework, and none of us are willing to release anything to the masses until it’s guaranteed to work for every user. So where do we stand?

Tomorrow I am puushing out a minor public release. It will start reporting back to us stats about users and their hardware, in a way that we can:

• Know how many users are going to have issues if we were to push out the new framework.
• Which users we can contact if we need testing with specific hardware.
• Focus our efforts on the areas that require the most attention.

For those concerned with privacy, here’s what is sent for my PC:

Once we gather these results, we can begin to tackle the bigger problem of fixing the next release to work flawlessly for everyone. I don’t have a timeline for when this will be done, but we do plan on pushing out any critical fixes to the old stable branch in the mean time as necessary. I also plan to selecvtively push people to the new framework based on their PC specs (in the case we don’t solve every issue) to ensure a smooth roll-out process.