TypedArray doesn't implement AutoCloseable on older devices so .use{} caused a crash.
It turned out the special handling for background colours was unnecessary anyway.
- Switch from ActivityResultContracts.GetContent() to OpenDocument()
which restores ACTION_OPEN_DOCUMENT behavior, granting write access
to file descriptors opened in C++ via ContentHandler.openFd().
- Replace unsafe force-unwraps (!!) in EmulationActivity with null checks.
- Improve the column measurement logic so it updates the column width when text changes.
- Use matchParentSize on the clickable target in OutlinedBox so that it is clickable when the OutlinedBox contains contents with dynamic height.
200e26c added controller handling to MovieConfigLayerLoader's
LoadFromDTM but not SaveToDTM. This caused a regression. When starting a
new input recording, MovieManager::BeginRecordingInput calls SaveToDTM,
which doesn't set the controller values in the DTM header to anything.
Then it loads the newly created movie config layer, causing LoadFromDTM
to be called, which in turn causes zeroed out controller values to be
loaded from the DTM header. This leaves the player with all controllers
set to None, making it impossible to control the game.
To fix this, let's move the saving of controllers from
MovieManager::SaveRecording to ConfigLoaders::SaveToDTM.
Independently spotted by both @Dentomologist and me while reviewing
PR #14805
The previous limit was correct for valid VPBs, but an invalid VPB
controlled by a malicious game could contain a non-fractional value
in current_pos_frac, which would allow writing an extra 15 samples
(30 bytes) into the stack. With AFC encoding, this is rounded up to 16
samples, but with much less control over which bytes are written.
Maybe we should be doing some validation, or bounds checking, but I'm
pretty sure this issue was copied from the original ucode, and we kinda
want to stay compatible.
The simpler fix is to just increase the size of raw_input_samples.
I've checked other code paths, and 0x514 samples seems to be the limit.
glMemoryBarrier comes from ARB_shader_image_load_store, so on a desktop context
below GL 4.2 the pointer is null. bSupportsBBox is set from
bSupportsFragmentStoresAndAtomics, which such a driver can still have, so saving
a state reads the bounding box and calls a null pointer.
UsePersistentStagingBuffers() in OGLTexture.cpp already guards the same call with
bSupportsImageLoadStore.
msg_in and msg_out were ending up with only 4-byte alignment, which
is undefined behaviour, since they contain 64-bit fields. Probably
doesn't cause any issues, but it showed up in ubsan.
iwubcode