Some renderer functions attempt to read back a surface's polygons from tess.verts. There are 3 possibilities, none of them good:
The surface uses a static VBO with multidraw. tess.numVerts will be 0: there is nothing for it to read.
The surface uses a static VBO with a single data range. tess.numVerts will be nonzero so the function will think there is data there. But really it is random data left over from whichever surfaces used the buffer last.
The surface does not use a static VBO; it actually writes data to tess.verts. The function may at least work correctly in this case. But reading data from this GPU-mapped memory may cause poor performance as in #849.
I haven't attempted to search for all functions like this, but happened to notice the following ones:
SurfIsOffscreen
AutospriteDeform
Autosprite2Deform
Note that some "autosprite" code is already known to be broken (#730). We might detect more suspicious functions by mapping the buffer as write-only, or setting it to null when a static VBO is active.
Some renderer functions attempt to read back a surface's polygons from
tess.verts
. There are 3 possibilities, none of them good:tess.numVerts
will be 0: there is nothing for it to read.tess.numVerts
will be nonzero so the function will think there is data there. But really it is random data left over from whichever surfaces used the buffer last.tess.verts
. The function may at least work correctly in this case. But reading data from this GPU-mapped memory may cause poor performance as in #849.I haven't attempted to search for all functions like this, but happened to notice the following ones:
Note that some "autosprite" code is already known to be broken (#730). We might detect more suspicious functions by mapping the buffer as write-only, or setting it to null when a static VBO is active.