Documentation. I dodged the topic so far. What's your guidelines here?
Documentation is good to have, but obviously the most boring part of adding a new binding. LWJGL already has bindings with no documentation (e.g. EGL, GLES, Nuklear), even though the template DSL is designed to require it. A working binding without docs is better than nothing, so this isn't a blocking issue.
As the package does not include a bgfx shared library, we may need to document how to build or where to obtain one.
Good idea, maybe add it in the packageInfo documentation?
The examples download a dependency (JOML) and copy a pile of assets from the bgfx repository. Not sure if that troubles at some point. Most of them are precompiled shader files which could also be inlined as byte[] tables. One of the examples works like that already.
I'd like the lwjgl3 repo to be light on dependencies. A solution would be:
- Keep simple demos, that could be used as basics tests for the binding, in lwjgl3.
- Move demos with dependencies/assets to
lwjgl3-demos. It includes JOML already and you can just push assets there directly (instead of going through build-assets.xml).
API test coverage still isn't particular great, so I'm pretty sure there are still some API quirks and/or bugs. Would need to port more examples, though at one point this would become an interesting task, as many of them work with imgui - which means porting them w/o GUI, or refactor them to use Nuklear for example.
The nice thing with LWJGL 3's lightweight approach is that you don't really need that much coverage. If a basic demo works, it's very unlikely that you'll encounter issues with more tests (unless the library design has an odd feature not already encountered in other libraries - use of va_list is an example of that). Full API coverage is not realistic (imaging testing everything in OpenGL) and most demos in lwjgl3 are there as tutorials for users, not for testing functionality. So, don't worry about this either.