This commit changes the command generation mechanism. Instead of
creating a command on the stack then calling azrp_queue_command() which
does a needless copy, the new function azrp_new_command() allocates
directly inside the command buffer, avoiding the copy.
This concept is pushed further with the introduction of finer-grained
functions azrp_alloc_command(), azrp_finalize_command() and
azrp_instantiate_command(), which split this process in three steps.
This allows generating commands of variadic size in-place in the
command buffer as well as using non-interval fragment sets.
* 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.
* 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.
Lephenixnoir