Bayonetta 3 Recomp v0.1.5

Bayonetta 3 Recomp v0.1.5

Cutscenes on Android now follow the game's own timing, as on Windows since v0.1.4, plus a fix for a cutscene that
could freeze on its first frame.

Android: as before, the release holds no APK, because the game library inside it is built from your own dump.
Build and install it from this source with android\build_bayonetta3.ps1 -Install (or android/build_bayonetta3.sh),
as described in docs/PLAYING.md. Your game data and saves in Internal storage/Bayonetta 3 are kept.
Windows, coming from v0.1.4: unzip this release over your folder (your private\ folder, saves and settings are
kept) and choose Rebuild in the launcher. Only the runtime changed, so the code generation step has nothing to redo.

Changes

• Android: the game picks the cutscene frame. Until now the Android build guessed which film and which frame to
  show from the order the game opened the films and from the wall clock. It now watches the game's own movie decoder
  ask for each frame, as the Windows build has since v0.1.4. That request names the film and the frame's timestamp,
  so each frame comes from the right film at the game's own time (#3). NX_MOVIE_VTABLE=0 in config.txt turns
  this off and goes back to the v0.1.3 behaviour.
• Fix (Windows and Android): a cutscene could freeze on its first frame. The game opens the next film while the
  current one plays. While the current film was playing, the next one could take one of its picture updates. That
  started the next film's clock early, so by the time the game asked for its frames it had already run to its end,
  and its picture stayed on the first frame for the whole film. Seen on Android in the Prologue's third film
  (ev0022); v0.1.4 on Windows had the same race, it just did not show up in testing. A picture update the game asked
  for now goes only to the film it asked for.

Verified

On an Android phone (Snapdragon 8 Gen 2, Adreno 740) and on Windows, with this build:

• Opening: ev0000, ev0005, ev0010 and ev0011 each play to the end, each after the previous one.
• Prologue: ev0020, ev0021, ev0022 and ev0023 each play to the end, ev0022 included.
• Every frame timestamp the game asked for matched the decoded frame. 0 FATAL and 0 crashes.
• New unit test for the freeze. The movie unit tests pass for the desktop and the Android build.

Not checked yet: the skill-tree and tutorial demo videos (a menu the test driver cannot reach).

Known issues and not tested yet

