What does HackerNews think of bgfx?

Cross-platform, graphics API agnostic, "Bring Your Own Engine/Framework" style rendering library.

Language: C++

#1 in OpenGL
Vulkan is sort of a post-API API. It seems to be designed specifically with high performance render pipelines in mind, and "end users" should interface with it through an intermediary layer.

Ie, you might prefer bgfx[0], cinder[1] or openframeworks[2].

0: https://github.com/bkaradzic/bgfx

1: https://www.libcinder.org/

2: https://openframeworks.cc/

>don’t say GitHub

Gitlab, Bitbucket.

I don't really know what to expect. You want to see good production code, and the FOSS community is way way WAY better at this than some of the bubble gum you'd see in a professional setting.

Your question is too general, so I can't exactly give you a specific repository. I could direct you to BGFX[1] for a decent architecture of a cross platform renderer, but if you're not a graphics programmer, that may be a bad exercise, as you'd spend more time learning jargon than studying clean code. Or it uses patterns (or lack of, given graphics programming) that don't apply to your domain.

[1]: https://github.com/bkaradzic/bgfx

If you target PC/Console and don't have an abstract GPU interface, then you should rethink your life choices

And all the graphics stacks nowadays are similar, Vulkan, Metal, DX12, all share the same ideas

Also there are countless opensource cross platform GPU libs, bgfx [1] or sokol [2] for example

[1] - https://github.com/bkaradzic/bgfx

[2] - https://github.com/floooh/sokol

I've had a decent experience with bgfx (https://github.com/bkaradzic/bgfx). It is solely a rendering library (no input, physics, sound, etc). It operates a layer just above a native rendering library, such as DirectX, OpenGL, Vulkan, Metal, etc - those are the "backend renderers" that bgfx uses.

Though I have my complaints about it, I think bgfx gives a good powerful-but-not-too-complicated abstraction over graphics programming; for some design info, see: https://bkaradzic.github.io/bgfx/internals.html

Sokol author here (thanks for the mention). I think it's important to note that Magnum has a much wider scope than both sokol-gfx and WebGPU (see here: https://magnum.graphics/features/extras/). sokol-gfx and WebGPU are "just" 3D API wrappers, while Magnum is a much more complete C++ framework for writing 3D applications. I've been following Magnum (and the author Vladimír Vondruš) for a long time, it's an excellent project with a lot of great ideas, and a nicely balanced C++ API (which is a feat of its own). Also I'm kinda jealous of the documentation: https://doc.magnum.graphics/magnum/ :)

PS: also don't forget BGFX (https://github.com/bkaradzic/bgfx) which sits somewhere in the middle between sokol-gfx/WebGPU and Magnum when it comes to API abstraction and feature set.

It seems they are going to duplicate the efforts from bgfx (https://github.com/bkaradzic/bgfx)
Cairo/Skia are not the only alternatives for Linux.

For example, one pretty nice cross-platform GPU-enabled stack :

https://github.com/bkaradzic/bgfx

https://github.com/memononen/nanovg

https://github.com/wjakob/nanogui

I stumbled upon this looking into BGFX[1]. I've been looking for an abstraction layer over Vulkan and Metal and it has come down to BGFX and Diligent Engine[2]. Diligent is still a bit lower level than I'd like, so I started poking around to see who was using BGFX. I was surprised to find Microsoft is using it in their C++ version.

[1]https://github.com/bkaradzic/bgfx [2]https://github.com/DiligentGraphics/DiligentEngine

I believe bfgx[0] is similar to what you're describing. It's been around since before the Vulkan/DX12/Metal era so the abstractions are more similar to OpenGL/DX11 where you don't have concepts like command buffers and command queues etc, which might be a turn off.

Big open source projects still seem to roll their own solution for this, which I imagine is both for historical reasons but also because there might be a fear that using a library like this could leave your hands tied when you need to do some API-specific workaround.

0. https://github.com/bkaradzic/bgfx

bgfx is such a layer: https://github.com/bkaradzic/bgfx

It exposes a common API to 3d GPU resources and implements it in terms of native backends.

As a nice complement to GLFW, there's also bgfx which can be configured to use GLFW:

https://github.com/bkaradzic/bgfx

Turns out it was a good idea to base new stuff on this: https://github.com/bkaradzic/bgfx
Maybe https://github.com/bkaradzic/bgfx or maybe http://www.ogre3d.org depending on the abstraction level you are looking for.
I'm using https://github.com/bkaradzic/bgfx for low-level rendering abstraction. IIRC in the engine there is no difference between opengl and d3d other than a projection matrix. On the outside there can be a difference, e.g. if opengl does not support some operation d3d does (because of drivers). On my computer D3D a tiny bit faster than OGL on windows.

I've not tried Linux for a long time, so it's possible there are some issues. But it's definitely compilable and it used to run few months ago.

MacOS port should be easy, there once was a branch with a lot of stuff already ported, but it was done by other programmer and he did not finish it.

A game engine is mostly tools, foundations (containers, serialisation), gameplay frameworks (entities, components, AI). This is not a game engine by my definition if it's marketed as "Vulkan only". Also, I have the feeling that every game should look different and have its own art direction, being able to switch the whole rendering pipeline is essential. Why not contribute to bgfx[1] really? It's a "Graphics API", not a "game engine"...

[1] https://github.com/bkaradzic/bgfx

Of course they do, but under NDA, just ask. OpenGL on top of whatever GAPI is on target platform is usually <100 KLOC, so completely possible to write your own if you REALLY need to (really is when your 1kk+$ budget game will fail just because there is an engineering problem).

And if you don't have resources to ask/communicate than just use something like https://github.com/bkaradzic/bgfx/ which is an awesome API agnostic rendering library.

What's your goal exactly? Depending on your goal there's a few routes.

If you want to produce compelling VR experiences then I'd recommend you download Unity. You should be able to start making real, valid prototypes for different types of VR interactions in under a week.

If you want to graphics then I might recommend you poke at http://humus.name/index.php?page=3D or https://github.com/bkaradzic/bgfx. But graphics isn't my specialty so my thoughts aren't the strongest.

If you want to learn C++ then... that's an interesting question I've not thought of before. Maybe I'd start with "Learn C the Hard Way"? http://c.learncodethehardway.org/book/ I'm not as much of a C fanboy/C++ hater as other game devs. I quite like C++11 lambdas and move semantics. But I hate boost and it's ilk. So starting with C and later adding a dash of C++ seems like a good way to start.

> but there really isn't a library that tries to do > just 2D with some filtering+scaling

While not a 2D library, https://github.com/bkaradzic/bgfx is a very sweet abstraction layer over platform graphics APIs

I'd recommend bgfx (https://github.com/bkaradzic/bgfx), if you want something simple and cross platform. In many ways it reminds me of a 3D SFML.
You should definitely check out bgfx (https://github.com/bkaradzic/bgfx). It abstracts various graphics APIs for you, making development and debugging markedly easier. It also stops you from having to deal with the complex state-machine known as GL.