Engine Chronicles

• Engine Chronicle #8: Following a Timing Fault Through the Engine

  Jul 03, 2026   Engine Chronicles

  While testing SereneAudio, we noticed that input had started arriving late across several different drivers.

  Because the same delay appeared with multiple devices and backends, it was unlikely to be a controller or driver problem. The fault had to be somewhere in the timing shared by the wider engine.

  OutFox inherited several timing systems from StepMania. Audio, input, gameplay, rendering and Lua had gradually become connected through assumptions about update order and which system was responsible for the current time.

  Those assumptions could remain unnoticed while the older systems continued to behave in the way the rest of the engine expected. Replacing RageSound and RageInput began to remove that behaviour, exposing dependencies that had previously been difficult to see.

  We first reworked the input timing path to fit the new engine model. Testing showed that part of RageInput was still acting as a timing authority, even though that responsibility was being moved elsewhere.

  Once that remaining control was removed, input timing began behaving correctly again.

  The next test reached the music wheel and crashed.

  The new path had exposed an older fault in the wheel that had previously been hidden by the engine’s former timing and update behaviour. Fixing that then uncovered a related problem with video banners, where Lua code still expected the timing behaviour provided by the older systems.

  Each issue came from the same underlying problem: several parts of the engine had learned to depend on behaviour they did not formally own.

  The replacement work is giving those responsibilities clearer boundaries.

  SongClock provides the shared gameplay timeline. SereneAudio handles audio transport and playback. SereneIO collects and timestamps input. The renderer presents the result, while Lua receives consistent timing information without needing to reproduce old engine assumptions.

  This does not mean every newly exposed fault was caused by SereneAudio or SereneIO. In several cases, the fault was already present. The older architecture simply arranged events in a way that kept it out of sight.

  By the end of the work, the input delay had been corrected, the remaining RageInput timing authority had been removed, and the music wheel and video banner faults had been fixed against the new timing model.

  What began as an audio timing test ended up removing another group of hidden dependencies between input, gameplay and presentation.

  That is an important part of the Beta I work. The new systems are not being layered over the old architecture indefinitely. They are gradually taking over their intended responsibilities, while the assumptions left behind are identified and corrected.

• Engine Chronicle #7: SereneAudio Across Platforms

  Jun 30, 2026   Engine Chronicles

  Replacing an audio engine does not stop at generating sound correctly inside the game.

  That sound still has to reach real hardware through the audio systems provided by each operating system. Those systems do not all work in the same way, and they do not all expect the engine to feed them audio using the same timing or buffering model.

  This stage of the SereneAudio work has focused on those output paths.

  SereneAudio is now running through WaveOut, RtAudio, PortAudio and PulseAudio. Linux output has also been tested and confirmed working through the new system.

  During that testing, we found an underrun affecting some of the older polling-based drivers.

  Part of the engine was still feeding those drivers using assumptions carried over from RageSound. That worked well enough under the old architecture, but it did not match how SereneAudio now prepares and submits audio.

  The answer was not simply to increase the buffer.

  Larger buffers can hide underruns, but they also increase latency and make playback less responsive. Smaller buffers reduce delay, but leave less room for the system to recover if audio is not supplied at the correct time.

  We needed to fix how those drivers were being fed rather than covering the problem with additional delay.

  StillRiver helped us follow the buffer activity while the engine was running. That showed where the older polling behaviour no longer matched the new audio path, and allowed us to check the result across each backend after the fix.

  WaveOut is now working through SereneAudio and retains a path for Windows XP support. RtAudio, PortAudio and PulseAudio are also working, giving us tested output routes across both Windows and Linux.

  This work also removes one of the restrictions inherited from RageSound.

  The older system expected one driver and device to remain active for the entire session. SereneAudio is being built so that the output driver and device can be changed from within the game without restarting the engine.

  There is still some cleanup remaining. The final volume-control paths owned by RageSound need to be removed so that SereneAudio handles that work in one place rather than sharing responsibility with the old system.

  For players, none of this should require much thought.

  Audio should start on the selected device, continue playing without stuttering or underruns, and remain responsive enough for rhythm-game playback. Older systems should continue working where we can support them, while newer devices should not be limited by assumptions from the previous engine.

  SereneAudio is now working through real platform backends rather than a single development path.

  That gives us the base needed to continue removing the remaining RageSound code and complete the transition cleanly.

• Engine Chronicle #5: StillRiver, Measure Before Changing

  Jun 29, 2026   Engine Chronicles

  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.

