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.
* Add build instructions for Dear ImGui that build the SDL +
OpenGL 3 / OpenGL ES 2 backend.
* Use Dear ImGui's bundled GL3W as a loader (including in azur itself,
which has not been using a loader until now).
* Properly select headers for OpenGL ES 2.0 (with the VAO extension) and
attributes for WebGL; clear up OpenGL 4 error codes.
* If FreeType2 is available through pkg-config, or if empscripten is
used (since it has a FreeType port), use FreeType to render fonts in
Dear ImGui for much-appreciated hinting quality.
Minor changes:
* Add window title to azur_init().
* Use emscripten's infinite loop simulation to make sure everything
stays in the same thread. This is needed for Dear ImGui to work.
This basic model supports a couple of options, but mostly designed for
three targets:
* gint on fx-CG 50, with a custom XRAM-streaming rendering engine that
is (to my knowledge) more powerful than all other existing options;
* The standard SDL/OpenGL combo for desktop platforms, using modern
OpenGL 3.3 and some basic shaders.
* The web platform with emscripten and its OpenGL ES 2.0 API that maps
to WebGL 1.0. OpenGL ES 2.0 code could also be used for mobile
platforms if this ever comes up.
The current code only includes setting up the program's main loop
(update/render) as well as basic rendering.
The framework of gint's rendering engine is drawn ("shader"-based
rendering in XRAM). On the OpenGL side, some utilities are defined,
including a primitive layer of shader code compatibility for OpenGL 3.3
vs. OpenGL ES 2.0. Actual rendering is still at prototype stage.