* This will allow the adding of things like 'redundant api call' for calls
that have no effect, as well as potential problems like drawing with an
empty viewport, or similar things that are common problems. Reading out-
of-bounds on buffers etc is a good example of 'defined' behaviour that
is probably not desired.
* These heuristics could also identify potential performance problems.
* It also supports adding debug messages after log-load time, so you could
do an additional extra-strength pass, or do a detailed check of one
draw call (e.g. a broken draw, to try and figure out the problem). If
there are any unread debug messages, the status bar will flash and the
debug messages window will show a count as (N).
* This allows 'partial' rows in the mesh viewer, if a vertex input element
references invalid/out of bounds data, but the others are fine (coming
from different streams).
* When idle if we map a resource that doesn't have backing store (like a
texture that wasn't initialised on creation) we create shadow storage
for the map. We only need it temporarily, so make sure to free it after
we unmap, otherwise it will stick around for hte lifetime of that
resource (!).
* It's not exactly feature parity but it's a start, and any UI would use
this under the hood.
* This means at least linux has a semi user-friendly way to launch and
capture programs - it's limited but you can just use
$ ./bin/renderdoccmd -c /path/to/program "argument string"
from the root of the repository.
* Logfile and capture options (which can't be set yet, but you could easily
hack in something to set them in renderdoccmd.cpp) are passed via
environment variables to the child process.
* At the moment it only works if the files from the capture are in the
exact same absolute paths (so generally on the same machine or same
distro will likely satisfy this, if the library versions are unchanged).
* Also since linux doesn't have a built-in way of verifying that symbols
match via GUIDs there's no checking yet. We could md5 or otherwise hash
the files to make sure they match.
* If there is no match at all we don't prompt for better symbols currently.
* I've added a little platform stamp onto the start of the module database
per-platform just so linux/windows won't try to load each other's symbols
as otherwise the logs are cross-platform. I didn't bump the serialise
version as this is a rarely used (and transient, typically) feature, so
not worth adding backwards compatiblity code. Symbols from an old windows
log won't resolve but that's not a problem. Symbols from a new log won't
load and will probably crash in an old version, but I'm not worried about
that.
* This makes it easier for my auto build scripts (i.e. without xcopy use
I can run them from msysgit bash).
* pdblocate now has Profile32&Release32 vs Profile64&Release64. This was
the easiest way to do it as it has to be compiled in 32bit to interact
with DIA, but we want it copied to the solutions output folder (x64/...
or Win32/...)
* We try and avoid multiple glTexImage2D chunks and instead mark the
texture as dirty if the parameters are the same. This is to avoid the
case where it's called repeatedly just to upload new data. However this
breaks for cubemaps since that's the one case where you HAVE to call it
multiple times just to create the texture. Once for each face-target.
So to compensate, we manually do this with the same parameters, then let
it be overwritten by later chunks & initial data.
* This is invalid since we are talking about real FBOs, not the default
FBO, but it might come up in compatibility context programs and it's
harmless to correct to try and replay correctly.
* This is for working with compatibility profiles, which I only plan to do
when it's harmless little tweaks like this. Not in a significant way
(like supporting the fixed function pipeline, display lists, etc).
* The theory here is that glDisable on a deprecated cap is 'harmless' as
it's already off by not existing. And maybe when capturing a mostly-core
program that has some legacy code or runs in compatibility, it calls
glDisable for these caps but never plans to use them. So we can ignore it
* If glEnable is called though, we serialise that and it will fire errors
and the replay will be wrong. That doesn't change.
* Technically we need to try and restore the VAOs even if disabled to the
correct setup, so that if they're just enabled they are in the expected
state. However if the attribs are in an invalid state it's not legal to
just enable them again, so they need to be respecified anyway.
* This might have something to do with compatibility profiles - it was
seen capturing Wolfenstein: The New Order, which runs 3.2 compatibility.
* If the pixel store parameters are relatively simple we go through a
fast path that's about the same as it was before, otherwise we manually
unpack to a tightly packed buffer for serialising. Hopefully this should
rarely happen.
* glPixelStore parameters are only serialised when capturing a frame, and
the pixel store parameters at frame start form part of the initial state
vector.
* The real implementation can do more if it wants, and align to a larger
alignment, but we just return 64 to the program and align to that, which
satisfies the extension minimum requirements (and chances are no program
takes advantage of wider alignment anyway).
* Many debug messages are completely useless without context, so to track
down bugs in crashdumps with logs, etc, it would be very useful to add
a little snippet to show what function call the message was fired from
and what the parameters were.
* I'll just add these as/when necessary for tracking bugs.
* Eventually I'll add a wrapper layer so that if EXT_dsa isn't present then
it just gets emulated, but for now we require it to be present even if
the captured program didn't use it.
* Also added handling for dirty buffer textures - there are no contents to
copy, those are handled with the buffer, so instead we just grab the few
parameters that are valid to re-specify the buffer texture.
baldurk