bgfx module

Started by CoDi, September 09, 2016, 12:54:02

Previous topic - Next topic

CoDi

Has anyone ever considered adding bindings to the bgfx library? It seems quite popular and is actively maintained. It provides a clean API with multiple back-ends, including Metal and Direct3D, and features C99 headers.

I don't have any experience with the LWJGL generator, so it's hard to tell if there are any obvious showstoppers. For example, bgfx comes with its own build system based on premake/LUA, so I'm not sure what the implications are with that, if any.

spasi

Yes, bgfx has been in my radar for a long time. I especially like that it's a great D3D solution, without having to add D3D bindings to LWJGL.

The C API is straightforward and there won't be any issues with the bindings.

The problem is that since bgfx is extremely customizable, it doesn't make much sense for LWJGL to include pre-built binaries. Users would have to build bgfx on their own (for each platform) and the LWJGL bindings would just use those natives. If you don't mind that, please add an issue on GitHub and I'll make time to create the bindings sometime after the 3.0.1 release.

CoDi

It's a bumpy ride, but I'm slowly getting somewhere...  :o

I now got the bgfx C99 example running on Windows with Direct3D 11, using GLFW for window creation.

spasi

Oh, you're making the bindings already, awesome!

CoDi

Yeah, learning a lot about my wrong assumptions about the generator and the stupid mistakes I did along the way. I'll push the branch to my GitHub fork after I got a few more examples ported and working.

CoDi

My GitHub branch

Current state: two samples ported and working, and I finally figured out how to avoid generating a "lwjgl_bgfx proxy library" just for the JNI bindings. Should have followed the GLFW example more closely sooner. ;D

I'm sure there are some more mistakes lurking in the binding script, which I want to wipe out by porting some more examples.

One question: the bgfx API uses uint8_t and uint16_t function parameters at many places, which is kind of inconvenient in Java because you have to (short) and (byte) cast a lot. Is there an option maybe to selectively generate int parameters in Java which still map to the correct (smaller) C type?

If there isn't, would that be a reasonable idea? Like a modifier, e.g. asInt..uint8_t.IN("_stage", "") (with a more fitting name, of course).

spasi

Quote from: CoDi on September 13, 2016, 07:05:27One question: the bgfx API uses uint8_t and uint16_t function parameters at many places, which is kind of inconvenient in Java because you have to (short) and (byte) cast a lot. Is there an option maybe to selectively generate int parameters in Java which still map to the correct (smaller) C type?

If there isn't, would that be a reasonable idea? Like a modifier, e.g. asInt..uint8_t.IN("_stage", "") (with a more fitting name, of course).

Interesting. No other library uses bytes/shorts in function parameters, so there hasn't been a need for such a modifier. It is certainly possible to create one.

spasi

Added the MapToInt modifier with af6974d.

CoDi

 :o

Looking good! Before:

bgfx_set_view_clear((byte)0,
		(short)(BGFX_CLEAR_COLOR | BGFX_CLEAR_DEPTH),
		0x303030ff,
		1.0f,
		(byte)0);


After:

bgfx_set_view_clear(0,
		 BGFX_CLEAR_COLOR | BGFX_CLEAR_DEPTH,
		 0x303030ff,
		 1.0f,
		 0);

CoDi

Current state: four examples ported and working. Just now I got bgfx' OVR mode running (and the matrix/quaternion math ported properly thanks to JOML).

CoDi

Update: I rebased and squashed my commits on the current master branch, so that the Git history isn't polluted too much with my meanderings. :P

I also ported one more example which tests geometry instancing and some texture functions.

Some open issues:


  • Documentation. I dodged the topic so far. What's your guidelines here?
  • As the package does not include a bgfx shared library, we may need to document how to build or where to obtain one.
  • 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.
  • 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.

spasi

Quote from: CoDi on September 24, 2016, 10:36:42Documentation. 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.

Quote from: CoDi on September 24, 2016, 10:36:42As 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?

Quote from: CoDi on September 24, 2016, 10:36:42The 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).

Quote from: CoDi on September 24, 2016, 10:36:42API 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.

dmitrykolesnikovich

Do you have any results to show? Real completed examples?

CoDi

Quote from: dmitrykolesnikovich on April 07, 2017, 15:37:36
Do you have any results to show? Real completed examples?

I ported some of the bgfx demos, which are now part of the lwjgl3-demos repository.