rush2-xbox 1.2.2

What changed in 1.2.2: this repository now says which console it was tested on.

An Xbox Series X, in Developer Mode — both of the consoles this was built and measured on are
Series X, so that is the only hardware anything here covers. A Series S has never been tried, not
once: nothing in this repository has been measured on one, and none of its numbers are a promise about
that console. The wording used to say "Xbox Series", which reads as if it covered both, and it does not.

Nothing else changed. The recipe, the patches and the tools are the same as in 1.2.1.

---

Español

Lo que cambia en la 1.2.2: este repositorio ya dice en qué consola se probó.

En una Xbox Series X, en modo desarrollador: las dos consolas en las que se construyó y se midió
esto son Series X, así que es el único hardware al que se refiere lo que dice. En una Series S no se
ha probado nunca, ni una vez: nada de aquí se ha medido en una, y ninguna de sus cifras es una promesa
sobre esa consola. Antes decía «Xbox Series», que se lee como si cubriera las dos, y no las cubre.

No cambia nada más: la receta, los parches y las herramientas son los mismos de la 1.2.1.

rush2-xbox 1.2.1 — how to take a N64Recomp game to UWP

This is a recipe, not a game. It describes how to take a title of the N64Recomp + RT64
family to an Xbox Series in Developer Mode, using Rush 2: Extreme Racing USA as the real case.
Nothing of the game is here.

Documentation only. Nothing to rebuild and nothing to reinstall: the build, the appx and every
file of the recipe are the ones in v1.2.0.

What changed: a fault narrower than stated, and a cause that was never tested

The owner, playing on the console, pinned down where the 2049 acceleration platforms actually
misbehave: only in STUNT events. Not in SINGLE RACE, not in CIRCUIT.

That one detail undoes the explanation this repository had been giving. The cause was stated as
upstream's unported 0x10 collision branch — func_800E1F80, left "for a future runtime patch" in
docs/rush2049_research/collision.md. But that branch is what pushes the car in any mode, and
the same document counts 0x10 polygons on race tracks as well: 78 on track 2, 3 on track 3, 4 on
track 5, besides the arenas and the obstacle course. A branch that is simply absent fails
everywhere, not in one menu row.

So the report stands and the cause goes back to not known. Issue #3 now carries both the scope
and the test that would separate the two readings: drive a 2049 race track that has pads and
watch whether they push. If they do, something specific to the stunt arenas is at fault; if they do
not, it was always broken everywhere and STUNT is merely where you notice.

Why that deserves a release of its own. It is the second claim here to be walked back in two
days — the first was the launch time, blamed on the console — and both for the same reason: an
observation was turned into a cause with no test in between. That pattern is more useful to the next
person than either correction is.

If you came for the launch

It is in v1.2.0 and unchanged here: 5–6 minutes down to ~20 s, with no black screen, from two
independent causes — the mipmap addressing modes making RT64 emit a shader that costs ~200 s to
build instead of 0.3 s, and the first frame waiting for an ubershader pipeline that no draw call
ever uses. Both are written up in docs/HOW-IT-WORKS.md, together with how
to find out which pipeline is the expensive one and how to show something on screen while the
shaders are still compiling.

What is in the zip

Everything the v1.2.1 tag contains — 14 files: the five-step build recipe with the reasoning
beside each decision, one patch against RT64's plume (MIT) kept as a record of a dead end, and the
documentation in English and Spanish.

rush2-xbox-1.2.1.zip
SHA-256  47e989ba35ba3f4865b82dff2e2afc949419217026125355915dac6efb3ac9aa

What is still open

