Sylpheed RE agent d90d14e021 [RE] Log render-target state, resolves and PS constants on every UI draw
The UI draw log recorded blend state, textures and geometry, which is
enough to say WHICH sprite a draw is and how it composites, and not
enough to answer whether a screen has more than one PASS. A second draw
into an off-screen target, or a resolve of the EDRAM into a texture that
a later full-screen quad samples, both look like just another quad in
the old format.

Three additions, all read straight out of the register file:

  mode=       RB_MODECONTROL.edram_mode. kCopy (6) is how this GPU issues
              a RESOLVE, and it arrives through the same DRAW_INDX packet
              as a sprite -- so without this field a resolve was
              indistinguishable from a draw.
  rt0=/pitch  RB_COLOR_INFO's EDRAM tile and format, RB_SURFACE_INFO's
              pitch and MSAA. A second target shows up as a different
              tile; a half-resolution post-process shows up as a pitch
              that is not the screen's.
  RESOLVE     on a kCopy draw, RB_COPY_CONTROL and RB_COPY_DEST_BASE.
              That destination reappearing as a later tex[base=...] is
              what 'resolve-and-resample' means stated in addresses,
              rather than inferred from the picture.
  ps_c[...]   the pixel shader's float constants, taken off its OWN
              float_bitmap -- the same one the backend uploads from -- so
              this is the shader's declared dependency set rather than a
              fixed window that could miss the one that matters. Pixel
              constants live at SHADER_CONSTANT_256_X and the c# printed
              is the index the shader's disassembly uses.

Without the constants, an alpha ramp driven by a shader constant and one
driven by per-vertex colour are the same picture.
2026-09-01 16:13:43 +00:00
2026-03-27 11:17:55 +09:00
2025-11-20 03:53:43 -08:00
2025-11-20 03:53:41 -08:00
2025-11-20 03:53:41 -08:00

Xenia Canary - Xbox 360 Emulator

Xenia Canary is an experimental fork of the Xenia emulator. For more information, see the Xenia Canary wiki.

Come chat with us about emulator-related topics on Discord. For developer chat join #dev but stay on topic. Lurking is not only fine, but encouraged! Please check the FAQ page before asking questions. We've got jobs/lives/etc, so don't expect instant answers.

Discussing illegal activities will get you banned.

Status

Buildbot Status Releases
Canary (🪟, 🐧) CI Codacy Badge LatestAllOld

Experimental Netplay

Buildbot Status Releases
Windows Codacy Badge Latest

Quickstart

See the Quickstart page.

FAQ

See the frequently asked questions page.

Game Compatibility

See the Game compatibility list for currently tracked games, and feel free to contribute your own updates, screenshots, and information there following the existing conventions.

Building

See building.md for setup and information about the xb script. When writing code, check the style guide and be sure to run clang-format!

Contributors Wanted!

Have some spare time, know advanced C++, and want to write an emulator? Contribute! There's a ton of work that needs to be done, a lot of which is wide open greenfield fun.

For general rules and guidelines please see CONTRIBUTING.md.

Fixes and optimizations are always welcome (please!), but in addition to that there are some major work areas still untouched:

See more projects good for contributors. It's a good idea to ask on Discord and check the issues page before beginning work on something.

Disclaimer

The goal of this project is to experiment, research, and educate on the topic of emulation of modern devices and operating systems. It is not for enabling illegal activity. All information is obtained via reverse engineering of legally purchased devices and games and information made public on the internet (you'd be surprised what's indexed on Google...).

Description
No description provided
Readme BSD-3-Clause 71 MiB
Languages
C++ 97.8%
Python 1%
CMake 0.4%
GLSL 0.2%
HLSL 0.2%
Other 0.2%