I recently posted a video showing the progress we are making with a huge overhaul of how osu! draws objects on the screen. It probably didn’t mean much to most of you, so I thought I’d take a few minutes to explain what we are trying to achieve (and why it is so important).

Let’s dissect one single component on the osu! main menu!

Firstly, let’s split out all the different components and sprites. The visualiser is omitted for simplicity.

You can see the various components (thicker blue lines) and the sprites/components contained within them (thin blue lines). Next, we need to figure out where they are going to sit on the screen. In order to do this, we need an Origin point set on each drawable object, which becomes the location used within the sprite to assign a position.

The orange dots represent the origins assigned to each drawable object. Hopefully it should make sense why the specific origins are chosen in this example; they should make setting the object’s position as simple as possible. An origin can be set to any of TopLeft, TopRight, CentreLeft, Centre, CentreRight etc., and can also be overridden with a custom value for unique cases.

One piece of the puzzle is still missing, because in many cases we want to give objects a position from a specific corner of their parent. Think of the case of the FPS display, where we want it to be at the bottom-right corner of the screen. Rather than providing the screen’s width and height (which could change at any point!), it is much nicer if we can give it a position of (0,0) from the BottomRight corner. This is done using Anchors. Let’s look at the FPS display in a bit more detail!

The FpsCounter contains three sub-components:

• Frame-rate display
• Frame delay display
• Dropped frames display

You can see in the diagram above how these are arranged in a (hopefully trivial) heirarchy. Now let’s figure out the positions, anchors and origins required to make this happen:

This is a very simple example as we don’t need to worry about assigning a different anchor and origin to a single object; they are always the same. This is actually quite a common scenario, but there are cases where this is not true. I’ll leave it up to your imagination where this would come up, but as a hint, consider that all scale/rotation animations applied are also based on the Origin.

You can click on any of the diagrams above to get a larger view. Please let me know if the explanations provided here are simple enough to follow, and if not, let me know where you got lost so I can improve on further posts.

As we are aiming to open source the client in the near future (this year), I plan on doing more posts like this to help people understand what kind of framework they will be exposed to. Oh, and if you want to know how we did things until this rewrite, think of the above example without the concept of more than one level of heirarchy

Hi everyone, I’m Ephemeral! I’ve been with osu! for a while now (since 2009) and have been ambling about behind the scenes for nearly as long, helping stuff get done and the like. Some things have recently come to bear, and I’ve been asked to help bring some clarity to the matter.

As many of you are probably aware, things have been particularly rocky in the community over the past week or so. A number of fairly big changes were added, then removed, then readjusted and proposed again, then removed again.. A mess and a half, to say the least. Everything went belly-up for a little while, and we’re only now just starting to get our head wrapped around things again.

During this whole fiasco, one of the biggest issues expressed by the community is the lack of transparency in how “staff” decisions are made and affect the game. This is something that as a team, we typically struggle with. Most of our major discussions happen behind closed doors, a product of years of tradition dating back to the very first years of the game, when the community was far, far smaller.

For the longest time, the community was small enough that any concerns would trickle through the engaged user-base and ultimately end up being noticed by someone involved who could do something about it. Over the years, osu!’s community has grown above and beyond our wildest expectations, and it is entirely fair to say that we have dropped the ball on adjusting our decision-making practices to account for this.

So, going forward, we aim to be entirely transparent with our thought processes leading up to the big decisions that impact everyone in the community.

What better place to start than with the issues of the past week?

With that in mind, we have constructed a unified timeline of the decisions pre-dating the infamous “Mapset and Spread” restructure that sent the community into a furore, as well as the “Ranking Criteria Council” concept (which has been met with similar levels of disdain).

It is our hope that by placing the events leading up to the birth of these decisions into the public view, we can work together to find out the best way of moving forward from here, and to make sure that something like this does not happen again.

We have suspended all movement in the Ranking Criteria changes for (at very least) the remainder of the week, and will use this time to gather your feedback and our thoughts on how we may best proceed from now on.

For those wondering how “osu!next” is coming along, here’s some of the progress we’ve been making. It may look like very basic stuff, but let me give you an idea of what is going on here:

We’ve been working to clean up the osu! codebase so it is easier to follow and contribute to. The existing framework means visual objects inside other objects (for things like scrollable views) have been limited in how they can be transformed. Movement has been easy, but anything beyond that requires quite convoluted code.

This video is an early preview of a drawable class inside another drawable class inside a third drawable class. Each can have transformations applied to them, which affect all of their children (movement, two-dimensional scale, rotation, colour and alpha).

