magnum VS godot-proposals

Magnum

If you want something that gives you more control you could use magnum.

Therefore, in terms of artist mindshare, Blender is the leading open source 3D creation program, but not the leading 3D creation program. I think Godot is already in a similar situation, and has been for a few years now. In comparison, most other open source game engines have focused on providing low-level functionality. These certainly fulfill a niche, but in my experience, most people want something that works at a higher level and comes with a built-in editor.

Magnum is worth checking out.

Since you want something lightweight, I'll assume you mean the former. If that's the case, then checkout bgfx or Magnum. Magnum does include some extra features typically found in a graphics engine.

You could try Magnum it wraps SDL and others, but you might find it maybe too low-level. It's certainly not Love2D.

C++ is similar to C in that there are multiple "styles" of use that vary from project to project. Other, usually newer languages (C#, Python, Rust, etc) tend to have a stronger sense of what idioms should be used. Whereas, for instance, some C++ projects (like some GUI libraries and game/graphics engines) will partially/entirely replace the STL (and older ones may have been around before C++ had a standard library aside from C's), or forbid the use of certain C++ features (example).

Magnum Graphics

> 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.

Godot was fine, for the most part, it's a good engine for small games. The main issue was around working together and resolving conflicts with git (Godot isn't really working and constantly kept changing IDs in resource files), and it kept losing data in scenes when the code changed so we had to rebuild things several times. On previous test games we also ran into huge performance issues in the editor when we wanted to do too much work in scenes, so we had to switch to doing most of the work in code.

The worst part was when I had to rip out a bunch of testing code that used @tool for release as it seemed to cause issues when doing a release build. The engine is generally not great when you want to follow clean software engineering (e.g. dependency injection is not possible, I opened a proposal to that end here[1]).

[1]: https://github.com/godotengine/godot-proposals/issues/8850

If we had a Mask2D, this would be super easy and straight forward.

So if that's what OP meant, clip_children property won't work. Instead OP needs to use a CanvasGroup parent and the Line2D (with CanvasItem Material in Subtract mode) and TextureRect as siblings, or any of the other methods explained here until we have a Mask2D node.

There is an open proposal to have a compile option for a LibGodot, as a Library https://github.com/godotengine/godot-proposals/issues/6267

Yes, there could be the option to open at least 2 tabs at the same time, when working with scripts. This has probably already been suggested in: https://github.com/godotengine/godot-proposals

I cannot tell exactly where the jitter is from the video, but if it is what I'm thinking of, it is a known issue, see here. There is a proposal to fix this, with tons of discussion here. Try some of the workarounds mentioned in these two links. Game looks great by the way!

It's in the release notes. Here is a link to the pull request, based on this proposal.

Currently not possible: https://github.com/godotengine/godot-proposals/issues/7213