CopyFramebufferToMemory always returned true, even when glReadPixels
failed, and then copied out whatever the readback buffer held from before.
Depth was labeled D24_S8 while GL reads it as float, and the conversion
ignored the source format, so only a D32F destination came out right.
Record the format and the result of each read, convert from that, and
return it. That also fixes the image readback reusing the aspect of an
earlier framebuffer readback.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The backbuffer is a different image every frame, so there's no earlier copy
of it to return, and the lookup fell through to the sync readback buffer.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Depth readback and the GLES stencil readback converted whatever their
buffer last held into PSP memory when the copy failed. The generic stencil
readback asked for depth, which asserts on Vulkan and D3D11. And
ReadFramebufferToMemory clamped the width to the buffer but not the height,
which a block transfer can exceed.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The repack loop used the texture height instead of the row, and the pack
row length was the rect's right edge while glGetTexImage writes whole rows.
Only reachable from the texture debugger.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The OLD_DATA_OK readback cache was keyed by framebuffer and size only, so
two equal-size rects of one framebuffer shared a buffer and each read got
whichever was copied last. Add x, y and the aspect to the key.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The crosshair turns red, and lock-on works, when stencil bit 3 is set at
the centre of the frame, which the game tests by reading the pixel from
VRAM with the CPU (#17936). Hook that and read back the stencil of that
row into the alpha bytes in RAM. The alpha the hardware backends keep
doesn't follow stencil everywhere, so reading color isn't enough.
Adds PerformReadbackStencilToMemory for this (8888 only for now).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Without the shared 512x512 pack texture, the staging texture was made
bw x bh, but the copy lands at bx, by and the read starts there. Depth and
stencil were worse: CopyResource needs the whole size, so nothing was
copied, and the read ran past the end of the mapping and crashed. Only
whole-buffer reads from 0,0 (like the debugger's) worked.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Some old states have replacement hook ops in memory. Since hooks moved out of
memory, those changed the functions' hashes on load, so they weren't hooked
again, and the CPU hit the op as an illegal instruction. Restore the
instructions this session hooked at the same addresses, as the old hooking did.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Its characters are as wide as the saving platform's wchar_t, so states saved on
Windows failed the length check on platforms with a 4-byte wchar_t.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
States from before 2018 saved idle voices uninitialized, so the position can be
garbage, which made the bounds check reject the whole state (Metal Gear Acid 2).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
StopThreads is called inside the
FramebufferManagerCommon::NotifyRenderResized. Issue is, StopThreads is
called inside an active frame, then clears that active frame's timestamp
descriptions. Rendering resumes, and QueueRunner uses the empty list’s
size to select query 0, which was already written.
Fix this by preserving timestamp descriptions for the current frame
when insideFrame_ is true while retaining the cleanup for other frames.
Returns the analyzed function's start, size and code hash at an address,
and the name of the hardcodedHashes entry already matching it, if any.
Replaces patching a printf into HashFunctions() in the docs.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The game converts each video frame into RAM and copies it into the
framebuffer with its own memcpy, which we didn't recognize. The hardware
backends never saw the copy and kept showing the last frame the GE drew.
Same function in the EU (ULES00192) and Korean (ULKS46038) versions.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Silent Hill: Origins shows each frame one late: the first draw of a frame
copies the previous one into its 565 display buffer. A dump of one frame
then displays a copy of the frame before it, taken from memory, and none
of what it draws. When the display buffer's last write came before most of
the frame's drawing, the recorder now records the next frame too, whose
copy puts the recorded frame on the display.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With a hardware renderer, a framebuffer only exists on the GPU, so a dump
copied whatever stale data RAM held when a game sampled a buffer it drew
in an earlier frame. Silent Hill: Origins shows the previous frame by
copying it into its 565 display buffer at the start of the next one, so
its dumps displayed old scratch data. The recorder now reads such buffers
back once before copying them out (not ones drawn during the recording,
which replay draws again).
It asks for the copy without creating a framebuffer: with
BlockTransferAllowCreateFB (which Silent Hill has) a plain readback makes
a new framebuffer at the destination and never writes RAM.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
pspKeys and pspAxis were written from the input thread and the render
thread without a lock. Entering VR camera adjust "released" held keys by
sending PSP button codes as keycodes, which released nothing; use
ControlMapper::ReleaseAll instead.
Input devices are now matched by ID. InputDevice objects are replaced after
device changes, so reference comparison registered the same device again.
Removing a device now releases what it was holding.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ReleaseAllKeys released on the XInput device IDs while input arrives on PAD
IDs, so whatever was held at a disconnect stayed held. Short reads and
report types we don't parse made the pad "disconnect" for several seconds,
and a simple DualSense BT report zeroed the state (pressing DPAD up, since
hat 0 is up). These now keep the previous state.
With HID input turned off we no longer open and block reading the device on
the shared input thread.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Buzz! Master Quiz converts its question videos (sceMpegBaseCscAvcRange)
straight into the middle of the frame it has drawn, at 84,69. The
framebuffer upload only matched writes starting at a framebuffer's
address, so the hardware backends never showed the video. Pass the
written width along and draw just that rectangle into the framebuffer.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Win32 has no share sheet hookup yet, so sharing a file offers to save a
copy of it. ShareFilesAsZip no longer needs an app cache directory, which
Windows doesn't set; it falls back to the memstick cache folder through
DIRECTORY_APP_CACHE. The save dialog now asks before overwriting.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
GetJavaString() returned Java's modified UTF-8, so input like emoji
reached C++ as invalid UTF-8. Commands to Java now get converted the other
way. Request IDs are made on several threads, and the permissions map was
written on the Java UI thread and read on the render thread. The frame
command debug log no longer prints params, which could hold a password.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An input box whose show() threw, a second input box open at onDestroy, and
browse commands dropped for a destroyed activity or failing in
processCommand were never answered, leaving the native side waiting (a
game's OSK forever). The image proxy also crashed the app on a picker
result without a URI, a SecurityException or an OOM.
Input boxes now answer exactly once, instead of a success followed by an
ignored failure.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The passwordMasking flag of System_InputBoxGetString() never reached Java,
and both sides logged the entered text, including RetroAchievements passwords.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
WipeRequesterToken() only reset the screen's token, after CreateViews() had
already handed it to the new views, so nothing was ever forgotten - not even
in ~Screen(), which saw a token of -1. A text input dialog open across a
RecreateViews() (on the RetroAchievements screen, a slow login failing) would
then write through a deleted PopupTextInputChoice, possibly into the field
that took its place: #21708.
Requests made while creating views now get their own token, forgotten
before the views are deleted. Screen-level requests keep the screen's token.
RequestManager: ForgetRequestsWithToken() now locks, and also drops
responses that arrived but weren't processed yet. ProcessRequests() calls
the callbacks one at a time without holding the lock, so a callback that
closes a screen drops the rest of that screen's responses.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With "Memory Stick inserted" off, the savedata modes that show no dialog now
fail with their own "no memory stick" error, as recorded on a PSP with the
stick pulled out (pspautotests utility/savedata/nomemstick). ms0: opens, stats
and directory opens fail with SCE_KERNEL_ERROR_NODEV.
SOCOM: Fireteam Bravo 2's boot-time AUTOLOAD loaded its save anyway, or said
there was no data rather than no memory stick.
test.py gets a test_flags table for tests that need their own headless flags;
this one runs with --no-memstick.
Fixes#21846
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An inverse boolean option was inverted twice, so --windowed forced fullscreen
on. --no-memstick runs with the memory stick removed, for testing that from
headless (which otherwise always inserts one).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
We copied the module into memory at the start of the call, then made the caller
wait for the read. On hardware the module's bytes only arrive at the end, and
until then other threads can use that memory (pspautotests modules/loadrace).
SOCOM: Fireteam Bravo 2 EU (UCES00543) relies on this. Its loader EBOOT loads
SOCOMPSP.PRX on one thread while another builds a GU display list in a 0x40-byte
buffer at the end of its .bss. That list overruns into the free memory right after
it, which is where the game module goes. On hardware the module load later
overwrites the overrun; for us, the overrun overwrote the module's first
instructions, and the game crashed as soon as it started.
The load now runs from a CoreTiming event at the end of the wait. Pending loads
are saved in savestates.
Fixes#18842
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
