| Age | Commit message (Collapse) | Author |
|---|
|
Use more C++17 features where this helps any.
|
|
|
|
Remove useless abstract member functions, simplify
some.
Issue: #718
|
|
- use `static constexpr inline' to avoid requiring
explicit declarations in object code
- use `const Foo* const' to maybe put into readonly
binary segment (at least for ELF DSOs)
- `constexpr' in function scope has storage, avoid
`static'
- don't use `constexpr' where there's no advantage,
like arrays
We'd like to avoid overhead of atomic initialization
for each function call. No idea how `static constexpr'
requiring storage in the standard plays with atomic
initialization requirement. Hearsay points that
`constexpr' without `static' in block scope behaves
more to our liking. It's all hazy though.
I'm not 100% sure if `static inline constexpr' has any
storage. Hopefully none, like a #define, and stuff
bigger than registers gets coalesced within the same
module, with small stuff being immediates.
|
|
Adjust usages.
|
|
|
|
Somehow, using unique_ptr causes a leak at destruct time. The stored
pointer isn't freed. It works perfectly fine with shared_ptr.
It seems I'm doing things correctly with a move constructor for
unique_ptr in the Tracker_PT class, as well as the pointer
initialization ctor in `module.cpp'. Who the hell knows what's happening
behind the scenes.
|
|
Issue: #718
|
|
Issue: #718
This allows for replacing the camera and point extractor code. See
`module.cpp' and `pt-api.hpp`.
|
|
|
|
|
|
I haven't even compile-tested Linux and OSX-specific bits.
|
|
|
|
|
|
|
|
We heavily used "volatile bool" to check if the thread
loop should stop. But this functionality is already
provided by Qt5's QThread::requestInterruption.
In other cases, "volatile" is wonderfully
underspecified so it's better to ditch its usage in
favor of std::atomic<t>. At the time we don't appear to
be using the "volatile" keyword except when calling
win32's Interlocked*() family of functions as
necessary.
In freetrackclient's header the "volatile" qualifier
was used as part of a typedef. This doesn't work. Use
it as part of data declaration.
|
|
|
|
- move dt handling here, from ITracker impl
- don't depend on other PT headers. we'd like to reuse the code.
- adjust return value convention.
- get rid of dt_valid
- return fps as a double
Adjust usages in ITracker impl and dialog.
|
|
|
|
This makes the point size text and point crosses not alias due to the
resize.
Due to nice pixel coordinate system, the cross-drawing lambda only needs
minimal changes.
|
|
- Pass `struct CamInfo' rather than several elements separately
- Reformat
- Return `struct CamInfo' together with the frame since then it's always valid
- Move the focal length formula into `struct CamInfo'
- Remove incorrect focal length formula rather than #if 0
- Pass some stuff by reference and not by pointer
|
|
|
|
- separate .{cpp,hpp} for few classes
- don't include namespaces globally; harmless but looks bad
anyway
- class with all public members to struct
|
|
|
|
|
|
|
|
With -D_USE_MATH_DEFINES MSVC defines the standard M_PI and
friends.
Since this preprocessor definition is now always passed as part
of the build system for MSVC. We can use M_PI as if on a
mission.
|
|
|
|
It's broken and users complain on the issue tracker.
Also fix tab stops.
|
|
Adjust usages.
|
|
Adjust usages in PT and Aruco trackers.
|
|
|
|
|
|
We can't depend on M_PI existing after including cmath.
|
|
|
|
We want double precision for POSIT. It's best for the type to be set in
ope place without the need to go over everything while switching it back
and forth during tests.
Machine epsilon for float is very small as per
<https://en.wikipedia.org/wiki/Machine_epsilon>. Also see the absurdly
high epsilon of 1e-4 of POSIT that we've had. With floats, making the
epsilon lower resulted in change deltas flushing to zero. This typically
led to the translation Z value being very unstable in PT.
After the epsilon and data type size changes the Z value is stable.
|
|
|
|
|
|
|
|
Adjust usages.
|
|
There's a race here since further accesses to the points array aren't
protected by a mutex in the extractor class.
There's no race in "get_points()" in the extractor since it's only used
in same thread where updates take place.
|
|
|
|
|
|
Closes #224
|
