Some D3D buffers (e.g. vertex buffers) use DirectDraw surfaces for storage.
Since a previous fix for forcing the emulated pixel format on surfaces broke
Alt-Tabbing in Messiah, this fixes it by automatically restoring D3D buffers
during Lock.
If this causes other issues, the only alternative seems to be forcing these
surfaces to system memory (which was the previous broken behavior).
Earlier the update thread was made persistent accross multiple primary surfaces,
but some parts were not correctly updated. The update event handle was still being
closed on release of the primary surface, and the update thread still exited if
there was no primary surface immediately after it received an update event.
When forcing the emulated pixel format to surfaces in CreateSurface,
the original surface description parameter was being modified, leading to
issues with the mouse cursor in Populous 3. Now a copy is modified instead.
Also avoided unnecessary palette update when the palette is being set to null.
The internal surface pointers to the compatible primary surface were not being reset
when the surface was released, possibly leading to other surfaces being misidentified
as the compatible primary surface.
All internal primary surface pointers are now reset to null on release.
Because the actual display mode is always forced to 32 bits color depth,
surfaces that would be created without a pixel format need to be explicitly
set to the emulated display mode's pixel format that the application expects,
rather than letting them use the actual display mode's pixel format.
However, the emulated pixel format was being forced on surface types that aren't
normal surfaces and shouldn't inherit the display mode's pixel format
(e.g. vertex buffers and depth buffers), which prevented some of these surfaces
from being created correctly.
Now the surface type checks are more restrictive.
The palette converter surface was being released even when it was null,
leading to potential problems with releasing the primary surface.
The update thread is also no longer terminated on each release.
Termination may have been necessary more often than expected because
the thread may be waiting on the DirectDraw critical section on release.
There doesn't seem to be any issues with letting the OS clean up
the running thread on exit instead.
