This allows the ability to separate the blend states of color and alpha.
The default blend state has also changed so that alpha is always added
together to ensure that the destination image always gets an alpha value
that is actually usable after the operation (for render targets).
Old default state:
color source: GS_BLEND_SRCALPHA, color dest: GS_BLEND_INVSRCALPHA
alpha source: GS_BLEND_SRCALPHA, alpha dest: GS_BLEND_INVSRCALPHA
New default state:
color source: GS_BLEND_SRCALPHA, color dest: GS_BLEND_INVSRCALPHA
alpha source: GS_BLEND_ONE, alpha dest: GS_BLEND_ONE
Someone's going to yell at me about this, but fix vertical alignment for
certain member variables in the main header.
For future reference, if you must use vertical alignment, always give it
plenty of space for the type names to grow in case you need to
add/change variables in the future; don't just align to the 'longest'
value, give it an extra 8-16 spaces for potential future variables.
This is done to prevent having to make commits like this in the future
that sort of pollute the history.
When using an enumeration value with a switch, it needs to be filled out
with all possible values to prevent compiler warnings. This warning is
used to prevent the developer from unintentionally forgetting to add new
enum values to any switches the enum is used on later on. Sadly, only
good compilers actually have this warning (mingw).
Microsoft's compiler doesn't seem to care about warning about things
like initializer list ordering. Mingw actually reports on this to
prevent potential confusion about ordering.
We have a sprintf_s function in mingw-w64, but it's the it won't compile
with visual studio because it's the C11 specification (aka the correct
specification that's not made by morons). Microsoft's version differs
to the specification (and is made by morons), so fall back to sprintf
(note if you can't tell, this commit message was edited by Jim)
The gs_enum_adapters function is an optional implementation to allow
enumeration of available graphics adapters that can be used with the
program. The ID associated with the adapter can be an index or a hash
depending on the implementation.
This adds support for the windows 8+ output duplicator feature which
allows the efficient capturing of a specific monitor connected to the
currently used device.
I do not want the D3D11 library to depend on a specific compiler
version. This way, I do not have to distribute D3D Compiler libraries
with the program (proprietary binary blobs). Any particular version
works because the API for the D3DCompiler function appears to be the
same; the only things that change are other features and additions
mostly (at least as far as I can tell). Using any version available on
the system should be more than sufficient rather than depending on some
specific D3D compiler version.
If the user doesn't have it, a download of the latest D3D distributables
should be fine, though it should work with the ones that come with
windows 7+ as well.
This Fixes a minor flaw with the API where data had to always be mutable
to be usable by the API.
Functions that do not modify the fundamental underlying data of a
structure should be marked as constant, both for safety and to signify
that the parameter is input only and will not be modified by the
function using it.
Typedef pointers are unsafe. If you do:
typedef struct bla *bla_t;
then you cannot use it as a constant, such as: const bla_t, because
that constant will be to the pointer itself rather than to the
underlying data. I admit this was a fundamental mistake that must
be corrected.
All typedefs that were pointer types will now have their pointers
removed from the type itself, and the pointers will be used when they
are actually used as variables/parameters/returns instead.
This does not break ABI though, which is pretty nice.
The alpha source and destination blend values were always being set to
one and zero, when they should have been set to the same as the color
values. This caused the alpha of the source texture to always overwrite
the alpha of the destination texture, rather than apply the blend
function upon it. Needless to say that it seriously screwed up the
render target if you rendered something with alpha on it.
Thanks to paibox for pointing this issue out and yelling at me to fix
it. I apologize for not getting to this sooner.
Changed API functions:
libobs: obs_reset_video
Before, video initialization returned a boolean, but "failed" is too
little information, if it fails due to lack of device capabilities or
bad video device parameters, the front-end needs to know that.
The OBS Basic UI has also been updated to reflect this API change.
There's no need to find DirectX because with VS2013 and mingw it's
already available by default. Older visual studio versions that didn't
come with DirectX by default are no longer supported anyway.
(Also mingw doesn't currently work at all due to lack of proper headers,
but once they do it'll be available in the same way. I think.)
NOTE: In texture_setimage, I had to move variables to the top of the
scope because microsoft's C compiler will give the legacy C90 error of:
'illegal use of this type as an expression'.
To sum it up, microsoft's C compiler is still utter garbage.
...I'm actually concerned that I went a bit overkill trying to prevent
backwards compatibility issues with this abstraction design, because
this is a large number of files that have to be modified just to add a
single graphics subsystem export. Someone's going to strangle me, and
when you know that someone might strangle you, that means that you did
something wrong. We'll have to look in to simplifying this in the
future without killing backward compatibility safety.
These functions were mostly related to being able to set true fullscreen
mode -- however, this has no place for our purposes, and these functions
were just sitting empty and unused, so they should be removed.
Besides, fullscreen mode only applies to the windows operating system.
This variable is currently somewhat pointless, I was originally going to
use it to tell the graphics subsystem to completely rebuild the internal
vertex buffers, but it would be bad/inefficient to allow that
functionality.
I had forgotten how constants worked when compiled; constants are
uploaded as constant registers. When constants are used with shaders,
multiple constants are often packed in to a single register when
possible to reduce constant register count.
For example, one 'float' constant and one 'float3' constant will be
packed in to a single register (c0.x for constant 1, c0.yzw for constant
2), but two 'float' constants and one 'float3' constant must inhabit two
registers (c0.xy for constant 1, c1.xyz for constant 2), so it must
start on a new register boundry (every 16 bytes).
I had first instinctively thought it was just a simple case of
alignment like it is on the CPU, but then I realized that it didn't
sound right, so I went back and did some more tests and then ultimately
remembered how constants actually are uploaded.
jp9000
martell
paibox