## Link to GitHub Issue or related Pull Request, if one exists
#0
## Description of change
Capturing a frame for the API stream made the game wait for
`GetRenderTargetData` in the middle of its present, roughly 1270us per
frame at 1080p. A 120Hz cab visibly lost frames for as long as a viewer
was connected.
The present thread now only issues a `StretchRect` into a render target
we own, which is queued rather than waited on, and a pool thread does
the readback and the pixel conversion. That takes the present thread
cost to 1-4us. Each snapshot is read on the request after the one that
took it, so the blit and its transfer have a full frame to land and the
read does not stall on the GPU either, at the cost of one frame of
stream latency.
Only streaming takes this path, and only on a device created with
`D3DCREATE_MULTITHREADED`. Screenshots, `capture.get_jpg` and the
`THREAD_BAN` models keep the existing inline readback unchanged.
Also raises the x264 encoder from `i_threads = 1` to 4, which was
holding a 1080p60 stream to 41fps and making a keyframe cost 12.7ms
against 6.6ms for an ordinary frame. Capped rather than automatic
because this encodes on the same machine it is capturing.
## Testing
tested against iidx33, which was the most sensitive to frame drops
## Link to GitHub Issue or related Pull Request, if one exists
#0
## Description of change
Moves the API capture readback off the game's Present thread while a
video stream client is connected.
The readback is a `LockRect` plus a memcpy of the whole back buffer,
roughly 635us at 720p and 1270us at 1080p. On the Present thread that
comes out of the game's frame budget: TDJ (at 120Hz) dropped to 117fps
with a 60fps stream running, and reading on a pool thread instead gave
the full 120 back.
Only streaming takes the off-thread path, gated on a new
`capture_pump::screen_claimed()`.
Screenshots, one-off API captures, and `THREAD_BAN` games all keep the
existing inline read for compat reasons. A pool thread in `LockRect`
while the Present thread sat inside `GetRenderTargetData` deadlocks DDR
X2 for example.
`CLAIMED[]` becomes `std::atomic<bool>` so the capture path does not
take a lock on the Present thread. The read pool has a single worker so
frames cannot be enqueued out of order, and both capture pools are never
destroyed so a late read cannot queue onto a torn-down pool.
The capture pipeline itself is unchanged: `GetRenderTargetData` is still
synchronous on the Present thread.
## Testing
DDR X2
World
IIDX TDJ
SDVX VM
## Link to GitHub Issue or related Pull Request, if one exists
#0
## Description of change
Significantly speeds up API screen capture and D3D9 screenshots saving.
Two reasons for doing this:
1. We now have a 4K game (GITADORA) and existing capture code was taking
multiple seconds.
2. Renewed user interest on streaming as we have a couple more companion
apps in active development.
**API screen capture (streaming), 1280x720:** 14.3ms -> 6.3ms per frame.
Back buffer copies go to pooled `D3DPOOL_SYSTEMMEM` surfaces via
`GetRenderTargetData` instead of allocating a lockable render target
every frame, and TooJpeg is replaced with libjpeg-turbo (encode 9.8ms ->
3.0ms). MSAA remains unsupported
**Screenshots for GITADORA arena model, across 4 screens with one of
them 4K**: 4068ms -> 124ms. `D3DXSaveSurfaceToFileA` is replaced with
fpng (encode 4043ms -> 76ms) and the screens encode in parallel.
Dropping D3DX also removes the `d3dx9_43.dll` ... `d3dx9_24.dll` probing
loop, so screenshots no longer fail outright on machines with no D3DX9
runtime installed.
Screenshot surfaces are read on the present thread, so no D3D call
reaches another thread for screenshots. This fixes a hang in DDR X2
introduced earlier in the branch: its device has no internal locking,
and reading the surface on a pool thread while the present thread sat
inside `GetRenderTargetData` left the game's own render thread
deadlocked.
## Testing
- **GITADORA** (arena model, D3D9Ex, 4K main plus three subscreens,
windowed) with
`-screenshotsub`: three sets of four screenshots, images verified
correct. Completion
order differs between sets, so the screens really are encoding in
parallel.
- **LovePlus** (KLP, plain D3D9, 768x1360): covers the inline path used
by games whose
image processing must not leave the present thread.
- **API screen capture** through a companion app: live video correct
throughout.
- **Print Screen** bound as the screenshot key: the clipboard copy
succeeded on every shot.
- Quitting the game after capturing leaves no `IDirect3DDevice9`
reference count warning,
so the pooled readback surfaces are released along with the device.
## Link to GitHub Issue or related Pull Request, if one exists
#0
## Description of change
Adds `-screenshotsub`. Off by default. When on, screenshots include the
subscreens. All subscreens are captured, even if they are hidden from
view. Works for all four screens of gitadora arena model as well.
This should also fix an issue with API / companion app not capturing
gitadora subscreen correctly.
Note: only done for DX9... DX11 will need another PR to make this work.
Unrelated to this PR, there seems to be a bug with gitadora not
accepting mouse or api touch input.
## Testing
## Link to GitHub Issue or related Pull Request, if one exists
#0
## Description of change
Adds the `-screenshotoverlay` option.
By default, file screenshots exclude the Spice overlay. Enabling this
option captures screenshots after the overlay is rendered.
Also updates DX11 backend to allow screenshots even when overlay is
disabled.
## Testing
## Link to GitHub Issue or related Pull Request, if one exists
n/a
## Description of change
Create a new thread that polls for the following hotkeys:
* super exit (both alt+f4 and bound key)
* coin insert
* screenshot
The goal is to make the capture of these more reliable, because before
this PR it wasn't.
## Testing
bicarusandGitHub