• Engine Chronicle #6: BMS Playback and SereneAudio’s First Silver Grade

  Jun 29, 2026   Engine Chronicles

  This work began with a BMS chart that was not loading correctly.

  What looked like a small detection problem led us into several older parts of the BMS and PMS support inside OutFox. Some chart types were not being classified correctly, and the engine did not always have a clear answer for how their audio should be handled once they had loaded.

  The BMS family includes BMS, BME and BML files, alongside related formats such as PMS. These formats have existed for a long time and have been used in many different ways. That flexibility is one of their strengths, but it also means that older and newer charts do not always expect the same playback behaviour.

  Some older charts rely on traditional BMS multiplexing, where background sounds and keysounds are arranged and played according to the assumptions of the original format. Newer content often expects a cleaner separation between background music and individual keysounds.

  OutFox needs to support both.

  Under the old audio system, responsibility for those decisions was spread across several parts of the engine. The loader, song data, music object and audio system could all become involved. That made it difficult to tell which part of the engine should own the behaviour, and made apparently small fixes much riskier than they needed to be.

  SereneAudio has allowed us to separate that work more clearly.

  OutFox now has an option for traditional BMS multiplex playback, allowing older charts that depend on it to behave more closely to how they were authored. Modern playback remains available for content that expects background music and keysounds to be handled separately.

  For now, the option is available through the experimental settings while the new theme work is completed.

  The same investigation also uncovered problems with chart detection.

  Some 5-key BMS charts were not being recognised correctly, while older four-panel dance charts stored in BMS files could also be missed or classified incorrectly. Those charts now appear and load as expected, including DDR-style charts written using the BMS format.

  This was also one of the first opportunities to test SereneAudio under the pressure of dense keysound playback.

  BMS content can schedule a large number of short sounds in a very small amount of time. That makes it useful for checking whether the audio transport, sound scheduling and playback path remain stable during real gameplay.

  StillRiver was running throughout the tests, giving us measurements from the audio system while the charts were being played. We checked scheduling behaviour, runtime stability, soundcard latency and clipping rather than relying only on whether the result sounded better.

  The results were consistent enough for SereneAudio to reach its first Silver grade.

  Silver does not mean the audio system is finished. It means this part of the new audio path has reached a measured and repeatable level of stability that we are comfortable continuing to build upon.

  The important result for players is much simpler.

  Older charts can use the playback behaviour they were written for. Newer charts are not forced through old assumptions. Missing chart types are being detected correctly, and dense keysound content can be tested with a clearer view of what the audio engine is doing.

  This is the benefit of replacing the older foundations properly.

  The BMS fixes were not only easier to make. They were easier to understand, test and verify without several parts of the engine fighting over the same decision.

  Patreon support gives us the time and hardware needed to follow work like this beyond the first visible bug. That is often where the useful fixes are hiding. We thank you a lot for your support!

• Engine Chronicle #4: From RageInput to SereneIO

  Jun 29, 2026   Engine Chronicles

  Input is one of the most important parts of a rhythm-game engine.

  Every step, key press, panel hit, MIDI message and controller action has to reach the game accurately and consistently. Small problems in that path can become missed inputs, duplicated events, uneven polling or devices behaving differently between operating systems.

  For many years, StepMania and Project OutFox handled this through RageInput.

  RageInput supported an enormous range of devices across several generations of hardware and operating systems. Over time, OutFox extended it with additional drivers, MIDI support and compatibility work for newer controllers.

  That kept more hardware working, but it also exposed the limits of the original design.

  Different platforms handle input in very different ways. Some devices produce buffered events, others need to be polled, and specialist arcade hardware may require its own timing and device behaviour. As support expanded, RageInput accumulated more platform-specific paths and assumptions, making the system increasingly difficult to maintain and improve safely.

  SereneIO is our replacement for that architecture.

  Rather than forcing every device through the same model, SereneIO allows OutFox to use the input method best suited to each platform and device family.

  On Windows, this includes buffered DirectInput, polled XInput, MIDI support and dedicated handling for specialist controllers. On Linux, SereneIO supports evdev, with additional platform work continuing for modern display and input environments. The wider architecture is designed so that platform-specific improvements can be added without turning the entire input system into another maze of exceptions.

  This is not simply a change of name.

  SereneIO gives us clearer separation between device discovery, event collection, polling and game-facing input. It reduces dependence on inherited assumptions and makes it easier to diagnose where a problem occurs when a device does not behave as expected.

  Compatibility remains central to the work.

  OutFox still needs to support ordinary keyboards and controllers, dance pads, arcade I/O, MIDI devices, legacy hardware and unusual community-built equipment. Modernising the input system is not useful if it narrows the hardware players can use.

  For players, the result should be straightforward: devices connect reliably, inputs are handled consistently, and specialist hardware can be supported without compromising the rest of the engine.

  RageInput carried the engine across many years of hardware change.

  SereneIO gives us a cleaner and more adaptable foundation for what comes next.

