These days, we have a lot of highly skilled people working on osu!. It’s no longer the era of everything-is-100%-done-by-peppy. One thing I aim to do with this blog effort is to give everyone on the team a voice. With yesterdays post being pretty exhausting for me, I was happy to take a break today when Tom94 offered to fill in :).

Hi everyone, Tom94 here with a guest post for today.

As many of you probably know already, we are currently pushing osu! towards running exclusively on top of the OpenGL graphics API rather than supporting DirectX and OpenGL alongside each other. This has multiple benefits, such as better cross platform support (hi, Mac and Linux users!) and less effort to implement and optimize visual features. This is not what I want to go in-depth about, though. Today I want to talk about a particular issue with osu!’s OpenGL implementation that has plagued us for a while: Users running on Intel integrated graphics chips mysteriously experienced severely worse performance than when they were running on DirectX.

Luckily, since I own a device with such a graphics chip inside I could test and narrow down where the issue came from. After many hours of troubleshooting and trying various complicated solutions without success, I found that the graphics chip did not support the graphics settings osu! wanted it to use and instead fell back to using the first setting it could find. Turns out this setting included 4x anti-aliasing, a very expensive technique for potentially improving image quality, but one which osu! cannot even profit from. As ridiculous as it may sound, we fixed a long standing huge performance problem simply by turning off anti-aliasing. Nobody noticed it was on in the first place, because in osu! there isn’t any noticeable benefit to it. At the end of the day by changing a single line of code the performance on Intel hardware increased by more than twofold in most cases. And it doesn’t even stop there. Another issue – blurry lines within the editor – which we were just as puzzled about ended up being fixed by this change as well.

This illustrates how when developing software it is the norm that something unexpected happens. Surprisingly often after hours of looking for a bugfix only a very minor change is needed. The challenge is to find this particular small change rather than trying to cover up an issue by patching it up with the programming equivalent of duct tape.

One positive aspect this whole ordeal brought with it was the addition of an in-game overlay designed to detect and troubleshoot issues with performance. It can be toggled via Ctrl+F11 when running the beta or cutting-edge version of the game and helps us greatly to figure out which parts of the game are running slowly. Here is an example of how it looks like when rapidly scrolling through the song selection.

Other interesting fixes that recently happened are:

• Fixed clicks sometimes not being handled if osu! ran at a too high framerate. Yes, this is sort of a first-world problem. A rounding error in the timing code made the game sometimes think objects have been clicked before they have been drawn to the screen. This is yet another very short fix which thankfully was a lot easier to find than the one above.

• Improved the way spinners work, fixing various things in the process. Auto now doesn’t score wrong amounts with the DoubleTime and HalfTime mods and the spinner animation is no longer capped at 60 frames per second.

• The hover sound loop in song select is now finally gone!

I’ve also been optimizing the pp processor to be ready for future things to come, but this is material for another blog post. :) If there are any questions I’ll gladly answer them in the comments!