Input is also masked correctly to only propagate downwards to the correct objects. You might notice that the boxes themselves aren’t masked to their parents yet; this is something we are still working on.

I coded up this example in a few minutes just to show what we’re up to behind the scenes. The whole class is under 100 lines for this demo, and about half of that will be unnecessary once we finish correcting the viewport implementation (so children can set their own coordinate system independent of the parent).

Yes, the “osu!next” design is still yet to take shape, but once we get the basics down things will be really really fast to actually implement. We’ve been holding off until the framework is ready to accept lots of new pieces entering it at a rapid pace.

This is the culmination of an effort over the last year, recently brought up-to-date by smoogipooo TVO and myself. It’s been a struggle to keep it merged alongside the constantly changing mainstream branch, but we are currently mending it with the aim of merging it into CE in the coming weeks. Stay tuned!

It has been a while since I’ve posted on general osu! progress, so here’s a cumulative update for January! It’s safe to say we’re making good progress in a lot of areas, though personally I still want to see more happen faster.

Infrastructure Improvements

There has been a pretty large spike in concurrent users over the last couple of months. In order to keep things working smoothly with the increased demand, I’ve begun to add additional servers where they didn’t exist before. The first of these to be introduced was a dedicated score submission server, decoupling it from the main private API backend server (previously handled score retrieval as well). Deployment of specific web-based tasks has always been quite modular, so adding new servers fortunately comes with little overhead, apart from the added cost. Work continues this week as I prepare servers for the added load caused by Chinese New Year.

In addition to processing servers, I’ve also been expanding the download mirrors to make sure the osu! game client, updates and associated resources are streamed as fast as possible to the various regions of the world. More to come on this, since I find content distribution quite an interesting area to discuss!

Skin Preview

Now live on cutting-edge, skin gameplay preview has finally come back. Rather than a specifically crafted game mode, it will randomly choose a beatmap, set the mods to Autoplay and seek to an area of the beatmap where you can see some action. The options menu is now able to stay open in this mode, allowing you to make changes to the skin (and other settings) while instantly seeing how it affects gameplay.

New Interface Sounds

I mentioned these at the end of last year, but they are now added on cutting-edge. You can go check them out yourself. They are also all skinnable.

OWC Prizes

We got our workflow sorted for sending tournament prizes out. The main osu!store’s fulfillment centre is already under enough load, so we had to setup a second fulfillment centre specifically for handling these prizes. Everything is going smooth now, and all OWC 2015 prizes have now been sent out to the winning teams!

New osu!web releases

The new osu! website is slowly beginning to take form! The beatmap listing is now live (ignore the low quality thumbnails please), along with new sections on user profiles including history, beatmaps and achievements. Livestreams are also visible, though the design is in need of severe revision.

Progress on the new web is about 10,000x slower than I want it to be. I’m still trying to figure out how to improve this without sitting down and completing it myself. If you are someone that has seen the bounty system we are running but something is holding you back from contributing, please let me know so I can do everything in my power to help increase productivity on the project! I will be announcing many more bounties over the coming weeks, so keep an eye out here and on the github repo.

Reddit Presence

I threw some effort into trying to get some degree of order in /r/osugame (to the point I would be personally happy to return there). Things are looking good, with cheating reports separated into a new dedicated sub-reddit. There’s a lot of unique conversation, content and meta that doesn’t make it on the official osu! forums, so if you don’t already frequent that place, you may want to check the sub-reddit out once in a while and see if it’s something you want to follow along with!

I recently switched from a MacBook Air 11” (2013) to the new Surface Book (base specs). My reasoning was to extend my battery life while on the move, as the air was only netting me around 6 hours on Windows. The air did of course fare better on OS X (7-8 hours) but I would find myself in Remote Desktop all day long as I generally use windows exclusively these days for development.

The hardware is quite nice overall. I have some issues with quality control, but I’ll save that for another more general post. I’m making this entry specifically to touch on battery life, as I have put in a fair amount of time and research in to getting my setup perfect and thought it would be a waste not to summarise and share it. There seems to be a bit of false information out there on how good/bad the Surface Book battery life is - especially due to early reviews using different hardware from the final specs. Time to try and help clear things up.

I get between 9 and 14 hours on battery, depending on what I’m doing. If I was to leave the PC idle (wifi connected, 50% brightness) I can get 18 hours. I use connected standby and the Surface Book consumes around 0.9-1% per hour sleeping. These numbers are well within my expectations. That said, in order to achieve such battery life, you do need to be aware of a few basic points:

