As Project OutFox grew, we kept finding the same kind of problem.

The engine could appear to be running well while doing far more work than it needed to. The frame-rate counter might show a large number, but it could not tell us whether frames were arriving evenly, whether a system was updating at the correct rate, or whether the engine was repeating work when nothing had changed.

Some of this behaviour had been inside the StepMania engine for many years.

That did not necessarily mean it was broken. In many cases, the original reason for the code had simply been lost as hardware, operating systems and the rest of the engine changed around it. A workaround written for an old graphics card or operating system could remain active long after that system had disappeared.

We did not want to remove something merely because it looked old or unusual. OutFox still supports hardware and content from several generations of rhythm gaming, so changing inherited behaviour without understanding it can cause very real problems.

At the same time, leaving everything untouched was not an answer either.

We needed to know what the engine was actually doing. That is why we built StillRiver.

StillRiver began as a way to look beyond the usual performance numbers. Instead of only telling us how many frames the engine could produce, it allowed us to follow the work happening inside each frame.

We could see which systems were running, how often they were being called, how long they were taking, and whether their behaviour changed elsewhere in the engine.

It did not take long for the measurements to reveal some odd results.

One of the clearest examples came from the lighting system. It could update more than two thousand times per second because nothing was properly limiting its update rate.

Each update was small, and the game still appeared to work, so the problem had remained hidden. Taken together, however, those updates were using processor time to repeatedly produce the same result.

The solution was not to make every lighting update faster.

It was to stop asking the lighting system to update when there was nothing useful for it to do.

That discovery became the principle behind StillRiver: If the engine does not need to do something, it should not do it.

Since then, StillRiver has become part of how we approach work across OutFox.

Before changing a system, we measure its existing behaviour. We make sure the test can be repeated, then compare the results after the change. This helps us see whether an apparent improvement is real, and whether it has affected timing, frame delivery, compatibility or another part of the engine.

It also helps protect older hardware.

Removing unnecessary work gives modern systems more room to run efficiently, but it can make an even larger difference on older laptops, embedded devices and original arcade computers. Supporting those systems does not mean leaving the engine frozen in the past. It means being careful about what we change and making sure every system uses the resources it actually needs.

StillRiver is not about chasing the largest benchmark number, it is about understanding the engine before we touch it.

Sometimes that means rewriting a system. Sometimes it means changing how often it runs. Occasionally, it means measuring something carefully and deciding that it was already doing the right thing.

The important part is that we no longer have to guess.

We can measure first, understand what is happening, and then make the change the engine actually needs. That evidence-led approach is also consistent with the wider StillRiver framework developed around engineering measurement and honest reporting.