Share the source code. :@

I'll include it with the games I make with it, when it's done, under CC BY-NC 2.0, or something like that for software. Right now you could make something similar by following the LunarG Vulkan tutorial, although this is 7k lines and does a ton of extra work :0

alternative answers:
carmack
talent

cool shit mang!

The answer would be emotionally stable community and american winners

pls make a thorough tutorial video for this

I don't think that it's worth making a through tutorial for an incomplete engine like this, but i'll tell you how it works:

Study the code here to understand how to use the Window Manager of your Operating System, if you have something weird that doesn't use it look up their documentation:
http://nehe.gamedev.net/tutorial/creating_an_opengl_window_(win32)/13001/
http://www.winprog.org/tutorial/
https://www.khronos.org/opengl/wiki/Programmi...X_and_Xlib

Then, learn the graphics API, I used the LunarG Vulkan Tutorial, and Vulkan-Tutorial.com to learn Vulkan, and for OpenGL I mostly looked at NeHe. Thats:
http://nehe.gamedev.net/
https://vulkan-tutorial.com/
https://vulkan.lunarg.com/doc/sdk/1.0.26.0/linux/tutorial.html

Now, I don't need references to write Win32 or OpenGL code anymore, I know it by now. And the rest of the code isn't in a tutorial, so I can explain it: The way the graphics work is that I keep feeding a linked list of all the objects put onto the vertex buffer memory on the graphics card, also when I say objects, I don't mean OOP, I am writing it all in C and not C++. So, I have a whole thing that guarantees that memory isn't being leaked. So, for drawing text on the screen I precompute all of the necessary verticies and texture coords before pushing this into the VBO memory, then when the program has started up and is ready to render things, it's really fast to just tell the driver to render "Vertex Buffer Object #17", and then I get my text. Obviously I need to rebuild this every time you type, but that's a rare case (one letter a second is just one frame out of 60, whatever). Now, then I parse the input using "sscanf", which isn't that great to use but I check all the errors so whatever. Then I use a hash table, which you should know how to do, to equate the thing you typed with an actual console command. And then I do the thing, which is usually like logging console variables, which, the program will actually access this hash table to initialize itself, and check on it to do other stuff, so it's a centralized way of configuring the program behavior instead of something like "#define SYS_WINDOW_WIDTH 640" (actually, I ask the OS what video modes play nice with the monitor, so if you change monitors you will get a whole other set of resolution options. That's kind of a bother but it ALSO happens to mean that in the year 2070 when we all use 16k monitors, this game will support it with absolutely no problems. ) The OpenGL fallback renderer on this thing will actually work fine on my linux laptop's terrible, terrible OpenGL driver with no extensions, i'm pretty sure it was just OpenGL 1.1. I do use extensions though, because that's a good idea. You should also look up the articles on here: http://fabiensanglard.net/ for ideas about how to write giant programs that are coherent and not a giant mess. I'll probably make some kind of video explaining all this when I finish.