• Engine Chronicle #3: OpenGL ES, ANGLE and a More Portable Renderer

  Jun 29, 2026   Engine Chronicles

  Project OutFox has always supported a wide range of hardware, but supporting many systems is not simply a matter of compiling the same renderer everywhere.

  Graphics drivers differ between operating systems, vendors and generations of hardware. Even when two systems claim to support the same version of OpenGL, their behaviour is not always identical. Over time, those differences create extra work, platform-specific fixes and faults that can be difficult to reproduce.

  To reduce that dependence on desktop OpenGL, OutFox now includes an OpenGL ES 2.0 rendering path.

  OpenGL ES uses a smaller and more tightly defined graphics API. It is widely used on embedded systems, single-board computers and other low-power hardware, making it an important part of our support for Raspberry Pi systems and SoC-based devices.

  This is not a reduced “mobile version” of OutFox.

  The OpenGL ES renderer is part of the same engine and is expected to preserve the established rendering behaviour needed by themes, noteskins and game content. It gives us another supported graphics path for systems where traditional desktop OpenGL is unavailable, unreliable or unnecessarily heavy.

  On Windows, we are also developing support through ANGLE.

  ANGLE translates OpenGL ES rendering calls into graphics APIs provided more directly by the operating system. Our current Windows work uses Direct3D 11, giving OutFox an alternative to relying on the quality of a machine’s native OpenGL driver.

  This matters because Windows OpenGL support is largely controlled by individual graphics vendors. Where those drivers are incomplete, inconsistent or no longer maintained, ANGLE gives us another route to the hardware.

  ANGLE can also support other native graphics backends, including Vulkan and Metal. Those provide possible paths for future platform work, but they should not be confused with the backends currently completed and qualified in OutFox.

  The aim is not to replace every renderer with one fashionable API.

  It is to give OutFox several dependable rendering paths, each suited to the hardware and operating system beneath it:

  • Desktop OpenGL for systems where it remains the right choice
  • OpenGL ES for embedded, low-power and SoC hardware
  • ANGLE through Direct3D 11 for improved consistency on Windows
  • Additional ANGLE backends where they become useful and properly tested

  For players, this work should be uneventful.

  The game should start, render correctly and behave consistently without requiring players to know which graphics translation layer or driver path is being used underneath it.

  For the project, however, it means less dependence on one graphics API, fewer vendor-specific surprises, and a stronger base for supporting both modern systems and unusual hardware in the years ahead.

• Engine Chronicle #2: From Glad-FFP to Glad-Prog

  Jun 29, 2026   Engine Chronicles

  Not every major engine change is immediately visible to the player.

  For many years, StepMania and Project OutFox relied on OpenGL’s fixed-function pipeline. In OutFox, this rendering path is known as Glad-FFP.

  Fixed-function rendering comes from an older generation of graphics hardware, when much of the rendering process was controlled through a predefined set of operations. It served the engine well, supported years of community content, and helped StepMania run across a remarkably broad range of systems.

  It is also increasingly distant from how modern graphics hardware is designed to work.

  To provide a stronger foundation for current and future systems, we developed Glad-Prog, OutFox’s fully programmable OpenGL rendering path.

  Glad-Prog replaces the assumptions of the fixed-function pipeline with a qualified shader-pair system. This gives the renderer a cleaner and more maintainable architecture, while providing the control needed for future graphics work.

  This is not simply about adding prettier effects.

  A programmable pipeline allows rendering behaviour to be defined more precisely, removes limitations inherited from the older path, and gives our mod-file and gimmick communities a more stable foundation for building visual effects.

  Compatibility has remained central throughout this work.

  Themes, noteskins and other community content built around the established StepMania rendering behaviour still need to function correctly. Glad-Prog has therefore been developed to preserve that behaviour while moving the underlying renderer onto modern graphics architecture.

  Glad-FFP has not been removed.

  Project OutFox continues to support it for older graphics hardware and legacy systems that cannot use the programmable renderer. Modernising OutFox does not mean discarding working hardware simply because it is old.

  Glad-FFP remains part of our compatibility path.

  Glad-Prog is the foundation we will build on from here.

• Engine Chronicle #1: Retiring RageSound

  Jun 29, 2026   Engine Chronicles

  Today marks a major change inside Project OutFox.

  After roughly 25 years in the StepMania engine family, RageSound has been retired and replaced by SereneAudio.

  Most players will never have encountered RageSound by name. It was not a menu option or a visible feature. It was one of the engine systems responsible for moving music, sound effects and keysounds from game content to the audio hardware.

  RageSound supported StepMania and Project OutFox across several generations of computers and operating systems. It ran on machines ranging from Windows XP systems and PowerPC Macs to modern Windows and Linux hardware. It also carried years of compatibility work for sound devices, drivers and platform APIs that have long since disappeared.

  That history matters, but it also came with a cost.

  After more than two decades, the audio system contained assumptions, workarounds and limitations inherited from several different eras of hardware. Fixing one problem could disturb behaviour elsewhere, while adding modern functionality often meant working around architecture that had never been designed for it.

  Continuing to patch RageSound would have kept those limitations at the centre of the engine. We chose to replace it instead.

  SereneAudio is the new audio foundation for Project OutFox. It has been designed around the hardware and operating systems we support today, while retaining the compatibility needed by existing songs, themes, keysounds and gameplay systems.

  This is not simply a renamed component. It gives us a cleaner system to build upon, reduces our dependence on inherited workarounds, and allows future audio development to be based on how OutFox now operates rather than how StepMania worked decades ago.

  Retiring RageSound does not mean dismissing its history.

  It kept the engine playing music through countless releases, hardware changes and operating-system transitions. Project OutFox could not have reached this point without the work that went into it.

  RageSound carried the engine a very long way, SereneAudio takes it from here.