2013-10-24 00:57:55 -07:00
|
|
|
uniform float4x4 ViewProj;
|
Revamp API and start using doxygen
The API used to be designed in such a way to where it would expect
exports for each individual source/output/encoder/etc. You would export
functions for each and it would automatically load those functions based
on a specific naming scheme from the module.
The idea behind this was that I wanted to limit the usage of structures
in the API so only functions could be used. It was an interesting idea
in theory, but this idea turned out to be flawed in a number of ways:
1.) Requiring exports to create sources/outputs/encoders/etc meant that
you could not create them by any other means, which meant that
things like faruton's .net plugin would become difficult.
2.) Export function declarations could not be checked, therefore if you
created a function with the wrong parameters and parameter types,
the compiler wouldn't know how to check for that.
3.) Required overly complex load functions in libobs just to handle it.
It makes much more sense to just have a load function that you call
manually. Complexity is the bane of all good programs.
4.) It required that you have functions of specific names, which looked
and felt somewhat unsightly.
So, to fix these issues, I replaced it with a more commonly used API
scheme, seen commonly in places like kernels and typical C libraries
with abstraction. You simply create a structure that contains the
callback definitions, and you pass it to a function to register that
definition (such as obs_register_source), which you call in the
obs_module_load of the module.
It will also automatically check the structure size and ensure that it
only loads the required values if the structure happened to add new
values in an API change.
The "main" source file for each module must include obs-module.h, and
must use OBS_DECLARE_MODULE() within that source file.
Also, started writing some doxygen documentation in to the main library
headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
|
|
|
uniform texture2d image;
|
2013-10-24 00:57:55 -07:00
|
|
|
|
|
|
|
sampler_state def_sampler {
|
|
|
|
Filter = Linear;
|
|
|
|
AddressU = Clamp;
|
|
|
|
AddressV = Clamp;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct VertInOut {
|
|
|
|
float4 pos : POSITION;
|
|
|
|
float2 uv : TEXCOORD0;
|
|
|
|
};
|
|
|
|
|
2013-10-25 02:50:08 -07:00
|
|
|
VertInOut VSDefault(VertInOut vert_in)
|
2013-10-24 00:57:55 -07:00
|
|
|
{
|
|
|
|
VertInOut vert_out;
|
2013-12-22 00:30:18 -08:00
|
|
|
vert_out.pos = mul(float4(vert_in.pos.xyz, 1.0), ViewProj);
|
2013-10-24 00:57:55 -07:00
|
|
|
vert_out.uv = vert_in.uv;
|
|
|
|
return vert_out;
|
|
|
|
}
|
|
|
|
|
2014-02-05 19:36:21 -08:00
|
|
|
float4 PSDrawBare(VertInOut vert_in) : TARGET
|
2013-10-25 02:50:08 -07:00
|
|
|
{
|
Revamp API and start using doxygen
The API used to be designed in such a way to where it would expect
exports for each individual source/output/encoder/etc. You would export
functions for each and it would automatically load those functions based
on a specific naming scheme from the module.
The idea behind this was that I wanted to limit the usage of structures
in the API so only functions could be used. It was an interesting idea
in theory, but this idea turned out to be flawed in a number of ways:
1.) Requiring exports to create sources/outputs/encoders/etc meant that
you could not create them by any other means, which meant that
things like faruton's .net plugin would become difficult.
2.) Export function declarations could not be checked, therefore if you
created a function with the wrong parameters and parameter types,
the compiler wouldn't know how to check for that.
3.) Required overly complex load functions in libobs just to handle it.
It makes much more sense to just have a load function that you call
manually. Complexity is the bane of all good programs.
4.) It required that you have functions of specific names, which looked
and felt somewhat unsightly.
So, to fix these issues, I replaced it with a more commonly used API
scheme, seen commonly in places like kernels and typical C libraries
with abstraction. You simply create a structure that contains the
callback definitions, and you pass it to a function to register that
definition (such as obs_register_source), which you call in the
obs_module_load of the module.
It will also automatically check the structure size and ensure that it
only loads the required values if the structure happened to add new
values in an API change.
The "main" source file for each module must include obs-module.h, and
must use OBS_DECLARE_MODULE() within that source file.
Also, started writing some doxygen documentation in to the main library
headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
|
|
|
return image.Sample(def_sampler, vert_in.uv);
|
2013-10-25 02:50:08 -07:00
|
|
|
}
|
|
|
|
|
libobs: Fix various alpha issues
There are cases where alpha is multiplied unnecessarily. This change
attempts to use premultiplied alpha blending for composition.
To keep this change simple, The filter chain will continue to use
straight alpha. Otherwise, every source would need to modified to output
premultiplied, and every filter modified for premultiplied input.
"DrawAlphaDivide" shader techniques have been added to convert from
premultiplied alpha to straight alpha for final output. "DrawMatrix"
techniques ignore alpha, so they do not appear to need changing.
One remaining issue is that scale effects are set up here to use the
same shader logic for both scale filters (straight alpha - incorrectly),
and output composition (premultiplied alpha - correctly). A fix could be
made to add additional shaders for straight alpha, but the "real" fix
may be to eliminate the straight alpha path at some point.
For graphics, SrcBlendAlpha and DestBlendAlpha were both ONE, and could
combine together to form alpha values greater than one. This is not as
noticeable of a problem for UNORM targets because the channels are
clamped, but it will likely become a problem in more situations if FLOAT
targets are used.
This change switches DestBlendAlpha to INVSRCALPHA. The blending
behavior of stacked transparents is preserved without overflowing the
alpha channel.
obs-transitions: Use premultiplied alpha blend, and simplify shaders
because both inputs and outputs use premultiplied alpha now.
Fixes https://obsproject.com/mantis/view.php?id=1108
2019-05-03 03:54:17 -07:00
|
|
|
float4 PSDrawAlphaDivide(VertInOut vert_in) : TARGET
|
|
|
|
{
|
|
|
|
float4 rgba = image.Sample(def_sampler, vert_in.uv);
|
|
|
|
float alpha = rgba.a;
|
|
|
|
float multiplier = (alpha > 0.0) ? (1.0 / alpha) : 0.0;
|
|
|
|
return float4(rgba.rgb * multiplier, alpha);
|
|
|
|
}
|
|
|
|
|
2014-02-05 19:36:21 -08:00
|
|
|
technique Draw
|
2013-10-25 02:50:08 -07:00
|
|
|
{
|
|
|
|
pass
|
|
|
|
{
|
|
|
|
vertex_shader = VSDefault(vert_in);
|
2014-02-05 19:36:21 -08:00
|
|
|
pixel_shader = PSDrawBare(vert_in);
|
2013-10-25 02:50:08 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
libobs: Fix various alpha issues
There are cases where alpha is multiplied unnecessarily. This change
attempts to use premultiplied alpha blending for composition.
To keep this change simple, The filter chain will continue to use
straight alpha. Otherwise, every source would need to modified to output
premultiplied, and every filter modified for premultiplied input.
"DrawAlphaDivide" shader techniques have been added to convert from
premultiplied alpha to straight alpha for final output. "DrawMatrix"
techniques ignore alpha, so they do not appear to need changing.
One remaining issue is that scale effects are set up here to use the
same shader logic for both scale filters (straight alpha - incorrectly),
and output composition (premultiplied alpha - correctly). A fix could be
made to add additional shaders for straight alpha, but the "real" fix
may be to eliminate the straight alpha path at some point.
For graphics, SrcBlendAlpha and DestBlendAlpha were both ONE, and could
combine together to form alpha values greater than one. This is not as
noticeable of a problem for UNORM targets because the channels are
clamped, but it will likely become a problem in more situations if FLOAT
targets are used.
This change switches DestBlendAlpha to INVSRCALPHA. The blending
behavior of stacked transparents is preserved without overflowing the
alpha channel.
obs-transitions: Use premultiplied alpha blend, and simplify shaders
because both inputs and outputs use premultiplied alpha now.
Fixes https://obsproject.com/mantis/view.php?id=1108
2019-05-03 03:54:17 -07:00
|
|
|
technique DrawAlphaDivide
|
|
|
|
{
|
|
|
|
pass
|
|
|
|
{
|
|
|
|
vertex_shader = VSDefault(vert_in);
|
|
|
|
pixel_shader = PSDrawAlphaDivide(vert_in);
|
|
|
|
}
|
|
|
|
}
|