Raylib is a treat to work with and I highly recommend you try it out for some of your visual projects. Raylib: www.raylib.com/ All the raylib bindings: github.com/raysan5/raylib/blo...
I’m using Raylib-go and i love it. This framework gives you just the right amount of abstraction, so you have all of fundamental blocks of functionality for all basic aspects of the engine (that’s made very easy), yet you are not bound to the engine, you are free and productive
I've had some limited exposure to SDL couple years back and it felt ancient. No wonder there is such demand for a simple unifying API with bindings for a lot of languages that's also not older than you. Where else are these people supposed to go?
What I'd add to the library vs GUI engine is it really matters if you are working on the game solo, or if you need to collaborate with non-programmer artists. If you are collaborating with artists and level designers, the GUI is more for them than for you. Level designers need a "Halo Forge Mode," if you will.
There are a lot of design choices like this, and like the other commenter pointed out Ray is not going to change them. He has an overly stubborn and asinine view on LOTS of things, which is why I do not use Raylib. Its a solid idea, screwed up by one mans insistence on being retarded.
I've been messing with raylib for the past week and was excited when I realized how easy it was to load and render a 3d model. But as soon as I tried to add lighting I hit a brick wall and couldn't do it. The basic lighting example program works but when I add my own model it won't light it. So I dug into the code and it appears no less complicated than doing it straight in opengl. Perhaps even moreso because raylib is automatically assigning uniforms and it's a huge pain in the ass to figure out what the hell is going on or what is going wrong.
It uses the so called Star Engine, which, at this point, is basically a heavily modified version of Lumberyard which in itself was a heavily modified version of CryEngine.
that comparison with game engines isn't very apt. yes obviously something like raylib is awesome for getting into game engine programming without building absolutely everything from scratch, but if you set out to make an actual *game*, you're going to end up reimplementing the same patterns and abstractions present in pretty much every game engine ever in some shape or form. it doesn't really mean anything that it's "more familiar" to a non-videogame programmer, because making any game that holds up to any sort of modern standard (not talking about AAA, this applies to anything that sells as a game on steam for at least a dollar, or something you see made for a 48 hour game jam) will require you to learn how to program a *game*, which is something very complex and deep, which programmers with experience in other fields might see as very alien. so in any case, what you'll be doing will be unfamiliar. a proper game engine (i.e. Godot) allows you to only need to get familiarized with some basic abstractions like scenes and nodes (which typically exist in other engines with names such as rooms and entities), but not have to deal with any of the heavy lifting that requires months if not years of study like collision, lighting, shading, rendering, optimization, and so on. the programming itself is exactly the same, thus the barrier of entry ends up being far lower than if you had to code your own game from scratch.
raylib seemed all fine and dandy to me until I tried to add lighting to a test model then I couldn't get it to work. Looks like to get it to work I have to not only know how to do it from scratch in opengl but also figure out what raylib is doing automatically vs what it isn't, and where the data is going which is considerably difficult.
