A fresh renderer is built per mission, and the particle engine's vertex
buffer is D3DPOOL_DEFAULT with a texture to match - both bound to the
device that made them. Initialize overwrote the two pointers with the
new device's resources without releasing the old ones, so the old device
kept a reference from resources nothing could reach any more.
~DPLRenderer's SAFE_RELEASE(mDevice) therefore never took it to zero.
Every race left a whole live device behind it - back buffer, depth
buffer and all, at whatever the render target is, which on the tester's
machine is 2560x1440. The next race's Initialize was the only thing that
ever let one go, so quitting from the front end let it go never.
Measured rather than assumed, with a standalone test using the same pool
and usage: release the device with the buffer outstanding and it reports
1 reference left, still alive. Release the buffer first and it reports 0.
Three parts to it:
- Destroy is null-safe now, and clears what it drops. It was neither,
and it runs on the device-lost path AHEAD OF A RESET - so a texture
that never loaded, which a missing VIDEO\particles.png is enough to
cause, took the Reset down with it. A released pointer left in place
is a dangling one the moment anything looks again.
- Initialize calls it first. The device-lost path already released
before re-initialising; this is the same contract for the case where
the device is not lost but REPLACED, which is what a new race is.
- ~DPLRenderer calls it before releasing the device, next to the texture
cache flush that is there for exactly this reason and had missed this
one. The device now dies with the mission that made it.
Destroy clearing mDevice is what makes the gap between it and the next
Initialize safe: the paint paths already test that pointer before they
touch anything.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
CydandClaude Opus 5
4410febd4c