20150702 /nesting/

published 02 Jul 2015

In order to explain what we are currently doing to the osu! graphics framework, I’d like you guys to take a look at the osu!stream UI. A lot of you are probably not familiar with this iOS-only release, but I wrote it from scratch several years ago, fixing all (most of?) the mistakes I made in the PC version you are used to.

Pay special attention to the movement of groups of sprites and interface elements on the screen. Although this video isn’t 60fps nor super high-quality (sorry, couldn’t capture it nicely in a quick moment), you should be able to notice the vibrance of the tweens, which react in a way you haven’t seen yet on the PC version of osu!.

Observe how the main menu is transformed on an overall level as well as an individual per-item level; how the header and footer in song select smoothly disappear off-screen (and back on); how bounces feel… more bouncy! Honestly, osu!stream feels so much more polished than osu! (everyone in the office today agreed) even though so much less time and effort was put into it over the years.

This is what the goal of the current framework changes is. In short, the ability to have nested “drawables”. A drawable can be anything from a sprite, to a primitive, to a collection of many more drawables. Each drawable can have Position, Scale, Rotation, Colour and Clipping applied to it. As you’d expect, these transforms will apply to all children drawables, which can lead to very dynamic movement of elements on the screen.

So you may then ask: what have we been doing until now in osu!? In the most basic terms, drawables could not be nested. A SpriteManager could contain many drawables, but that’s the end of the chain. So for elements like osu!direct, Online Users, song select panels etc., the movement of groups of sprites that are related to each other has been a bit clunky and cumbersome.

There are a few more intricacies to what the current changes we are working on are changing (and fixing), but trying to explain them without going into amazingly minute detail would be quite hard. Maybe we can do that another day, if you are so inclined :).

Making these framework changes are both imperative to implementing the osu!next design and also to open-sourcing the osu! code-base. Because there’s no way I would want to expose the masses to the current state of the code!