Hello Guest

bgfx module

  • 13 Replies
  • 10745 Views
*

Offline CoDi

  • *
  • 49
bgfx module
« on: September 09, 2016, 12:54:02 »
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.

*

Offline spasi

  • *****
  • 2261
    • WebHotelier
Re: bgfx module
« Reply #1 on: September 09, 2016, 13:49:58 »
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.

*

Offline CoDi

  • *
  • 49
Re: bgfx module
« Reply #2 on: September 11, 2016, 10:59:12 »
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.

*

Offline spasi

  • *****
  • 2261
    • WebHotelier
Re: bgfx module
« Reply #3 on: September 11, 2016, 16:45:34 »
Oh, you're making the bindings already, awesome!

*

Offline CoDi

  • *
  • 49
Re: bgfx module
« Reply #4 on: September 11, 2016, 18:13:14 »
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.

*

Offline CoDi

  • *
  • 49
Re: bgfx module
« Reply #5 on: September 13, 2016, 07:05:27 »
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).

*

Offline spasi

  • *****
  • 2261
    • WebHotelier
Re: bgfx module
« Reply #6 on: September 13, 2016, 23:16:36 »
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).

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.

*

Offline spasi

  • *****
  • 2261
    • WebHotelier
Re: bgfx module
« Reply #7 on: September 14, 2016, 09:49:03 »
Added the MapToInt modifier with af6974d.

*

Offline CoDi

  • *
  • 49
Re: bgfx module
« Reply #8 on: September 14, 2016, 12:22:47 »
 :o

Looking good! Before:

Code: [Select]
bgfx_set_view_clear((byte)0,
(short)(BGFX_CLEAR_COLOR | BGFX_CLEAR_DEPTH),
0x303030ff,
1.0f,
(byte)0);

After:

Code: [Select]
bgfx_set_view_clear(0,
BGFX_CLEAR_COLOR | BGFX_CLEAR_DEPTH,
0x303030ff,
1.0f,
0);

*

Offline CoDi

  • *
  • 49
Re: bgfx module
« Reply #9 on: September 21, 2016, 21:16:51 »
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).

*

Offline CoDi

  • *
  • 49
Re: bgfx module
« Reply #10 on: September 24, 2016, 10:36:42 »
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.

*

Offline spasi

  • *****
  • 2261
    • WebHotelier
Re: bgfx module
« Reply #11 on: September 24, 2016, 12:17:12 »
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.

Re: bgfx module
« Reply #12 on: April 07, 2017, 15:37:36 »
Do you have any results to show? Real completed examples?

*

Offline CoDi

  • *
  • 49
Re: bgfx module
« Reply #13 on: April 07, 2017, 17:08:54 »
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.