Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: BGFX Makes It Easy Targeting Multiple Rendering APIs

  1. #1
    Join Date
    Jan 2007
    Posts
    14,554

    Default BGFX Makes It Easy Targeting Multiple Rendering APIs

    Phoronix: BGFX Makes It Easy Targeting Multiple Rendering APIs

    BGFX is a cross-platform rendering library that makes it easy targeting multiple versions of OpenGL and Direct3D on platforms ranging from Apple iOS to Windows to Google Native Client...

    http://www.phoronix.com/vr.php?view=MTU0NTQ

  2. #2
    Join Date
    Feb 2012
    Posts
    183

    Default

    Sweet- wouldn't this be similar to the same kind of technology as SDL? Or perhaps even more simple, since it focuses mainly on graphics? I'd like to see what kinds of engines could plug into this, since it could be useful for game developers if it's so flexible.

  3. #3
    Join Date
    Oct 2013
    Posts
    192

    Default

    Quote Originally Posted by scionicspectre View Post
    Sweet- wouldn't this be similar to the same kind of technology as SDL? Or perhaps even more simple, since it focuses mainly on graphics? I'd like to see what kinds of engines could plug into this, since it could be useful for game developers if it's so flexible.
    This is a little bit lower level than SDL, SFML and other toolkits. It's a very thin layer over Direct3D and OpenGL with minimal overhead so there is no need for graphics engines to deal with them directly. Ogre3D and similar graphics engines which are dealing with multiple D3D and OGL backends might benefit from this.

  4. #4
    Join Date
    Dec 2012
    Posts
    196

    Default

    Quote Originally Posted by siavashserver View Post
    This is a little bit lower level than SDL, SFML and other toolkits. It's a very thin layer over Direct3D and OpenGL with minimal overhead so there is no need for graphics engines to deal with them directly. Ogre3D and similar graphics engines which are dealing with multiple D3D and OGL backends might benefit from this.
    Doesn't Valve also use a thin layer like this in their Source Engine?

  5. #5
    Join Date
    Oct 2013
    Posts
    192

    Default

    Quote Originally Posted by newwen View Post
    Doesn't Valve also use a thin layer like this in their Source Engine?
    According to the Porting Source to Linux paper they are mapping D3D calls to OGL through their togl wrapper. It's a quick drop-in solution for existing D3D based game engines, but I don't think that will be as flexible as BGFX.

  6. #6
    Join Date
    Feb 2009
    Posts
    161

    Default

    Quote Originally Posted by siavashserver View Post
    ..It's a very thin layer over Direct3D and OpenGL with minimal overhead so there is no need for graphics engines to deal with them directly. Ogre3D and similar graphics engines which are dealing with multiple D3D and OGL backends might benefit from this.
    It's not that thin of a layer, considering they their own shading language, sort drawing calls, do font rendering and have their own geometry file format.
    Ogre already have their own abstraction layer of the rendering API adapter to their specific needs, and since bgfx is not that thin, I doubt it will be useful to them.

    I never read much into Valve's approach, but it sounds like a custom implementation of the Direct3D device interface class. I could be wrong though...

  7. #7
    Join Date
    Jun 2011
    Posts
    267

    Default

    Quote Originally Posted by mdias View Post
    It's not that thin of a layer, considering they their own shading language, sort drawing calls, do font rendering and have their own geometry file format.
    Ogre already have their own abstraction layer of the rendering API adapter to their specific needs, and since bgfx is not that thin, I doubt it will be useful to them.

    I never read much into Valve's approach, but it sounds like a custom implementation of the Direct3D device interface class. I could be wrong though...
    Looks like a great library except that it's using stb_image, and to quote the Musl Wiki http://wiki.musl-libc.org/wiki/Alternative_libraries

    beware of stb* from nothings.org since author is ignorant about invoking UB

  8. #8
    Join Date
    Dec 2013
    Location
    Seattle, WA
    Posts
    2

    Default

    Hi thanks for posting about bgfx here.

    So just to clarify things, bgfx is higher level than GL/DX renderers (it's not thin wrapper around API, it doesn't try to mimic GL nor DX behavior at all), and it's lower level than common 3D engines like Ogre3D. bgfx doesn't deal with scene at all, whatever is submitted to bgfx it will be rendered. But unlike GL/DX bgfx before submittion will sort draw order and optimize to minimize state changes. Sorting allows also submission to be more optimal, since order of submission is not preserved, it's possible to submit object for multiple passes at the same time. For example if you pass over scene with GL/DX you would need to submit in order of rendering, which means you have to pass over scene multiple times in order to submit in the right order, which is usually expensive. With bgfx higher level code can traverse scene once, and submit for all passes at once, then internally bgfx sorts these draw calls and they get properly rendered.

    stb_* stuff is optional, and it's there for mostly tools and examples. It's not used in runtime. bgfx natively can process only DDS, PVR or KTX texture. Runtime code is located inside include/ and src/ (+ glext headers from 3rdparty).

    bgfx is similar to SDL, since it tries to simplifies cross-platform development. But it's focused to graphics part only and it can work with SDL, GLFW, and similar windowing APIs. I provide some basic windowing harness for examples (to minimize external dependencies), but that can be replaced with SDL, GLFW, etc.

  9. #9
    Join Date
    Jun 2011
    Posts
    267

    Default

    Quote Originally Posted by bkaradzic View Post
    Hi thanks for posting about bgfx here.

    So just to clarify things, bgfx is higher level than GL/DX renderers (it's not thin wrapper around API, it doesn't try to mimic GL nor DX behavior at all), and it's lower level than common 3D engines like Ogre3D. bgfx doesn't deal with scene at all, whatever is submitted to bgfx it will be rendered. But unlike GL/DX bgfx before submittion will sort draw order and optimize to minimize state changes. Sorting allows also submission to be more optimal, since order of submission is not preserved, it's possible to submit object for multiple passes at the same time. For example if you pass over scene with GL/DX you would need to submit in order of rendering, which means you have to pass over scene multiple times in order to submit in the right order, which is usually expensive. With bgfx higher level code can traverse scene once, and submit for all passes at once, then internally bgfx sorts these draw calls and they get properly rendered.

    stb_* stuff is optional, and it's there for mostly tools and examples. It's not used in runtime. bgfx natively can process only DDS, PVR or KTX texture. Runtime code is located inside include/ and src/ (+ glext headers from 3rdparty).

    bgfx is similar to SDL, since it tries to simplifies cross-platform development. But it's focused to graphics part only and it can work with SDL, GLFW, and similar windowing APIs. I provide some basic windowing harness for examples (to minimize external dependencies), but that can be replaced with SDL, GLFW, etc.
    Is Mesa's OpenVG and Nvidia Path Rendering something you would be willing to consider including at some point?

    Also I see ...

    OpenGL 3.1
    OpenGL ES 3

    Isn't OpenGL ES 3 something you get for free via OpenGL 4.3, just wondering why there is OpenGL ES 3 support and not OpenGL 4.3+ support.
    Last edited by zester; 12-17-2013 at 01:04 PM.

  10. #10
    Join Date
    Oct 2013
    Posts
    192

    Default

    @bkaradzic

    Thank you very much for joining us

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •