BGRX was being treated as "BGR input" with "RGBA storage", where it
should have been "BGRA input" with "RGB storage". So the input for the
texture was expecting 24 bits of packed BGR rather than 32bit BGRX
pixels, and was internally storing it with alpha available.
On some operating systems, with specific drivers it seems that BGR/BGRA
isn't properly treated as such in certain cases. This fix will
hopefully force the formats to be treated as BGR/BGRA when actually
rendering, which should get around the implementation-specific issue.
- Add dummy GL texture support to allow libobs texture references to be
created for GL without
- Add a texture_getobj function to allow the retrieval of the
context-specific object, such as the D3D texture pointer, or the
OpenGL texture object handle.
- Also cleaned up the export stuff. I realized it was all totally
superfluous. Kind of a dumb moment, but nice to clean it up
regardless.
Also, rename atomic functions to be consistent with the rest of the
platform/threading functions, and move atomic functions to threading*
files rather than platform* files
Staging surfaces with GL originally copied to a texture and then
downloaded that copied texture, but I realized that there was really no
real need to do that. Now instead they'll copy directly from the
texture that's given to them rather than copying to a buffer first.
Secondly, hopefully fix the mac issue where the only way to perform an
asynchronous texture download is via FBOs and glReadPixels. It's a
really dumb issue with macs and the amount of "gotchas" and non-standard
internal GL functionaly on mac is really annoying.
There were a *lot* of warnings, managed to remove most of them.
Also, put warning flags before C_FLAGS and CXX_FLAGS, rather than after,
as -Wall -Wextra was overwriting flags that came before it.
- Removed the dependency on windows.h for windows. I feel it's an
unnecessarily large dependency to have to add to all source files
when the only thing that's needed to make the windows version compile
the debug functions is just the __stdcall call convention keyword.
On top of increasing compile time due to the large number of headers
it includes from all the windows API headers, it also adds a lot of
potential name conflicts, as I was getting a number of name conflicts
for lots of names like near/far, which were used in old legacy 16bit
windows code.
jp9000
BtbN
Zachary Lund
Palana
Peter SZTANOJEV