glFlush is somewhat implementation-specific; on OSX for example, it is
additionally used to draw to a view. However, we're already using the
Objective-C function flushBuffer, which apparently calls glFlush
internally anyway to draw to views. That means that we're superfluously
calling glFlush most of the time if there's an active swap chain. So
instead, only call glFlush when there are no active swap chains on OSX.
This is my fault; I made an idiotic assumption about the data and it
ended up causing the plugin to crash. This is definitely one of my more
embarrassing moments.
A minor optimization: in copy_rgbx_frame (used when libobs is set to
output RGBA frames instead of YUV frames), if the line sizes for the
source and destination match, just use a single memcpy call for all of
the data instead of multiple memcpy calls.
Found via clang-3.6, actual warning:
window-basic-main.hpp:406:14: warning: 'GetProfilePath' overrides
a member function but is not marked 'override'
[-Winconsistent-missing-override]
Added cast to unsigned and the assert because microsoft's compiler
doesn't support "%zu"
Actual warning:
libobs/graphics/effect-parser.c:1387:4: warning: format specifies type
'unsigned int' but the argument has type 'size_t' (aka 'unsigned long')
[-Wformat]
This addition allows external cmake modules to include the same modules
that are commonly distributed with the main obs-studio repo: things like
FFmpeg, curl, etc.
This cmake module adds various cmake functions used for generating obs
plugins. This currently may not fully support linux; this may require
more changes on linux due to the nature of the file structure linux
uses.
This just changes the x264 encoder settings; it doesn't actually change
the framerate of OBS. OBS will always output at a constant framerate
regardless of whether this option is on or off; this just changes how
the encoder encodes the data.
Certain plugins/modules that are loaded on windows may be dependent on
libraries that are located in the same directory as the module in
question. This makes is so that LoadLibrary will also search for
dependent libraries for that module in the module's directory.
When globbing for modules, the intent was to ignore the . and ..
directories that might also be included in the glob search. It was
mistakenly doing a string compare on the 'path' variable which contains
the full path, rather than the 'file' variable which just contains the
found file itself, so the string compare always failed.
Fixes issues using DepsPath(32|64), was using ${lib_suffix} instead of
${_lib_suffix} so 32/64-sepcific directories wouldn't work properly.
Also the DepsPath environment/cmake variable wasn't specified for the
library search.
Also added the same dependency search paths for libfdk (if someone wants
to use it on windows for whatever reason)
Palana
jp9000
Anthony Catel
Radzaquiel
Gol-D-Ace
Jess Mayo