I know that c++ has no NATIVE graphics support. Neither does Python, or C, or anything of the sort (as far as I know). So here's the question... Take the game Doom for example, (this game was coded in C) how in the world does that game have graphics if it was made in C? How are graphic engines like Unity or UnReal or openGL even made? Are they coded in pure ASM? with re-coded systems for different platforms? That seems extremely tedious to me... So say if you are a programmer like me, who doesn't like using code that other people have created- I swear don't yell at me for that- and you want to make a simple app with a simple GUI? How in the WORLD do you do that? Do you have to write ASM code and incorporate it with your c++/ python? And if that's the case, do you have to re-code that ASM in the native ASM language for all of the different platforms? Any help is appreciated!

Almost nobody writes assembly by hand these days; it's usually C, with a tiny amount of assembly deep in the guts of the operating system. But you're not too far off.

Operating systems generally provide some low-level API for graphics, using similar machinery to how you might do things like access files. On (recent) Windows for instance, this API is WDDM which spans from the libraries that can be loaded by a program through to the kernel-mode display driver that knows how to talk to your specific GPU.

On Windows, the kernel ABI is deliberately hidden- you always communicate with the system via loaded DLLs, and graphics APIs are the same. To use Direct3D 11 for instance, you'd link against d3d11.dll (and probably others), using the functions exported by that DLL.

So it's basically impossible to not use libraries; you could theoretically write your own display driver and everything in between, but that's nearly impossible without being the manufacturer of the GPU because they're such complex machines.

---

The story is similar for other operating systems, but they'd use different APIs. Something like OpenGL is yet another API that can be translated into whatever the operating system's native graphics API is, so generally speaking writing a cross-platform program with OpenGL is not much more complex than recompiling the program for another system. The tricky part is ensuring everything you use is portable in the same way.

So Windows incorporates a library with preset ASM that communicates with the GPU? So it IS a feature of windows? Because only they can make it because only they know the info necessary to create it. Is this correct?

C code that runs with system privileges can theoretically access the hardware and memory needed to perform functions on the GPU (disregarding performance and special CPU feature issues that might make use of ASM more appropriate), but in a modern OS it needs to be loaded as a privileged device driver or whatever. These days, this is normally made by the vendor of the graphics card or GPU. Windows then builds on this and provides an interface for nonprivileged application programs to access graphics and GUI functions, since they are not allowed by the OS to interact with the graphics hardware directly (otherwise there would be no way for the OS to coordinate multiple programs running at once and prevent them from trampling one another).

Toolkits like Qt are frequently used as a convenient means to make programs that can be compiled for Windows as well as other platforms like Mac and Linux. It provides its own interface that it then translates to the underlying OS functions for whatever OS the user is running the application on.