obs-studio/libobs/data/default.effect

53 lines
958 B
Plaintext
Raw Normal View History

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;
sampler_state def_sampler {
Filter = Linear;
AddressU = Clamp;
AddressV = Clamp;
};
struct VertInOut {
float4 pos : POSITION;
float2 uv : TEXCOORD0;
};
VertInOut VSDefault(VertInOut vert_in)
{
VertInOut vert_out;
vert_out.pos = mul(float4(vert_in.pos.xyz, 1.0), ViewProj);
vert_out.uv = vert_in.uv;
return vert_out;
}
float4 PSDrawBare(VertInOut vert_in) : TARGET
{
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);
}
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);
}
technique Draw
{
pass
{
vertex_shader = VSDefault(vert_in);
pixel_shader = PSDrawBare(vert_in);
}
}
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);
}
}