Plenty of studios still roll their own engines and tools (e.g. Thekla, Croteam, Frictional Games, ...) and they had good reasons to do so. For example here's Jonathan Blow talking about one of the reasons he chose to write The Witness from scratch:

Quote

I don't have any desire to use a different engine for many reasons, and it's unclear which are the most important reasons, so let's start with the least usual one. Which is: when I'm making these games, they're not just commercial products. They're expressive works that we're working very hard to make, and we want them to have as long of a lifetime as possible. So I would like this game to be relevant 20 years from now, 40 years from now. How do you do that? Well, you don't necessarily do that by building it on top of a very complicated system, that you don't own, that somebody else will cease to support at some point in the future. Once future consoles happen or current PC operating systems no longer work, we at least have the source code to the whole system so we can make it work in the future. If Unity ceases to support something in the future, you basically have to rewrite it on a different system, and depending on how much of your gameplay depends on the core of how that worked, it may be very difficult or impossible to reproduce the same thing."

I also quite like this blog post by Jeff Preshing:
http://preshing.com/20171218/how-to-write-your-own-cpp-game-engine/

As for Handmade Hero, here's a good video of Casey explaining his reasoning behind it:
https://www.youtube.com/watch?v=fQeqsn7JJWA

Personally I like to write everything from scratch in C because I just love low-level programming, but of course it's not for everyone. It also takes a long time to get an actual game done so doing as MonterMan says and using a couple of libraries is a good middle ground.

17 hours ago, MonterMan said:

Raylib seems solid.

My suggestion is to use an composite of small libraries that deal with different stuff. For example, you can use bullet for physics and collision, cute_sound for audio stuff; that way, if you feel like rolling out your own renderer, nothing is holding you back since all your game engine components are separated libs. You aren't tied down by a heavy lib that does it all, because a heavy lib that does it all tend to be more of a "control freak" than lightweight libs. This way, you have retained the "control" in your own hands. Just make sure you are in control of your code, and not the other way around. 

I am not sure if Raylib is one of those, but better make sure it isn't before you've decided to use it  

(EDIT: I was simply enumerating the possible library you can use, I wasn't actually recommending them (namely bullet and cute_sound). Not saying they are bad or anything; I haven't used them so I can't speak for them.)

That's a solid advice. Personally I don't like dependencies, and that's why I dislike Java and JS projects so much, but that's a bigger factor if your dependency has other dependencies and it becomes a snowball.
I may try that at some point, but I think I will stick with raylib for the first one.

15 hours ago, D956 said:

Plenty of studios still roll their own engines and tools (e.g. Thekla, Croteam, Frictional Games, ...) and they had good reasons to do so. For example here's Jonathan Blow talking about one of the reasons he chose to write The Witness from scratch:

I also quite like this blog post by Jeff Preshing:
http://preshing.com/20171218/how-to-write-your-own-cpp-game-engine/

As for Handmade Hero, here's a good video of Casey explaining his reasoning behind it:
https://www.youtube.com/watch?v=fQeqsn7JJWA

Personally I like to write everything from scratch in C because I just love low-level programming, but of course it's not for everyone. It also takes a long time to get an actual game done so doing as MonterMan says and using a couple of libraries is a good middle ground.

 

I think I'm convinced that I want to learn to do it or at least learn sufficient to know if I want to do from scratch or not. I'ld never knows if a try it.
So I'll continue following HMH and using something middle ground at the same time.

4 hours ago, Promit said:

cracks knuckles

Alright, let's talk seriously about what it means to roll your own. For context, I've worked at Microsoft and had access to the Windows source code. I've worked at NVIDIA and had access to the D3D driver source code. I'm software architect of a group which has a completely C++ tech stack which is essentially custom, save a few helper libraries that are part of it. I say this only to provide some context for where I'm coming from - rolling your own is a very familiar world to me. I'm going to ignore Casey/HMH from here on out because I don't care enough about him to say more on that subject.

That's great. Do you have time to do both? More on that in a moment.

I'm a little concerned that you don't actually know what you are trying to accomplish here.

In general, there are two ways to come at building games. You can start with something very high level and learn all about how to structure the high level structures of a game, filling in low level knowledge over time. Or you can start very low level with the individual pieces, eventually figuring out how to connect them into a working whole. Both are perfectly valid approaches, but it's very difficult to accomplish both missions simultaneously. The people we're talking about in this thread have many years of professional experience under their belts, and are usually doing this in their spare time too. 

You can choose to roll your own tech, as we did, and it can pay dividends long term. But that choice will kick your actual game back by years, especially if you're still learning the fundamentals as you do it. Witness was mentioned above - that game took eight years and an ultimate team of 15 people to create. So it becomes necessary to decide what your priorities are, because we're no longer talking about short term gratification. You've demurred on that choice so far, though I like @MonterMan's comment on integrating outside libraries, particularly open source ones. I don't like the concept that some stick to of not having dependencies, because that's not reality. You always have dependencies, you're just choosing not to acknowledge them. The OS and platform SDK, the graphics API and drivers, the C++ runtime, etc. I just include the dependencies in the source tree whenever possible, rather than doing package manager stuff.

At the end of the day, you're going to have to decide that you're writing some part of the system yourself, and some part just already exists there for you and functions in its own mysterious ways. There are many places to draw that line, but you should have a good understanding of why you placed it where you did and what the goals are. No matter what you choose, some things are going to be closer and some things are going to be farther away. It will take a long time to have both the low level and high level under your belt - and I have to mention that very few professional game developers ever do that. Most inhabit just one section of that world, relying on the rest of the team to build a complete product.

I may have sounded a little ambicious, and I really am. 
I'm a little bit disappointed that you don't think HMH is a valid topic to discuss, but I may understand that in the future - I'll not know now. Seems a valid school of thought, even though most people seem to dislike the whole "compression oriented programming" idea.

Anyway...
Well, as I said, I've actually developed 5 games in Unity already, and a small one in Unreal (this one VR), so I'm not a total noob. I'm a noob in the low-level field, however.
I may be extrapolating things and trying to go too far. That would not be the first time. But hey, that's why I'm here asking for advice instead of just doing it.
What is clear to me is that I need to learn more, to know what I should try to do and what I should not, and to know what is worth doing and what is not.

You gave me good suggestions in your last post, but I should say I'ld prefer to try some C/C++ this time.
Suggestions are still welcome.

If you want low level, try Vulkan. 900 lines for a triangle.

Next up the chain is OpenGL, DirectX, etc... Both take lots of setup and learning to use by themselves.

Next up is Allegro, SDL, SFML, etc.... They provide an easy interface to use OpenGL and DirectX as well as lots of different niceties. I wouldn't suggest going any lower level than this.

Above that are Engines and Frameworks like you've been using. Ogre3D, Unity, UE, etc.... These are high level libraries with specific pros and cons I'm not familiar with. You've already gone this route, and you want to learn more, so I would suggest moving down a level. Libraries like SDL, Allegro, SFML, etc... let you use OpenGL and DirectX alongside your application, so you can learn it as slowly or as quickly as you like. Studying these libraries can also give you good ideas on how to implement lower level programming. This is what I would recommend.

I recommend you try out binary example programs from each library you are considering. I provide binaries with examples, demos, and tests included for Allegro 4 and 5 and you can find them here : Allegro Lives! Try it today!

EDIT

Actually, I should also mention things like GLEW and GLUT, which give you quick and easy ways to get going with OpenGL, but I think ultimately they will limit what you can do.