Age | Commit message (Collapse) | Author |
|
|
|
By @drdanilov21. We'll likely need it in the future.
|
|
LoadStringFromFile result is always AnsiString.
I'm using the Unicode InoSetup version so paging @ph0b.
|
|
It's used in the win32 installer.
This reverts commit 3252beca3aa20fe5183a13029db831e4e121f6dc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We no longer have this recurring problem since I enabled
ignoring executable bit changes on the Windows workstation.
|
|
For my convenience.
|
|
Previous disallowed binding an already-bound key on Unix since Qxt
doesn't pass through bound keys unlike the Windows implementation.
Refactor some common code.
The Windows implementation isn't even compile-tested.
|
|
Issue: #349
Valgrind: yes
|
|
|
|
|
|
Committer shouldn't push so fast to get a chance to rebase.
Closes #356
|
|
Previous commit fixed only the case with one perpendicular axis of
rotation with the rest fixed at origin. This one works with all three
degrees of freedom enabled.
Reported-by: @MathijsG
Issue: #356
|
|
|
|
74d9f5e31428ef362033a63c10b781d943c5e5a5 skipped some of intermediate
computations.
|
|
We actually need to use a float intermediate type lest the value gets
truncated.
|
|
With a very small denominator in barycentric coords formula we get a
dissociated octopus that took PCP and LSD in one sitting.
A dead Octopus is just a bunch of blue spheres.
IOW, in division with too small a denominator operand the results are
numerically unstable.
This is done in the constructor in a convoluted way as to avoid
branching during calculating for each pixel.
Issue: #356
Reported-by: @MathijsG
|
|
This reverts commit 546cfb5ad52dcfe1421d1af5e7baeada588ac735.
@MathijsG points out that some users have red LEDs, not uniform white.
Issue: #355
|
|
The confusion stems from the max slider value. It's 255, not 100 as is
the default. Max pixel count change to 20 was confused as we'll counting
area and not radius here. Taking into account that the value was divided
by 100 previously, it's bit less than the previous one but not as
confused as then.
Reported-by: @MathijsG
Issue: #355
|
|
|
|
|
|
|
|
|
|
|
|
The numeric warnings are somewhat useful. Sadly only clang supports the
vtable object file bloat warning.
|
|
|
|
The files are machine-generated and full of redundancies. With pedantic
warnings it drowns the relevant stuff.
|
|
It's pointless for it to exist, see previous commit for rationale. No
call sites.
|
|
With the GNU toolchain there's some mix-up and the "opentrack_version"
symbol isn't emitted into the object file at all. Disable LTO for the
"version" statically linked library.
The "version" statically linked library exists so that files needing the
version only need to be re-linked, not recompiled. A preprocessor global
-DVERSION=foo rebuilds the whole project after each commit. A header
definition rebuilds all include sites.
LTO in the GNU toolchain is very broken on Windows, particular the
interaction of GCC "linker plugin" injected into Binutils bfd ld. The
gold ld we can't use since it's only for ELF executables.
There's nothing alarming here at all unless there's some miscompilation
and there doesn't seem to be any. The rest of the functional changes is
changing cc -> c of that object file, and moving library definition
after the source file is already generated.
|
|
Due to typo axis index got saved as the same .ini name as another index.
Spotted-by: @Ec0nomist
Confirmed-by: @huliqan
Issue: #327
|
|
Spotted-by: @Ec0nomist
Issue: #327
|
|
I'm unsure whether the context object for QObject::connect overload
we're using in enum support is treated as the connection's target thread
at all. Docs are silent on this.
In the meantime, no crashes or other anomalies observed, while violating
Qt thread safety invariants resulted in immediate crashes beforehand. So
let's use Qt::AutoConnection and not worry for the time being.
|
|
|
|
|
|
Issue: #327
|
|
|
|
|
|
The api callee already takes care of that so remove the "ok" argument.
|
|
|
|
|
|
The resync code already worked without that.
|
|
|
|
We don't need to move back the datagram since we're processing the
original.
|
|
|
|
|