The api docs don’t say wether the SDL_LockSurface calls are recursive… ie, if
you can lock it multiple times, and then subsequent unlocks won’t actually
unlock till you have an unlock for every previous lock.
They are not recursive, but could be made so fairly easily.
Secondly, are the lock/unlock call very costly?
No, they are not, although it’s always better to lock the surface once
before a bunch of surface accesses than to lock it many times during
a single frame.
What happens if some places got missed, and it writes without locking?
It crashes. This only happens when locking is actually required (DirectX
hardware surfaces for one), which is painful to debug.
In my experience, unless you can cache some of your surfaces in hardware
and take advantage of hardware blitters, it’s faster to keep your surfaces
in main memory and copy them all at once, especially for a software rendered
game like Descent. This reduces bus accesses which tend to be slow.
The new MTRR support may alleviate some of this, but I haven’t tested
it for speed yet.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec