Currently only has hand-picked tests and very rough code, but it's a
start. In the future, I want to have better tests, more
options like printf's %e/%f/%g, and more versatile methods.
* Add a unit testing framework in libnum/test/. Assertions are checked
against sparse sets of input values (a couple thousands for each
type), distributed fractally.
* Add performance tests for num16.
* Fix an overly ambitious substitution of /256 by >>8 in num16::mul,
which would give some incorrect results for negative results.
* Also fix an incorrect sign extension in the num16->num32 conversion.
* Express comparison-with-int operators in terms of the integer even
though some versions are faster when expressed in terms of the fixed-
point value. This is because the integer is frequently known at
compile-time.
* Add minDouble and maxDouble static members to each num type to
programmatically supply the bounds of the type.
This change adds tests for libnum (run with `make -C build-x tests`)
that compile example programs with g++ and evaluate how optimized the
assembly code is. This is done by checking user-provided specifications
of what instructions should and shouldn't be used against the compiled
assembler.
* Update the build system to support intermediate installs (instead of
exposing CMake targets that were only usable from within the main
CMakeLists.txt).
* Finish the emscripten build and add detailed instructions in
README.md.
* Get rid of runtime GLSL files by embedding them into a C file. This
solves the annoying problem of where to install them and how to find
them at runtime.
* Provide FindAzur.cmake to access the library. At the moment the module
still needs to be found which requires a set(CMAKE_MODULE_PATH) in
user applications. I consider this an acceptable compromise.
* Automatically go soft-fullscreen in the emscripten application.
This properly separates the libraries developed here from the (now
clearly) third-part software that we build at the same time.
There is still no install script for these libraries, they are only
usable from the main CMakeLists.txt. This will change soon.
The code for P8 failed in some non-transparent cases and I'll admit I
could not be bothered to fix it when the superiors formats were already
designed and promised a significant boost.
Lephenixnoir
Sylvain PILLOT