| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Issue: #910
|
|
|
|
|
|
|
|
|
|
|
|
Also there's this evil `static' but it probably resulted in having it
set to identity anyway.
|
|
|
|
Tracking for caps was broken.
Issue: #854, #822
Reported by: @Attigliuzzo, listekcr
|
|
|
|
|
|
|
|
|
|
Maybe global `-Wcomma' is too harsh.
There should be no functional changes whatsoever.
|
|
|
|
|
|
- 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.
|
|
It was broken for MSVC where isnan doesn't work with
fast math. Fall back to `fpclassify'.
Adjust usages.
|
|
For the Wiimote tracker.
Adjust usages in tracker/pt.
Issue: #718
|
|
Issue: #718
This allows for replacing the camera and point extractor code. See
`module.cpp' and `pt-api.hpp`.
|
|
|
|
|
|
|
|
|
|
It could cause microstutter.
|
|
|
|
It qualifies far less often now, but will likely reduce
jerkiness.
|
|
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.
|
|
|
|
We allow for max of less than a pixel skew of all the points.
|
|
Also, changing "f" typedef to "float" won't break the build anymore.
|
|
- 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
|
|
We can't possibly have LEDs smaller than (6/3=2) each.
Especially not (2.5/6).
|
|
Use stack arrays rather than vectors. std::array may be a better
choice though.
|
|
|
|
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.
|
|
|
|
|
|
|
|
Adjust usages.
|
|
|
|
|
|
Issue: #386
|
|
|
|
|
|
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.
|
|
The input array has exactly 3 points. The vector has potentially more
points, sorted by circularity.
Spotted-by: @DaMichel
Closes #380
|
|
|