The port plays, at 59 FPS, and the owner confirmed this build on an Xbox Series X. Left on the
table: the game never opens the Controller Pak (#5), the acceleration platforms misbehave in
stunt events and nobody knows why yet (#3), a remnant of the sky fault shows as light triangles
in the top-left corner on tight curves (#6), and a playthrough from start to finish is still
untested (#1).

License

MIT, as N64Recomp and RT64 are. Nothing of the game project is here: it publishes no
license. The UWP forks the recipe builds on are worleydl's.

Rush 2: Extreme Racing USA is © Midway. Not affiliated with them, with Microsoft, or with the
authors of N64Recomp, RT64, the game project or the UWP forks. Rights holders:
jajdpmail@gmail.com.

rush2-xbox 1.2.0 — how to take a N64Recomp game to UWP

This is a recipe, not a game. It describes how to take a title of the N64Recomp + RT64
family to an Xbox Series in Developer Mode, using Rush 2: Extreme Racing USA as the real case.
Nothing of the game is here.

What changed: the launch was never the console

Until this release the documentation said that a launch takes minutes because the driver needs
180–190 s to build some of the pipelines, and that caching one is impossible on this console. The
second half is true. The first was a symptom — and the two real causes are measured, named and
written up:

1. The mipmap addressing modes. On the RDP it is normal for the higher mipmap levels to be
marked CLAMP while the lower ones are WRAP: there is nothing to repeat on a two-texel level. RT64
compares the modes of every level, and when they differ it drops the native sampler and emits a
shader that branches per sample. On an Xbox Series that shader costs ~200 s of pipeline creation
against 0.3 s for the plain one — seven of them ate 1 337 s of a 1 448 s launch. Taking
level 0's mode for every level: worst shader 262 s → 8.8 s, and the image is identical.

2. The first frame was waiting for the ubershader. State::fullSync() joins the threads that
create its eight pipelines before rendering anything; the first costs 26.8 s here and the other
seven are free. While the game thread sits in that join there is no workload, no present, and so
no logo, no interface and no loading bar — that was the 27 seconds of black screen before the
logo. And a counter says no draw call ever falls back to the ubershader: those seconds were
spent on a pipeline that does not draw a triangle.

	before	after
first frame on screen	~28 s	~0 s
the game, running	~50 s	~22 s
whole launch	5–6 min	~20 s

Two more things worth taking: how to find out which pipeline is the expensive one — log
psoDesc.PS.BytecodeLength next to the creation time and match it against the compiled .dxil
sizes — and how to show something while the shaders compile, when the only thing available is
clearColor over rectangles.

What is in the zip

Everything the v1.2.0 tag contains — 14 files: the five-step build recipe with the reasoning
beside each decision, one patch against RT64's plume (MIT) kept as a record of a dead end, and the
documentation in English and Spanish.

rush2-xbox-1.2.0.zip
SHA-256  ba7ff11484064f9b3b2865001b3abd9929d9f82248a3e628f197a95123881b61

What is still open

The port plays, at 59 FPS, and the owner confirmed this release on an Xbox Series X. Left on the
table: the game never opens the Controller Pak (#5), the boost pads are missing upstream and
not here (#3), a remnant of the sky fault shows as light triangles in the top-left corner on
tight curves (#6), and a playthrough from start to finish is still untested (#1).

The two decisions that are not obvious

The game's libraries cannot be built with the Visual Studio generator. MSBuild has no ClangCL
toolset for "Application Type = UWP" — asking for it with WindowsStore gives MSB8020 — and
cl.exe breaks the ecosystem, which is written for clang. The way is Ninja + clang-cl, with the
libraries as a desktop target: what makes them UWP is the _UWP macro from the patches, and the
only real WindowsStore project is the appx one.

The UWP dependency bundle has one branch per engine. Taking the wrong one leaves the link
unfinished with uwp_PickMultipleFiles unresolved.

And five startup traps the next game will hit too

SDL_INIT_HAPTIC does not exist in WinRT's SDL, and the game's own if (SDL_Init(...) > 0) check
never catches the -1 — so it ends up with no video, hanging on the window, with no message;
Windows.Gaming.Input has to be asked for or there is no controller; FOLDERID_LocalAppData is not
LocalState, and portable mode is no way around it; LocalState does not exist until the first
launch; and the container's stderr is invalid, so writing to it is a fail-fast — which is what
made the game vanish mid-race, with no exception, no dump and no message.

License

MIT, as N64Recomp and RT64 are. Nothing of the game project is here: it publishes no
license. The UWP forks the recipe builds on are worleydl's.

Rush 2: Extreme Racing USA is © Midway. Not affiliated with them, with Microsoft, or with the
authors of N64Recomp, RT64, the game project or the UWP forks. Rights holders:
jajdpmail@gmail.com.

rush2-xbox 1.1.1

Documentation only: nothing to reinstall. The recipe, the archived patch and the tooling are
byte for byte those of v1.1.0.

Two credit errors, both in the files that exist to give credit:

• The explanatory block after the MIT text in LICENSE had been copied from another repository of
  this catalogue and never adapted: it claimed this was a derivative of Golden Balloon, denied
  granting rights in Diddy Kong Racing, and listed src/ and package/, which this repository does
  not have. It now states what is actually here.
• plume was described as RT64's own rendering hardware interface. It is
  renderbag/plume — MIT, Copyright (c) 2024 renderbag and
  contributors — which RT64 uses as a submodule. The one patch this repository publishes is against
  plume, so that is the credit that matters most here.

And one thing the documentation never said: N64ModernRuntime and RecompFrontend, which the
recipe also builds, are GPL-3.0, not MIT. Nothing of theirs is reproduced here, but anyone
publishing their own patches against them has to carry their license, not this one.