Removes prior attempt to expose libcaption headers which really shouldnt
have public. This instead moves the obs-internal include out of the
public obs-scene.h and into it's implementation.
Code submissions have continually suffered from formatting
inconsistencies that constantly have to be addressed. Using
clang-format simplifies this by making code formatting more consistent,
and allows automation of the code formatting so that maintainers can
focus more on the code itself instead of code formatting.
The line drawing functions previously assumed the upper-left 3x3 for
box_transform only held scale. The matrix can also hold rotation, so
pass in scale separately.
Fixes https://obsproject.com/mantis/view.php?id=1442
(This commit also modifies UI)
Removes obs_scene::group_sceneitem and replaces it with
obs_scene::is_group. Changes a number of other functions related to
groups so that a group is not inherently tied to a specific scene, and
helps allow a single group to be referenced in multiple scenes if
desired.
Allows the ability to group scene items. Groups internally are
sub-scenes, which allows the ability to add unique filters and
transforms to each group.
Allows the ability to use scale filters such as point, bicubic, lanczos
on specific scene items, disabled by default. When using one of the
latter two options, if the item's scale is under half of the source's
original size, it uses the bilinear low resolution downscale shader
instead.
This buffers scene item visibility actions so that if
obs_sceneitem_set_visible to true or false, that it will ensure that the
action is mapped to the exact sample point time in which
obs_sceneitem_set_visible is called. Mapping to the exact sample point
isn't necessary, but it's a nice thing to have.
There are a ridiculous number of features related to scaling and
positioning due to requests by a number of people who complained that
they hated the way that OBS1 would always resize their sources when the
source's base size changed. There were also people who wanted more
control for how the resizing was handled, or the ability to completely
prevent resizing entirely if desired. So I made it so that you can
optionally use a 'bounds' system, which allows you to specify different
styles of controlling resizing.
If disabled, the source will always automatically resize and only the
base scale is applied. If enabled, you have a variety of different ways
to limit/control how it can resize within the bounds, or make it so it
can't resize at all. You can also control alignment within that
bounding box, so you can make it so that a source always aligns to a
side or corner of the box.
I also added an alignment value which changes how the source is oriented
relative to the position of the scene item. For example, setting
bottom-right alignment will make it so that the position of the item is
the bottom right corner of the source. When the source resizies, it
will resize leftward and upward in that case, which solves the problem
of how a source resizes relative to a desired position.
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
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.
Scene items previously were removed by calling obs_sceneitem_destroy,
but this proved to be a potential race condition where two different
threads could try to destroy the same scene item at the same time.
Instead of doing that, reference counting is now used on scene items,
and an explicit obs_sceneitem_remove function is used instead for item
removal, which sets a 'removed' variable to ensure it can only be called
exactly one time.
jpark37
jw0z96
Exeldro
Kurt Kartaltepe
jp9000
James Park
cg2121
Ryan Foster
Palana
Peter SZTANOJEV