Connected Standby Low Power States

Update: As of the release of the February 17th Firmware updates, Hyper-V is no longer required for Connected Standby!

As of January 2016, in order to make connected standby actually enter low power states, you have to install the optional Hyper-V components. The reasoning behind this is yet unknown, but it’s the difference between 2800mW/h and 680mW/h usage when sleeping. Note that having wifi on or off does not seem to affect drain rate significantly.

In order to check that your system is correctly entering Connected Standby low power states, you can use the powercfg command.

• First make sure your battery is already at 96% or less - the SB hides battery drain from 100 to 97% from the system, which will cause completely inaccurate results if included.
• Make your system sleep for at least 30 minutes (less than 10 won’t display at all, less than 30 will be inaccurate).
• Open an administrative command prompt (Win+X then A) and type powercfg /sleepstudy.
• Open the generated html page in your browser of choice and compare to the following example:

For those wondering what it looks like when CS isn’t working correctly, here’s an example.

Inhibit Turbo Boost while on battery

I recommend disabling turbo boost while on battery by setting the maximum processor state to 99% in your power profile. While this will reduce the performance of some burst tasks, it will also limit the degree that run-away processes using high CPU for their lifetime can affect battery life, which can be a huge gain.

In order to change the processor state, you will need to alter your registry as it is hidden by default. Here’s a reg file that will do it for you (open it in a text editor if you’d rather make the change manually).

Hit the windows key and type “power plan” then open the “Edit Power Plan” settings panel. Click “Change advanced power settings” and alter your maximum processor state while on battery to 99%.

As a note, it is possible that for some workflows this will not be beneficial. Turbo Boost is implemented to be quite efficient, so you may want to consider not adjusting these settings if you are getting already getting ample battery life without overriding the defaults.

CPU Babysitting

Windows 10 has some issues which can result in high CPU usage. Make sure you keep a watch on CPU usage to make sure you don’t get any background tasks saturating your CPU. Here are some examples I have experienced which can result in high background usage:

• Search indexing. If you have a lot of small files that change regularly in your user folder (node.js projects, cygwin installs, large git repositories), consider exluding them from indexing.
• System and Compressed Memory. If this is high, you likely have a driver or software conflict. I experienced this after a bit too much experimentation with SB drivers; a fresh install of windows has since fixed it.
• Service Host: Remote Procedure Call. I’ve found that some windows store apps can trigger a high CPU state that you can only recover from by closing the problematic apps. Let’s hope Microsoft addresses this one.

If you’re worried about background processes, power saver can help alleviate the load, but it is limited to certain services such as Windows Update. No harm in leaving it permanently on, though.

I use Rainmeter to watch over my CPU, as it gives me a quick glance of the processes using the most CPU time.

Display Brightness

Keep display brightness at 50% or less. Anything higher increases battery usage quite exponentially. I’d recommend turning off adaptive brightness and just adjusting yourself as you see fit.

Raw Energy Consumption

On top of this, I highly recommend an app like BatteryBar Pro (the free ‘basic’ version is fine) to watch your actual energy consumption. You don’t need to constantly be watching, but at least spend a few sessions understanding which of your tasks are using more power than others.

Undervolting?

Advanced users may want to consider undervolting using Intel XTU, but I’m not going to go over that here as it requires special care with connected standby else your system will crash. I do run at -82mV and can attest that it reduces heat output significantly, but doesn’t really affect battery life in a meaningful way.

Conclusion

The Surface Book has a 68Wh battery, so if you want 10 hours you need to aim for 6800mW consumption or less. When doing menial tasks like web browsing, I usually hover around 4-5000mW; dev work is closer to 6-7000mW; burst CPU activity can hit as high as 20-30W.

While you can achieve high battery life with the SB, the out-of-box experience is absolutely horrible. Microsoft do still have some work to do:

• Connected Standby should just work, even without Hyper-V enabled.
• Connected Standby should be using far less power. The specs state devices must drain less than 5% per 16 hours, and they are yet to get anywhere close to that. Who knows if they can?
• The Surface Book consumes power while completely off when connected to the keyboard dock. This is completely unacceptable. I’m not sure if it can be fixed with firmware updates, but let’s hope so.

Can I recommend this thing? I’m honestly not sure yet. I have a few other issues I haven’t mentioned here such as paint being scratched off the hinge, fan noise and speaker issues which I’m happy to live with but deserve consideration before making a purchase (these seem like quite common issues, looking around). I’ll write those up another time if I find time :).