obs-studio/test/test-input/test-filter.c

73 lines
1.4 KiB
C
Raw Normal View History

(API Change) Refactor module handling Changed API: - char *obs_find_plugin_file(const char *sub_path); Changed to: char *obs_module_file(const char *file); Cahnge it so you no longer need to specify a sub-path such as: obs_find_plugin_file("module_name/file.ext") Instead, now automatically handle the module data path so all you need to do is: obs_module_file("file.ext") - int obs_load_module(const char *name); Changed to: int obs_open_module(obs_module_t *module, const char *path, const char *data_path); bool obs_init_module(obs_module_t module); Change the module loading API so that if the front-end chooses, it can load modules directly from a specified path, and associate a data directory with it on the spot. The module will not be initialized immediately; obs_init_module must be called on the module pointer in order to fully initialize the module. This is done so a module can be disabled by the front-end if the it so chooses. New API: - void obs_add_module_path(const char *bin, const char *data); These functions allow you to specify new module search paths to add, and allow you to search through them, or optionally just load all modules from them. If the string %module% is included, it will replace it with the module's name when that string is used as a lookup. Data paths are now directly added to the module's internal storage structure, and when obs_find_module_file is used, it will look up the pointer to the obs_module structure and get its data directory that way. Example: obs_add_module_path("/opt/obs/my-modules/%module%/bin", "/opt/obs/my-modules/%module%/data"); This would cause it to additionally look for the binary of a hypthetical module named "foo" at /opt/obs/my-modules/foo/bin/foo.so (or libfoo.so), and then look for the data in /opt/obs/my-modules/foo/data. This gives the front-end more flexibility for handling third-party plugin modules, or handling all plugin modules in a custom way. - void obs_find_modules(obs_find_module_callback_t callback, void *param); This searches the existing paths for modules and calls the callback function when any are found. Useful for plugin management and custom handling of the paths by the front-end if desired. - void obs_load_all_modules(void); Search through the paths and both loads and initializes all modules automatically without custom handling. - void obs_enum_modules(obs_enum_module_callback_t callback, void *param); Enumerates currently opened modules.
2014-07-27 12:00:11 -07:00
#include <obs-module.h>
2013-09-30 19:37:13 -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
struct test_filter {
obs_source_t *source;
gs_effect_t *whatever;
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
};
static const char *filter_getname(void *unused)
{
UNUSED_PARAMETER(unused);
return "Test";
}
static void filter_destroy(void *data)
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
{
struct test_filter *tf = data;
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
if (tf) {
obs_enter_graphics();
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
(API Change) Improve graphics API consistency Summary: - Prefix all graphics subsystem names with gs_ or GS_ - Unsquish funciton names (for example _setfloat to _set_float) - Changed create functions to be more consistent with the rest of the API elsewhere. For exmaple, instead of gs_create_texture/gs_texture_destroy, it's now gs_texture_create/gs_texture_destroy - Renamed gs_stencil_op enum to gs_stencil_op_type From: To: ----------------------------------------------------------- tvertarray gs_tvertarray vb_data gs_vb_data vbdata_create gs_vbdata_create vbdata_destroy gs_vbdata_destroy shader_param gs_shader_param gs_effect gs_effect effect_technique gs_effect_technique effect_pass gs_effect_pass effect_param gs_effect_param texture_t gs_texture_t stagesurf_t gs_stagesurf_t zstencil_t gs_zstencil_t vertbuffer_t gs_vertbuffer_t indexbuffer_t gs_indexbuffer_t samplerstate_t gs_samplerstate_t swapchain_t gs_swapchain_t texrender_t gs_texrender_t shader_t gs_shader_t sparam_t gs_sparam_t effect_t gs_effect_t technique_t gs_technique_t eparam_t gs_eparam_t device_t gs_device_t graphics_t graphics_t shader_param_type gs_shader_param_type SHADER_PARAM_UNKNOWN GS_SHADER_PARAM_UNKNOWN SHADER_PARAM_BOOL GS_SHADER_PARAM_BOOL SHADER_PARAM_FLOAT GS_SHADER_PARAM_FLOAT SHADER_PARAM_INT GS_SHADER_PARAM_INT SHADER_PARAM_STRING GS_SHADER_PARAM_STRING SHADER_PARAM_VEC2 GS_SHADER_PARAM_VEC2 SHADER_PARAM_VEC3 GS_SHADER_PARAM_VEC3 SHADER_PARAM_VEC4 GS_SHADER_PARAM_VEC4 SHADER_PARAM_MATRIX4X4 GS_SHADER_PARAM_MATRIX4X4 SHADER_PARAM_TEXTURE GS_SHADER_PARAM_TEXTURE shader_param_info gs_shader_param_info shader_type gs_shader_type SHADER_VERTEX GS_SHADER_VERTEX SHADER_PIXEL GS_SHADER_PIXEL shader_destroy gs_shader_destroy shader_numparams gs_shader_get_num_params shader_getparambyidx gs_shader_get_param_by_idx shader_getparambyname gs_shader_get_param_by_name shader_getviewprojmatrix gs_shader_get_viewproj_matrix shader_getworldmatrix gs_shader_get_world_matrix shader_getparaminfo gs_shader_get_param_info shader_setbool gs_shader_set_bool shader_setfloat gs_shader_set_float shader_setint gs_shader_set_int shader_setmatrix3 gs_shader_setmatrix3 shader_setmatrix4 gs_shader_set_matrix4 shader_setvec2 gs_shader_set_vec2 shader_setvec3 gs_shader_set_vec3 shader_setvec4 gs_shader_set_vec4 shader_settexture gs_shader_set_texture shader_setval gs_shader_set_val shader_setdefault gs_shader_set_default effect_property_type gs_effect_property_type EFFECT_NONE GS_EFFECT_NONE EFFECT_BOOL GS_EFFECT_BOOL EFFECT_FLOAT GS_EFFECT_FLOAT EFFECT_COLOR GS_EFFECT_COLOR EFFECT_TEXTURE GS_EFFECT_TEXTURE effect_param_info gs_effect_param_info effect_destroy gs_effect_destroy effect_gettechnique gs_effect_get_technique technique_begin gs_technique_begin technique_end gs_technique_end technique_beginpass gs_technique_begin_pass technique_beginpassbyname gs_technique_begin_pass_by_name technique_endpass gs_technique_end_pass effect_numparams gs_effect_get_num_params effect_getparambyidx gs_effect_get_param_by_idx effect_getparambyname gs_effect_get_param_by_name effect_updateparams gs_effect_update_params effect_getviewprojmatrix gs_effect_get_viewproj_matrix effect_getworldmatrix gs_effect_get_world_matrix effect_getparaminfo gs_effect_get_param_info effect_setbool gs_effect_set_bool effect_setfloat gs_effect_set_float effect_setint gs_effect_set_int effect_setmatrix4 gs_effect_set_matrix4 effect_setvec2 gs_effect_set_vec2 effect_setvec3 gs_effect_set_vec3 effect_setvec4 gs_effect_set_vec4 effect_settexture gs_effect_set_texture effect_setval gs_effect_set_val effect_setdefault gs_effect_set_default texrender_create gs_texrender_create texrender_destroy gs_texrender_destroy texrender_begin gs_texrender_begin texrender_end gs_texrender_end texrender_reset gs_texrender_reset texrender_gettexture gs_texrender_get_texture GS_BUILDMIPMAPS GS_BUILD_MIPMAPS GS_RENDERTARGET GS_RENDER_TARGET gs_device_name gs_get_device_name gs_device_type gs_get_device_type gs_entercontext gs_enter_context gs_leavecontext gs_leave_context gs_getcontext gs_get_context gs_renderstart gs_render_start gs_renderstop gs_render_stop gs_rendersave gs_render_save gs_getinput gs_get_input gs_geteffect gs_get_effect gs_create_effect_from_file gs_effect_create_from_file gs_create_effect gs_effect_create gs_create_vertexshader_from_file gs_vertexshader_create_from_file gs_create_pixelshader_from_file gs_pixelshader_create_from_file gs_create_texture_from_file gs_texture_create_from_file gs_resetviewport gs_reset_viewport gs_set2dmode gs_set_2d_mode gs_set3dmode gs_set_3d_mode gs_create_swapchain gs_swapchain_create gs_getsize gs_get_size gs_getwidth gs_get_width gs_getheight gs_get_height gs_create_texture gs_texture_create gs_create_cubetexture gs_cubetexture_create gs_create_volumetexture gs_voltexture_create gs_create_zstencil gs_zstencil_create gs_create_stagesurface gs_stagesurface_create gs_create_samplerstate gs_samplerstate_create gs_create_vertexshader gs_vertexshader_create gs_create_pixelshader gs_pixelshader_create gs_create_vertexbuffer gs_vertexbuffer_create gs_create_indexbuffer gs_indexbuffer_create gs_gettexturetype gs_get_texture_type gs_load_defaultsamplerstate gs_load_default_samplerstate gs_getvertexshader gs_get_vertex_shader gs_getpixelshader gs_get_pixel_shader gs_getrendertarget gs_get_render_target gs_getzstenciltarget gs_get_zstencil_target gs_setrendertarget gs_set_render_target gs_setcuberendertarget gs_set_cube_render_target gs_beginscene gs_begin_scene gs_draw gs_draw gs_endscene gs_end_scene gs_setcullmode gs_set_cull_mode gs_getcullmode gs_get_cull_mode gs_enable_depthtest gs_enable_depth_test gs_enable_stenciltest gs_enable_stencil_test gs_enable_stencilwrite gs_enable_stencil_write gs_blendfunction gs_blend_function gs_depthfunction gs_depth_function gs_stencilfunction gs_stencil_function gs_stencilop gs_stencil_op gs_setviewport gs_set_viewport gs_getviewport gs_get_viewport gs_setscissorrect gs_set_scissor_rect gs_create_texture_from_iosurface gs_texture_create_from_iosurface gs_create_gdi_texture gs_texture_create_gdi gs_is_compressed_format gs_is_compressed_format gs_num_total_levels gs_get_total_levels texture_setimage gs_texture_set_image cubetexture_setimage gs_cubetexture_set_image swapchain_destroy gs_swapchain_destroy texture_destroy gs_texture_destroy texture_getwidth gs_texture_get_width texture_getheight gs_texture_get_height texture_getcolorformat gs_texture_get_color_format texture_map gs_texture_map texture_unmap gs_texture_unmap texture_isrect gs_texture_is_rect texture_getobj gs_texture_get_obj cubetexture_destroy gs_cubetexture_destroy cubetexture_getsize gs_cubetexture_get_size cubetexture_getcolorformat gs_cubetexture_get_color_format volumetexture_destroy gs_voltexture_destroy volumetexture_getwidth gs_voltexture_get_width volumetexture_getheight gs_voltexture_get_height volumetexture_getdepth gs_voltexture_getdepth volumetexture_getcolorformat gs_voltexture_get_color_format stagesurface_destroy gs_stagesurface_destroy stagesurface_getwidth gs_stagesurface_get_width stagesurface_getheight gs_stagesurface_get_height stagesurface_getcolorformat gs_stagesurface_get_color_format stagesurface_map gs_stagesurface_map stagesurface_unmap gs_stagesurface_unmap zstencil_destroy gs_zstencil_destroy samplerstate_destroy gs_samplerstate_destroy vertexbuffer_destroy gs_vertexbuffer_destroy vertexbuffer_flush gs_vertexbuffer_flush vertexbuffer_getdata gs_vertexbuffer_get_data indexbuffer_destroy gs_indexbuffer_destroy indexbuffer_flush gs_indexbuffer_flush indexbuffer_getdata gs_indexbuffer_get_data indexbuffer_numindices gs_indexbuffer_get_num_indices indexbuffer_gettype gs_indexbuffer_get_type texture_rebind_iosurface gs_texture_rebind_iosurface texture_get_dc gs_texture_get_dc texture_release_dc gs_texture_release_dc
2014-08-07 23:42:07 -07:00
gs_effect_destroy(tf->whatever);
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
bfree(tf);
obs_leave_graphics();
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
}
}
static void *filter_create(obs_data_t *settings, obs_source_t *source)
2013-09-30 19:37:13 -07:00
{
struct test_filter *tf = bzalloc(sizeof(struct test_filter));
char *effect_file;
2013-09-30 19:37:13 -07:00
obs_enter_graphics();
(API Change) Refactor module handling Changed API: - char *obs_find_plugin_file(const char *sub_path); Changed to: char *obs_module_file(const char *file); Cahnge it so you no longer need to specify a sub-path such as: obs_find_plugin_file("module_name/file.ext") Instead, now automatically handle the module data path so all you need to do is: obs_module_file("file.ext") - int obs_load_module(const char *name); Changed to: int obs_open_module(obs_module_t *module, const char *path, const char *data_path); bool obs_init_module(obs_module_t module); Change the module loading API so that if the front-end chooses, it can load modules directly from a specified path, and associate a data directory with it on the spot. The module will not be initialized immediately; obs_init_module must be called on the module pointer in order to fully initialize the module. This is done so a module can be disabled by the front-end if the it so chooses. New API: - void obs_add_module_path(const char *bin, const char *data); These functions allow you to specify new module search paths to add, and allow you to search through them, or optionally just load all modules from them. If the string %module% is included, it will replace it with the module's name when that string is used as a lookup. Data paths are now directly added to the module's internal storage structure, and when obs_find_module_file is used, it will look up the pointer to the obs_module structure and get its data directory that way. Example: obs_add_module_path("/opt/obs/my-modules/%module%/bin", "/opt/obs/my-modules/%module%/data"); This would cause it to additionally look for the binary of a hypthetical module named "foo" at /opt/obs/my-modules/foo/bin/foo.so (or libfoo.so), and then look for the data in /opt/obs/my-modules/foo/data. This gives the front-end more flexibility for handling third-party plugin modules, or handling all plugin modules in a custom way. - void obs_find_modules(obs_find_module_callback_t callback, void *param); This searches the existing paths for modules and calls the callback function when any are found. Useful for plugin management and custom handling of the paths by the front-end if desired. - void obs_load_all_modules(void); Search through the paths and both loads and initializes all modules automatically without custom handling. - void obs_enum_modules(obs_enum_module_callback_t callback, void *param); Enumerates currently opened modules.
2014-07-27 12:00:11 -07:00
effect_file = obs_module_file("test.effect");
2013-09-30 19:37:13 -07:00
tf->source = source;
(API Change) Improve graphics API consistency Summary: - Prefix all graphics subsystem names with gs_ or GS_ - Unsquish funciton names (for example _setfloat to _set_float) - Changed create functions to be more consistent with the rest of the API elsewhere. For exmaple, instead of gs_create_texture/gs_texture_destroy, it's now gs_texture_create/gs_texture_destroy - Renamed gs_stencil_op enum to gs_stencil_op_type From: To: ----------------------------------------------------------- tvertarray gs_tvertarray vb_data gs_vb_data vbdata_create gs_vbdata_create vbdata_destroy gs_vbdata_destroy shader_param gs_shader_param gs_effect gs_effect effect_technique gs_effect_technique effect_pass gs_effect_pass effect_param gs_effect_param texture_t gs_texture_t stagesurf_t gs_stagesurf_t zstencil_t gs_zstencil_t vertbuffer_t gs_vertbuffer_t indexbuffer_t gs_indexbuffer_t samplerstate_t gs_samplerstate_t swapchain_t gs_swapchain_t texrender_t gs_texrender_t shader_t gs_shader_t sparam_t gs_sparam_t effect_t gs_effect_t technique_t gs_technique_t eparam_t gs_eparam_t device_t gs_device_t graphics_t graphics_t shader_param_type gs_shader_param_type SHADER_PARAM_UNKNOWN GS_SHADER_PARAM_UNKNOWN SHADER_PARAM_BOOL GS_SHADER_PARAM_BOOL SHADER_PARAM_FLOAT GS_SHADER_PARAM_FLOAT SHADER_PARAM_INT GS_SHADER_PARAM_INT SHADER_PARAM_STRING GS_SHADER_PARAM_STRING SHADER_PARAM_VEC2 GS_SHADER_PARAM_VEC2 SHADER_PARAM_VEC3 GS_SHADER_PARAM_VEC3 SHADER_PARAM_VEC4 GS_SHADER_PARAM_VEC4 SHADER_PARAM_MATRIX4X4 GS_SHADER_PARAM_MATRIX4X4 SHADER_PARAM_TEXTURE GS_SHADER_PARAM_TEXTURE shader_param_info gs_shader_param_info shader_type gs_shader_type SHADER_VERTEX GS_SHADER_VERTEX SHADER_PIXEL GS_SHADER_PIXEL shader_destroy gs_shader_destroy shader_numparams gs_shader_get_num_params shader_getparambyidx gs_shader_get_param_by_idx shader_getparambyname gs_shader_get_param_by_name shader_getviewprojmatrix gs_shader_get_viewproj_matrix shader_getworldmatrix gs_shader_get_world_matrix shader_getparaminfo gs_shader_get_param_info shader_setbool gs_shader_set_bool shader_setfloat gs_shader_set_float shader_setint gs_shader_set_int shader_setmatrix3 gs_shader_setmatrix3 shader_setmatrix4 gs_shader_set_matrix4 shader_setvec2 gs_shader_set_vec2 shader_setvec3 gs_shader_set_vec3 shader_setvec4 gs_shader_set_vec4 shader_settexture gs_shader_set_texture shader_setval gs_shader_set_val shader_setdefault gs_shader_set_default effect_property_type gs_effect_property_type EFFECT_NONE GS_EFFECT_NONE EFFECT_BOOL GS_EFFECT_BOOL EFFECT_FLOAT GS_EFFECT_FLOAT EFFECT_COLOR GS_EFFECT_COLOR EFFECT_TEXTURE GS_EFFECT_TEXTURE effect_param_info gs_effect_param_info effect_destroy gs_effect_destroy effect_gettechnique gs_effect_get_technique technique_begin gs_technique_begin technique_end gs_technique_end technique_beginpass gs_technique_begin_pass technique_beginpassbyname gs_technique_begin_pass_by_name technique_endpass gs_technique_end_pass effect_numparams gs_effect_get_num_params effect_getparambyidx gs_effect_get_param_by_idx effect_getparambyname gs_effect_get_param_by_name effect_updateparams gs_effect_update_params effect_getviewprojmatrix gs_effect_get_viewproj_matrix effect_getworldmatrix gs_effect_get_world_matrix effect_getparaminfo gs_effect_get_param_info effect_setbool gs_effect_set_bool effect_setfloat gs_effect_set_float effect_setint gs_effect_set_int effect_setmatrix4 gs_effect_set_matrix4 effect_setvec2 gs_effect_set_vec2 effect_setvec3 gs_effect_set_vec3 effect_setvec4 gs_effect_set_vec4 effect_settexture gs_effect_set_texture effect_setval gs_effect_set_val effect_setdefault gs_effect_set_default texrender_create gs_texrender_create texrender_destroy gs_texrender_destroy texrender_begin gs_texrender_begin texrender_end gs_texrender_end texrender_reset gs_texrender_reset texrender_gettexture gs_texrender_get_texture GS_BUILDMIPMAPS GS_BUILD_MIPMAPS GS_RENDERTARGET GS_RENDER_TARGET gs_device_name gs_get_device_name gs_device_type gs_get_device_type gs_entercontext gs_enter_context gs_leavecontext gs_leave_context gs_getcontext gs_get_context gs_renderstart gs_render_start gs_renderstop gs_render_stop gs_rendersave gs_render_save gs_getinput gs_get_input gs_geteffect gs_get_effect gs_create_effect_from_file gs_effect_create_from_file gs_create_effect gs_effect_create gs_create_vertexshader_from_file gs_vertexshader_create_from_file gs_create_pixelshader_from_file gs_pixelshader_create_from_file gs_create_texture_from_file gs_texture_create_from_file gs_resetviewport gs_reset_viewport gs_set2dmode gs_set_2d_mode gs_set3dmode gs_set_3d_mode gs_create_swapchain gs_swapchain_create gs_getsize gs_get_size gs_getwidth gs_get_width gs_getheight gs_get_height gs_create_texture gs_texture_create gs_create_cubetexture gs_cubetexture_create gs_create_volumetexture gs_voltexture_create gs_create_zstencil gs_zstencil_create gs_create_stagesurface gs_stagesurface_create gs_create_samplerstate gs_samplerstate_create gs_create_vertexshader gs_vertexshader_create gs_create_pixelshader gs_pixelshader_create gs_create_vertexbuffer gs_vertexbuffer_create gs_create_indexbuffer gs_indexbuffer_create gs_gettexturetype gs_get_texture_type gs_load_defaultsamplerstate gs_load_default_samplerstate gs_getvertexshader gs_get_vertex_shader gs_getpixelshader gs_get_pixel_shader gs_getrendertarget gs_get_render_target gs_getzstenciltarget gs_get_zstencil_target gs_setrendertarget gs_set_render_target gs_setcuberendertarget gs_set_cube_render_target gs_beginscene gs_begin_scene gs_draw gs_draw gs_endscene gs_end_scene gs_setcullmode gs_set_cull_mode gs_getcullmode gs_get_cull_mode gs_enable_depthtest gs_enable_depth_test gs_enable_stenciltest gs_enable_stencil_test gs_enable_stencilwrite gs_enable_stencil_write gs_blendfunction gs_blend_function gs_depthfunction gs_depth_function gs_stencilfunction gs_stencil_function gs_stencilop gs_stencil_op gs_setviewport gs_set_viewport gs_getviewport gs_get_viewport gs_setscissorrect gs_set_scissor_rect gs_create_texture_from_iosurface gs_texture_create_from_iosurface gs_create_gdi_texture gs_texture_create_gdi gs_is_compressed_format gs_is_compressed_format gs_num_total_levels gs_get_total_levels texture_setimage gs_texture_set_image cubetexture_setimage gs_cubetexture_set_image swapchain_destroy gs_swapchain_destroy texture_destroy gs_texture_destroy texture_getwidth gs_texture_get_width texture_getheight gs_texture_get_height texture_getcolorformat gs_texture_get_color_format texture_map gs_texture_map texture_unmap gs_texture_unmap texture_isrect gs_texture_is_rect texture_getobj gs_texture_get_obj cubetexture_destroy gs_cubetexture_destroy cubetexture_getsize gs_cubetexture_get_size cubetexture_getcolorformat gs_cubetexture_get_color_format volumetexture_destroy gs_voltexture_destroy volumetexture_getwidth gs_voltexture_get_width volumetexture_getheight gs_voltexture_get_height volumetexture_getdepth gs_voltexture_getdepth volumetexture_getcolorformat gs_voltexture_get_color_format stagesurface_destroy gs_stagesurface_destroy stagesurface_getwidth gs_stagesurface_get_width stagesurface_getheight gs_stagesurface_get_height stagesurface_getcolorformat gs_stagesurface_get_color_format stagesurface_map gs_stagesurface_map stagesurface_unmap gs_stagesurface_unmap zstencil_destroy gs_zstencil_destroy samplerstate_destroy gs_samplerstate_destroy vertexbuffer_destroy gs_vertexbuffer_destroy vertexbuffer_flush gs_vertexbuffer_flush vertexbuffer_getdata gs_vertexbuffer_get_data indexbuffer_destroy gs_indexbuffer_destroy indexbuffer_flush gs_indexbuffer_flush indexbuffer_getdata gs_indexbuffer_get_data indexbuffer_numindices gs_indexbuffer_get_num_indices indexbuffer_gettype gs_indexbuffer_get_type texture_rebind_iosurface gs_texture_rebind_iosurface texture_get_dc gs_texture_get_dc texture_release_dc gs_texture_release_dc
2014-08-07 23:42:07 -07:00
tf->whatever = gs_effect_create_from_file(effect_file, NULL);
bfree(effect_file);
2013-09-30 19:37:13 -07:00
if (!tf->whatever) {
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
filter_destroy(tf);
tf = NULL;
2013-09-30 19:37:13 -07:00
}
obs_leave_graphics();
UNUSED_PARAMETER(settings);
2013-09-30 19:37:13 -07:00
return tf;
}
static void filter_render(void *data, gs_effect_t *effect)
2013-09-30 19:37:13 -07:00
{
struct test_filter *tf = data;
if (!obs_source_process_filter_begin(tf->source, GS_RGBA,
OBS_ALLOW_DIRECT_RENDERING))
return;
obs_source_process_filter_end(tf->source, tf->whatever, 0, 0);
UNUSED_PARAMETER(effect);
2013-09-30 19:37:13 -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
struct obs_source_info test_filter = {
.id = "test_filter",
.type = OBS_SOURCE_TYPE_FILTER,
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
.output_flags = OBS_SOURCE_VIDEO,
.get_name = filter_getname,
.create = filter_create,
.destroy = filter_destroy,
.video_render = filter_render,
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
};