As in v0.1.4: a full playthrough from a new save has
not been verified, and rendering still has issues. Ultrawide (ultrawide in the launcher) widens only the 3D view
for now; menus, HUD and text are still stretched (#4). When something fails, attach the log
(private\win\logs\game.log on Windows, Internal storage/Bayonetta 3/nx.log on Android), your OS, CPU and GPU.
Never attach game files, saves, keys or anything made from your dump.

This is an independent fan project, not affiliated with or endorsed by Nintendo, PlatinumGames or SEGA. Use only
game files you obtained legally yourself.

Bayonetta 3 Recomp v0.1.4

Bayonetta 3 Recomp v0.1.4

Cutscenes on Windows now follow the game's own timing. Download, unzip and run as for v0.1.3.
Coming from v0.1.3: unzip this release over your folder (your private\ folder, saves and settings are kept) and
choose Rebuild in the launcher. Only the runtime changed, not the recompiler, so the code generation step has
nothing to redo.

Changes

• Windows: the game picks the cutscene frame. Until now the runtime guessed which film and which frame to show
  from the order the game opened the films and from the wall clock (the guess v0.1.3 corrected for #3). The runtime
  now watches the game's own movie decoder ask for each frame. That request names the film and the frame's
  timestamp, so each frame comes from the right film at the game's own time. Nothing else in the game's behaviour
  changes. NX_MOVIE_VTABLE=0 turns this off and goes back to the v0.1.3 behaviour.
• Android still uses the v0.1.3 behaviour (open order and wall clock). It will move over once it has been checked
  on a phone.

Verified

Headless Windows runs of the release build:

• Opening: ev0000, ev0005, ev0010 and ev0011 each play to the end. The timestamps the game asks for match the
  decoded frames exactly, and no frame was missing.
• Prologue: ev0020, ev0021, ev0022 and ev0023 each play to the end.
• 0 FATAL and 0 crashes in these runs. The unit tests pass for the desktop and the Android build.

These runs also confirmed the order v0.1.3 uses: the game plays ev0010 to its end before it asks for ev0011.

Not checked yet: the skill-tree and tutorial demo videos (a menu the test driver cannot reach), and Android on a
phone.

Known issues and not tested yet

As in v0.1.3: a full playthrough from a new save has
not been verified, and rendering still has issues. Ultrawide (ultrawide in the launcher) widens only the 3D view
for now; menus, HUD and text are still stretched (#4). When something fails, attach private\win\logs\game.log (or
game.log.prev after starting the game again), your OS, CPU and GPU. Never attach game files, saves, keys or
anything made from your dump.

This is an independent fan project, not affiliated with or endorsed by Nintendo, PlatinumGames or SEGA. Use only
game files you obtained legally yourself.

Bayonetta 3 Recomp v0.1.3

Bayonetta 3 Recomp v0.1.3

A fix for the Prologue's third cutscene in #3. Download, unzip and run as for v0.1.2.
Coming from v0.1.2: unzip this release over your folder (your private\ folder, saves and settings are kept) and
choose Rebuild in the launcher. Only the runtime changed, not the recompiler, so the code generation step has
nothing to redo.

Fixes

• The Prologue's third cutscene never reached the screen (#3). The opening plays four films in a row (ev0000 →
  ev0005 → ev0010 → ev0011). The game opens the next film while the current one is still playing, and the
  runtime kept only one film at a time, so opening ev0011 one frame into ev0010 ended ev0010. You heard ev0010
  over ev0011's picture, and then ev0011's sound over a black screen. Every open film now has its own playback
  session. The film that is playing keeps the picture until the game closes it or it has shown its last frame. The
  film the game opened early then starts from its own first frame.
• When the playing film has no decoded frame yet, the screen stays blank for that moment instead of starting the
  next film's clock early.

Verified

Headless Windows runs of the release build. Windows and Android pick the film the same way (by open order and wall
clock), so these runs cover the Android logic too:

• Opening: ev0000, ev0005, ev0010 and ev0011 each play to the end. ev0010 now gets about 2,600 frames,
  where before it got one.
• Prologue: ev0020, ev0021, ev0022 and ev0023 each play to the end. The game opens each next film early, and
  none of them takes over the screen.
• 0 FATAL and 0 crashes in these runs. Frames sampled during ev0010 and ev0011 show each film's own pictures.

Not checked yet: the skill-tree and tutorial demo videos (a menu the test driver cannot reach), and the Android
build on a phone.

Known issues and not tested yet

As in v0.1.2: a full playthrough from a new save has
not been verified, and rendering still has issues. Ultrawide (ultrawide in the launcher) widens only the 3D view
for now; menus, HUD and text are still stretched (#4). When something fails, attach private\win\logs\game.log (or
game.log.prev after starting the game again), your OS, CPU and GPU. Never attach game files, saves, keys or
anything made from your dump.

This is an independent fan project, not affiliated with or endorsed by Nintendo, PlatinumGames or SEGA. Use only
game files you obtained legally yourself.

Bayonetta 3 Recomp v0.1.2

Bayonetta 3 Recomp v0.1.2

Fixes for the hidden-stage crash in #2 and for a late exit inside a stage. Download, unzip and run as for v0.1.1.
Coming from v0.1.1: unzip this release over your folder (your private\ folder, saves and settings are kept) and
choose Rebuild in the launcher. The recompiler changed, so Rebuild runs the code generation again; only what
changed is redone.

Fixes

• The red diamond stages exit on entry (#2). The hub's wall map has red diamond nodes beside the purple chapter
  nodes: those are the Phenomenal Remnants, each chapter's optional challenge stage. Entering one closed the game
  with FATAL: call into the middle of a function: main+3e6af0 (or main+3e6c88 on the second table just after
  it). The switch that picks which stage to load has 270 entries and the recompiler recovered only the first 256, so
  a stage whose index was above 255 and pointed somewhere new reached a case that did not exist and called into
  the middle of a guest function. The table bound was being cut short by a cbz between the cmp and the b.hi:
  cbz/cbnz/tbz/tbnz read a register and leave the cmp's flags alive, so the scan now steps over them.
  Both 270-entry switches now carry all 35 of their targets, and Phenomenal Remnants load and play.
• Re-analysis also stops inventing cases for 13 other tables, where the 256-entry fallback had been reading the
  bytes that follow the table and turning them into in-function addresses. Those cases were labels pointing at data,
  never real entries; they are gone, no real target was dropped.
• A late exit inside a stage (service 'ILogger' command 0 is not implemented). lm returned an empty
  ILogger, and after a while in a stage the game calls Log on it and the process exited with no tombstone. The
  commands the game actually sends — Log, SetDestination, TransmitHashedLog, DevNotify — now accept and
  drop their input, as on retail; unimplemented commands of later versions still fail loudly. After the fix, a
  Phenomenal Remnant ran for over two hours with no FATAL line.

Known issues and not tested yet

As in v0.1.1: a full playthrough from a new save has not
been verified, rendering and cutscenes still have issues, and the Prologue story transition has a loading problem.
What has been played through beyond that: a Phenomenal Remnant, from the hub into the stage and in the stage. When
something fails, attach private\win\logs\game.log (or game.log.prev after starting the game again), your OS, CPU
and GPU. Never attach game files, saves, keys or anything made from your dump.

This is an independent fan project, not affiliated with or endorsed by Nintendo, PlatinumGames or SEGA. Use only
game files you obtained legally yourself.

Bayonetta 3 Recomp v0.1.1

Bayonetta 3 Recomp v0.1.1

Fixes for the first two reports. Download, unzip and run as for v0.1.0. Coming from v0.1.0: unzip this release
over your folder (your private\ folder, saves and settings are kept) and choose Rebuild in the launcher; only
what changed is built again.

Fixes

• Render resolution (#1). The game renders at its own console size: 1600x900 docked, 1280x720 in handheld
  mode, whatever the window is; the window size only sets what that picture is scaled to. The settings said the
  window was the render size; they now say what it is, and the setting is called Window size. To render at
  1600x900, turn Handheld mode off (launcher, Settings, System; or handheld=0 in private\b3.conf); FSR 1
  sharpens the scaled picture. NX_HANDHELD=0 set directly also counted as handheld before; it now means docked.
  An internal resolution above 900p is not available yet.
• The Old Picture Book (#2, if that is the stage). Without program 1 of the 1.2.0 update the book cannot open
  the Bayonetta Origins prologue: the game closes and starts again at the title. It now says so in a message box,
  with how to add it. Put your own program 1 in a program1 folder beside exefs and romfs in your dump (its own
  exefs and romfs) and choose Rebuild: it is now picked up after the first setup too.
• The launcher's help for Frame rate says what 90 / 120 Hz does now.

Known issues and not tested yet

As in v0.1.0. When something fails, attach
private\win\logs\game.log (or game.log.prev after starting the game again), your OS, CPU and GPU. Never attach
game files, saves, keys or anything made from your dump.

This is an independent fan project, not affiliated with or endorsed by Nintendo, PlatinumGames or SEGA. Use only
game files you obtained legally yourself.

Bayonetta 3 Recomp v0.1.0

Bayonetta 3 Recomp v0.1.0

The first release of Bayonetta 3 Recomp: a static recompilation of Bayonetta 3 (Nintendo Switch, version 1.2.0) for
Windows, Linux / Steam Deck and Android. The game's code is translated to C++ and built on your machine from your
own dump. This release contains no game code, game assets, keys or saves, and none are downloaded.

Status: playable, early. The Prologue, cutscenes, audio, input and Chapter 8 (through chapter select with a
progressed save) have been played. A full playthrough from a new save has not been verified.

Download and run

Windows 10/11 (64-bit)

1. Download Bayonetta3Recomp-v0.1.0-windows-x64.zip and, if you like, check it against the .sha256 file
   (certutil -hashfile <zip> SHA256).
2. Unzip it to a folder you can write to, with plenty of free space on the same drive as your dump. A short path
   without special characters works best.
3. Double-click Bayonetta3Recomp.cmd. The launcher opens; choose Set up from my dump and pick the folder that
   holds your dump's exefs\ and romfs\ (and, for the Old Picture Book, program1\ from the 1.2.0 update).

The first setup downloads the pinned build tools from their official releases (hash-checked, about 600 MB), checks
your dump against the 1.2.0 hashes, translates the code and the shaders and builds the game: about an hour on a fast
PC. It resumes where it stopped if you close it. Then Start game.

The zip bundles its own Python, so nothing needs to be installed but a Vulkan driver (and, for the cutscenes, the
free "VP9 Video Extensions" from the Microsoft Store). The programs are not code-signed, so Windows SmartScreen or
Defender may warn about them; download only from this page and check the hash.

Linux / Steam Deck: build from source with docs/PLAYING.md, "Linux / Steam Deck".
Android: build the APK with the same guide, "Android arm64".

What's in it

• 90 / 120 Hz at the right speed. Above 60 Hz the gameplay clock and the game's frame-counted windows (stick
  moves such as back-forward-attack, press buffers, the window after a hit, Witch Time's slow-downs) are converted to
  real time. Without this, gameplay ran at twice its speed at 120 Hz.
• Texture cache (Intel Arc, AMD, Steam Deck). ASTC textures are stored as BC7 in a cache the first time they
  load; from the next load on they are read from it instead of being decoded on the CPU (Prologue on an Arc B390:
  2.7 s of decoding the first time, 56 ms the next, a quarter of the memory).
• Mods: files in private/win/run/b3/mods/<name>/romfs/ replace the game's files of the same path.
• A folder you can move: setup hard-links your dump into the folder (no extra space on the same drive).
• Model detail Highest in the in-game settings panel (F1, or + and − together).
• Rebuild in the launcher (or python tools\b3_win.py update) after a newer release: only what changed is
  built again.
• Keyboard and mouse, controller layouts, FSR 1, anisotropic filtering, Discord Rich Presence (with your own
  application id), the Old Picture Book's prologue and its return to Bayonetta 3.

Known issues

• Not verified end to end: a full playthrough; the Prologue has a known loading/progression issue around the end
  of a cutscene. Chapter select is a way around it.
• Above 60 Hz, hit-stops are shorter (the short freeze when a hit lands still counts frames).
• The 90/120 Hz timing conversion was measured with scripted runs, not played by hand yet. If moves or Witch Time
  feel off above 60, set the frame rate to 60 and tell us.
• First visits still decode textures on GPUs without ASTC; only later visits read the cache. The BC7 encoder uses
  one mode: about 45 dB against the original on average, lower on blocks with several distinct colours.
• Linux has no one-command setup yet; it is a manual build (docs/PLAYING.md).
• Phones throttle as they heat up; the Balanced 40 profile holds better than Unlocked.

Not tested yet

Please report what you see with these:

• This zip's Set up and Rebuild in the launcher on a fresh Windows PC (the steps were run from the command
  line, the launcher's progress view was checked by its unit test).
• The texture cache on a Steam Deck or another AMD GPU (it was measured on Intel Arc).
• Keyboard and mouse played by hand.

When something fails, attach private\win\logs\game.log (and private\win\logs\setup-*.log for a setup problem),
your OS, CPU and GPU. Never attach game files, saves, keys or anything made from your dump.

This is an independent fan project, not affiliated with or endorsed by Nintendo, PlatinumGames or SEGA. Use only
game files you obtained legally yourself.