Project OutFox news posts

Engine Chronicle #28: Measuring More Than Gameplay

Tue, 04 Aug 2026 05:42:40 +0000

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 mea...

Engine Chronicle #27: Every Mode Has Its Own Contract

Tue, 04 Aug 2026 05:42:21 +0000

Project OutFox supports rhythm-game families with very different ideas about input, judgement, holds, mines, keysounds and chart timing.

That means we cannot clean up gameplay by treating Dance as the default answer and forcing every other mode through it.

Some modes care about fresh presses. Others also use buttons that were already held when a row crossed. Hold heads, checkpoints, mines and synthetic inputs do not behave identically everywhere. BMS, PMS, DTX and other formats also carry rules that cannot be reduced to familiar four-panel behaviour.

Those differences are not edge cases.

They ...

Engine Chronicle #26: Tracing Gameplay Judgements

Tue, 04 Aug 2026 05:42:02 +0000

Some of the hardest bug reports we receive are also the shortest:

“That judgement was wrong.”

The player may be completely right, but the final judgement alone does not tell us where the problem happened.

An input passes through several parts of OutFox before it becomes a result on screen. The engine receives it from a device, maps it to the correct panel, relates its timestamp to the song, selects a chart object, applies the rules for the active game mode, and then updates scoring, life, effects and theme behaviour.

A fault anywhere along that route can make the final result look wrong. We ar...

Engine Chronicle #25: Fixing Hold Note Visuals

Tue, 04 Aug 2026 05:41:40 +0000

Recent work on hold notes has focused on cases where the judgement was correct, but the note did not finish cleanly on screen.

Different game modes expect failed and completed holds to behave differently.

In Dance-style gameplay, a failed hold should continue moving through the receptor. The body and tail remain visible so the player can see the hold finish, even though it has already received an NG result.

Pump-style holds need different handling. Once a hold has completed successfully, it should not leave the head, tail or another small visual effect sitting at the receptor after the result ...

Engine Chronicle #24: Cleaning Up Theme Wheel Work

Tue, 04 Aug 2026 05:41:18 +0000

Recent work on Select Music has focused on Simply Love FunZone and soon to be Infinitesimal.

Both themes make heavy use of Lua to control how their music wheels look and behave. That gives them much more freedom than the standard engine wheel, but it also means the theme and engine can end up repeating some of the same work.

A single wheel movement may update the selected song, request grades, refresh chart information, load banners and CDTitles, update previews, rebuild visible rows and move several theme actors.

None of those jobs is unusual on its own, however, the problem appears when both...

Engine Chronicle #23: Why the Obvious Row Optimisation Wasn’t Safe

Tue, 04 Aug 2026 05:40:56 +0000

As part of the continuing crossed-row work, we looked at reducing how much of the chart the engine scans during gameplay.

The idea seemed reasonable. If we know the latest row where something changed, the engine should be able to stop its update there instead of continuing farther through the chart.

StillRiver showed that it was not that simple.

During testing, meaningful gameplay work was still happening beyond the proposed limit. In some cases, the latest changed row was behind the current tap iterator, the mine iterator, or both.

Capping the scan at that point would have saved work, but it ...

Engine Chronicle #22: Checking Held Inputs at the Right Time

Tue, 04 Aug 2026 05:40:35 +0000

While reviewing the crossed-row gameplay path, we found another place where the engine could use the right information at the wrong moment.

Some gameplay rules need to know whether a panel was being held when a chart row crossed the receptors. The older path could answer that by checking whether the panel was held when the engine processed the row.

Most of the time, those moments are close enough to appear identical, however, they are not always identical.

If a frame arrives late, the engine may need to process several rows together. By then, the player may have pressed or released the panel a...

Engine Chronicle #21: The Mine That Got Hit Twice

Tue, 04 Aug 2026 05:40:16 +0000

While reviewing the old crossed-row gameplay logic, we found a mine being judged twice.

The first hit came from a real input. The player pressed the panel while the mine was in range, and the engine handled it normally.

Later, when the same row crossed the receptors, another part of the engine checked whether that panel was still being held. It found the same mine and generated a second hit for it.

Same row, same column and same mine, judged through two different paths.

Both paths exist for valid reasons. OutFox needs to detect a direct press on a mine, but some game modes also need to punish ...

Engine Chronicle #20: From Thirteen Minutes to Under a Minute

Tue, 04 Aug 2026 05:39:55 +0000

The recent loader work has now reached a point where the difference is difficult to miss.

One of our older benchmarks recorded 3,902 songs taking 791.658415 seconds to load. That is just over thirteen minutes. When we began the current round of testing, our active 3,722-song library was still taking 677.246704 seconds.

After working through the loader piece by piece, that same library reached repeated runs of around forty-six seconds. A later validation run completed in 44.012848 seconds. There was no single switch responsible for that change. This was on a USB external 2.5" 5400RPM 2009 lapto...

Engine Chronicle #19: Making the Song Cache Reliable

Tue, 04 Aug 2026 05:39:31 +0000

As part of the loader work, we have also been reviewing how OutFox decides whether cached song data can still be used. Caching is essential for large libraries. Once a song has been parsed, the engine can save the result and avoid repeating the same work every time it starts.

That only helps when the saved data still matches the files on disk.

A chart may have been edited, a banner replaced, metadata corrected, or a parser changed since the cache entry was created. If the engine does not recognise that change, it can load stale information even though the source files are correct.

We have been...