bgfx VS magnum

bgfx seems interesting if you aren't going to use SFML. Gets you rendering.

You can also check bgfx, although this is just a rendering library. (In their github they have a showcase of projects, game engines and games developed with it)

And bgfx does it with graphics and ui.

I know I've seen a few key graphics layer abstraction libraries, but I can't recall which ones are best, perhaps (I just saw) bgfx?

BGFX is a somewhat popular cross-platform rendering library that is written in C-style C++ (the author calls it Orthodox C++ ).

bgfx

Ovaj lik ima srpsko ime, al ne znam dal je stvarno iz srbije, ima dosta veliki projekat iza sebe: https://bkaradzic.github.io/bgfx/overview.html

Perhaps not quite what you're looking for, but I've had a reasonably good experience with bgfx. It's basically 1 level of abstraction above specific graphics APIs (GL, DirectX, etc). It is not a full game engine, just a rendering API.

Im using this lib for getting renderer API, on pretty old PC with win7x86 works pretty fine, but when Im trying to start it on Windows 10x64 with DirectX11(software) on DirectX10(hardware) it says the next thing:

You'll probably have more luck here: https://github.com/bkaradzic/bgfx/discussions

> He has Vulkan support in here with a clearly marked file named Pipeline.cpp. The guy knows what a pipeline is...

There is a Vulkan API wrapper. However, there is no "Vk Renderer" -- no code seems to use the Vulkan parts of the code system, and the two projects seem unrelated.

> * Is this not a UBO interface?

There are ways of making a uniform buffer, however the examples don't cover them and the API doesn't adapt automatically. See how all of the setters assert if UBOs are enabled.

https://github.com/mosra/magnum/blob/cfc02599e54e02337dd56bb...

> * I don't see why you think there's limited support for multiple framebuffers...?

The code I do see is about binding/unbinding framebuffers in a stateful manner, e.g. AbstractFramebuffer::bind(), rather than supporting passes.

> None of your criticism seem well intentioned. It might behoove you to give people the benefit of the doubt and realize that you may be able to learn something from them, even if they're so clearly inferior to you.

To put it simply, I've taught enough graphics to know first-hand the kinds of misconceptions that OpenGL-styled APIs can cause, and I'm just a bit tired to see it continue. Admittedly I was a bit harsh, I don't mean any harm towards the author. There are just graphics APIs with interfaces I consider to be much better designed.

I've not played with this one, but looks promising: Look­ing for an open-source lib­rary that gives you graph­ics ab­strac­tion and plat­form in­de­pend­ence on ma­jor desktop, mo­bile and web plat­forms? Do you want it to have all the con­veni­ence util­it­ies around yet stay small, power­ful and not give up on flex­ib­il­ity? And it’s free to use, even for com­mer­cial pur­poses. https://magnum.graphics/

I have just started a project using the magnum graphics library and I’m finding it very enjoyable. It is easy to get started with, provides a lot of functionality and has good documentation/examples.

If you want to take some of the legwork out of the rendering, the Magnum framework is a pretty thin wrapper that provides some basic abstraction around the graphics API. Haven't used it for Vulkan before, but for GL it's pretty nice. It's C++ though. If you really want all this granular control anyways, why not just write in C++?

It's not a tutorial, but magnum is a modern C++11/14 graphic engine actively developed by a small team.

There are code-only engines like Urho3D, Monogame, etc. Unfortunately there aren't a ton of options, though, and in many cases it becomes worth it to just write games without an engine. Libraries like Magnum and EnTT can help reduce the legwork.

Doing all that in Rust might be too much to ask for; there are libraries like Magnum that make it pretty easy to support Windows/Linux/Android and Emscripten/WebAssembly, but I'm not sure you're going to find anything that's not in C++, and/or that works on mac.