* We create fake backbuffer as SRGB if the original default backbuffer was
SRGB in the program.
* All of our output backbuffers are also SRGB, and we enable
GL_FRAMEBUFFER_SRGB when writing to them.
* Add the 'fake' srgb curve applied to linear data to display it as if it
were srgb, which tends to look intuitively correct even if it's not 100%
accurate. See the behaviour existing in D3D11 already.
* This means that all APIs pass byte string types. ALL strings everywhere
in the entire codebase must be assumed to be and treated as UTF-8 content
not ASCII.
* Gets rid of all the horrible %hs specifiers that caused warnings on
linux! Hooray.
* We convert to wide strings, or use wide characters, only when necessary
to use the Win32 API. Some windows specific code will stay in wide chars
just for convenience.
* Files are already serialised as UTF-8 strings for linux/windows binary
compatibility, so this change doesn't break backwards compatibility.
* There was a report of renderdoccmd.exe doing --cap32for64 in an infinite
loop on itself (each process trying to inject the previous). I'm not sure
how this could get started, but assuming this was happening automatically
for 'hook into children', try to break the infinite loop by refusing to
inject into our own exes.
* This is a bit complex. If an application has a global symbol e.g.
GLENABLE glEnable; as their function pointers that they fill out from
glXGetProcAddress, then OUR glEnable global function gets replaced with
that symbol. It's weird. But it means crashes if we try and return the
address of that symbol as a function pointer.
* However it's also possible to get the reverse problem - if an application
has a shared library that has those symbols expecting them to be function
pointers, those symbols will get overridden with our global functions
and it will mean an instant crash when they try to assign to those func
ptrs.
* I'm not sure if there is an ideal fix to this Catch-22, as we also need
to export these bare functions in case someone just plain links against
libGL and expects them to be there, with no GetProcAddress/dlsym funny
business.
* This is the first attempt at backwards logfile compatibility. Since most
captures are fairly ephemeral I don't know to what degree I'll go in
future to support old captures, but since this was a fairly trivial
example (just skip serialising a bit of data if it's an old version
without it), I'll test this out.
* renderdoc/api/replay/ contains all the headers for using the replay and
analysis side of renderdoc (like in a UI or auto-testing tool)
* renderdoc/api/app/ contains the headers if you wanted to write a
renderdoc-aware application.
* This could be improved and moved further down, not all functions would
need a lock (only things modifying shared resources), but it suffices
for now.
* Even if the app only queries some subset of extensions, we may need
more (e.g. need the DSA extensions). GetRealFunctions does a
PopulateHooks which will fill out the extensions that we need.
* Normal selector functions are implemented via these, which requires
EXT_direct_state_access to be available, but this isn't hard to work
around with some wrapper functions should that become necessary.
* Disabling the macro means that the DirectX SDK (June 2010) should be the
only dependency and you can compile as normal, just without d3d11.1
support.
* This won't be massively supported and official releases will not use this
* It might break in future as I won't be testing, it might even be deleted
to tidy up, but until then it might come in handy for some.
baldurk