StillRiver was originally built to help us understand what OutFox was doing while it ran.

That meant looking at frame updates, rendering, audio, input and the systems that continued working even when nothing had changed. The recent loader work expanded that view.

Startup had become one of the largest performance problems in the engine. On bigger libraries, players could wait several minutes before reaching the music wheel. Once there, uncached media and repeated file checks could create further stalls during the first pass through a pack.

We needed to measure those paths in the same way we measured gameplay.

StillRiver now records more of the work involved in starting the engine and loading content. This includes directory scanning, parser activity, note-data processing, cache handling, media checks, audio-length detection and the different stages of building the song library.

That gave us a clearer picture of where the time was going. We also now have a preference based block in the preferences, which we will keep into the releases for those that want to see what StillRiver records, it is all uncompressed TSV (tab seperated values) a spreadsheet basically). We we also provide some tools to read the new data, but we left them unencrypted so you can see what the game can collect, with full transparancy.

Some operations were necessary to preserve compatibility with older charts and unusual folder layouts. Others were asking the same question repeatedly, opening files earlier than required, or running parser routes when there was no suitable content for them to process.

Once those differences were visible, we could make narrower changes.

The loader became significantly faster. Cache handling became more dependable. Theme wheels stopped repeating some expensive work, and several tempting gameplay optimisations were left alone when the measurements showed they could change behaviour.

That last part is important.

StillRiver does not exist only to justify removing code. Sometimes it confirms that a small change is safe. Sometimes it shows that a proposed shortcut would skip required work. In other cases, it gives us enough information to plan a cleaner replacement later without changing behaviour immediately. The same approach now applies across startup, gameplay and presentation, measure the current behaviour, find the work that is actually causing the problem, then change only what the results support.

For players, this should mean faster startup, smoother first-time scrolling, more reliable cached content and fewer faults caused by unrelated systems repeating the same work.

StillRiver began by showing us what happened during a frame.

It now helps us understand the work required before the first frame of gameplay appears.