Releases: tshino/softcam
Releases · tshino/softcam
v1.8.1
v1.8
What's Changed
- Added
scIsConnected()method to API to make application connection waiting more flexible by @jekyll2014. (thanks!) #51 - Added corresponding
is_connected()method to the python_binding example. - Updated solution file version from Visual Studio 2019 to Visual Studio 2022. #45
- Added
pushd/popdto example installer BAT files to work correctly even if launched from another directory. #48
New Contributors
- @jekyll2014 made their first contribution in #51
Full Changelog: v1.7...v1.8
v1.7
What's Changed
- Bumped NuGet package version of Google Test.
- Changed the primary target compiler from Visual Studio 2019 to Visual Studio 2022. #44
- Have set TargetName property explicitly instead of letting it use the default ($(ProjectName)) for each project to prevent output file names from changing even if project file names change.
- Duplicated all existing project files with _vs2019 suffix added to maintain VS2019 support.
- For example,
softcam_vs2019.slncan be used as same as the previoussoftcam.sln. All the output files keep the same name as before.
- For example,
- Updated the GitHub Action workflow files to let them keep using the latest solution file (
softcam.sln). - Retargeted all project files (except
*_vs2019) to use the VS2022 toolset.
- Refactoring:
- Named namespaces of each test code for better visualization on Visual Studio. #42
Full Changelog: v1.6...v1.7
v1.6
v1.5
v1.4
v1.3
- Improved accuracy of timing control.
- Fixed an issue on Debug DLL.
- The
senderexample program was making an assertion failure when it stops with Ctrl+C pressed by the user. - The cause of the assertion failure is a global destructor for a global std::mutex object in softcam.dll. The assertion in the destructor claimed that the mutex object is still locked. That happens because when Ctrl+C has pressed the whole program execution stops immediately no matter the state of mutex objects and then the global destructors are invoked after that.
- This fix removes unnecessary global destructors to avoid such a scenario.
- The
v1.2
- Added support for 32-bit camera applications #3.
- To support both 32-bit and 64-bit camera applications, each of the DLL
softcam.dllof both modes must be built and installed. - Once both DLLs are installed in a system, no matter which one your application links to or which one the camera application accesses to, they can communicate and the images are streamed between them correctly.
- To support both 32-bit and 64-bit camera applications, each of the DLL
- Changed the layout of the
distdirectory:dist/bin/x64<-dist/bindist/lib/x64<-dist/libdist/bin/Win32(NEW)dist/lib/Win32(NEW)
- Fixed an issue on Debug DLL name confusion.
- The example program
sender.exewithDebugconfiguration was failing to run because the import librarysoftcamd.libwrongly tries to findsoftcam.dll(notsoftcamd.dll). - Now the import library is fixed to use
softcamd.dllcorrectly.
- The example program
v1.1
- Added PostBuildEvent which makes the
distdirectory that holds the header and the binaries. - Changed the build configuration of examples to use the
distdirectory and made them independent of the library's build. - Improved timing calculation.
- Added a figure on top of the README.