OpenGL certainly can be used without external helpers, which after all only wrap the native API calls. So just make the native API calls yourself.

With that said, and even for a Quake level of graphics complexity, I'd still advocating using a modern API like D3D11 instead of old OpenGL, because it's going to work better with “modern” hardware (and “modern” in this context means up to 12 years old!), it's just a much nicer API to work with, and it gives you flexibility to add “Easter egg” features should you wish to do so.

@juliean Much is opinion based and i won't comment. But the last OpenGL version is from 2018 (correction: 2017, sorry) and it is perfectly usable without a 3rd party loader by defining the datatypes and dynamically loading the library and the functions one needs into function pointers. I do it that way.

There is no need to use 1.4, it is ages old and does not run well on or even use the features of modern hardware.

Also, if one decides to use an api like glfw for window handling obatining an OpenGL context is seemless on windows just like on Linux. Basic core OpenGL 4.5 functionality runs smoothly on my PC with a GTX970 as well as on my notebook with intel hd 4400. One thing that won't work on the latter is an SRGB colour framebuffer attachment. No problem.

(Looks like i have been ninja'd :-))

21st Century Moose said:
OpenGL certainly can be used without external helpers, which after all only wrap the native API calls. So just make the native API calls yourself.

Green_Baron said:
@juliean Much is opinion based and i won't comment. But the last OpenGL version is from 2018 and it is perfectly usable without a 3rd party loader by defining the datatypes and dynamically loading the library and the functions one needs into function pointers. I do it that way.

Well, ok, technically you are correct. But does it really matter for this threat? If I have to define the headers for using an API, load the calls into function pointers etc… thats not a trivial task that you can expect anybody without higher levels of experience in the API to do, don't you? :D

So I should have probably said something along the lines of that you can't realistically use OpenGL 1.4 without external helpers without increasing the complexity of the task considerably, which I wouldn't recommend OP do. Better?

Nope :-)

OpenGL 1.4 is not a thing since a long time. Using it is self-castigation :-). Have a look at OpenGL 4.5/4.6.

Opinion: a function pointer is a very basic C functionality and doesn't require higher skill levels to use. Function pointers are used all over the C/C++ languages' standard or template libraries, where they are often used without noticing (example sorting).

More opinion about D3D: The D3D i looked at (9) worked with macros where it could. Macros everywhere. Terrible for debugging.

This is all opinion based, beautiful projects are made with OpenGL as well as D3Dwhatever :-)

Green_Baron said:
Opinion: a function pointer is a very basic C functionality and doesn't require higher skill levels to use. Function pointers are used all over the C/C++ languages' standard or template libraries, where they are often used without noticing (example sorting).

Sure, a function pointer is a trivial thing. Having to know/figure out all the functions/types you need, and getting everything right is not basic or trivial at all. There's a reason libraries like GLEW and GLUT exist. Its pretty much like I wouldn't recommend a beginner to use raw Win-API for window handling over some library like SFML (even though I personally do the former).

Green_Baron said:
More opinion about D3D: The D3D i looked at (9) worked with macros where it could. Macros everywhere. Terrible for debugging.

Yeah, D3D9 is pretty much on the level of early GL. DX11 is an entirely different API, and I base my opinions solely on that. Even though I would probably give D3D9 a little edge over GL, mainly for the fact that that its error-reporting was still better, and a little easier to mess up the resource-bindings.

Green_Baron said:
This is all opinion based, beautiful projects are made with OpenGL as well as D3Dwhatever :-)

That goes without saying, what I care more is how long it took/would have taken, and factors like maintainability etc… without saying too much, I just wanna point to “lugaru” (https://www.gamedev.net/forums/topic/649121-unmaintainable-code/) which was a successful indie title and certainly impressive, until you look at the code an realise it could have been realised with much less pain ?

The functions are documented. (but i cheated and copied the definitions out of glad, but hush, don't tell anybody !).

Well, taking the D3D11 zoo as a reference we should be so sporty and compare it to OpenGL 4.2 and later, just like D3D12 and Vulkan are often compared (which I cannot judge). 4.5 offers direct state access, which I find nice for integration in oop, raii and all that. But i don't know D3D11, so i cannot compare.

Whatever, everybody must find their way. I only hope that Vulkan in its current state of flux is not the last word. For a hobbyist like me it is a mess.

Direct3D has always been a more-explicit, DSA-based API. DSA in GL 4.5 is just OpenGL picking up something D3D has always had.

Green_Baron said:
Well, taking the D3D11 zoo as a reference we should be so sporty and compare it to OpenGL 4.2 and later, just like D3D12 and Vulkan are often compared (which I cannot judge). 4.5 offers direct state access, which I find nice for integration in oop, raii and all that. But i don't know D3D11, so i cannot compare.

I only compared those version based on what @21st century moose suggested ? I didn't mean to be intelectually dishonest. Though my own judgement of GL is based on 4.5 and later, which I used when I wrote my back-
end for my engine. Might have missed something major though, as the general API didn't seem that much improved (still depending on integers for resouce-bindings etc…).

Green_Baron said:
Whatever, everybody must find their way. I only hope that Vulkan in its current state of flux is not the last word. For a hobbyist like me it is a mess.

Thats something I can totally agree on! Whether its Vulkan or DX12, I also hope that there will be another direct replacement for DX11/OpenGL that is not as complicated as those new hardware-centric APIs.

I've actually played a bit with OpenGL and GLFW. I drew a small scene with a few texture mapped cubes without lighting, and moved around it with a camera. The code was a bit messy and probably poorly optimized, but I did get somewhere. I got started with DX11 but haven't had much time lately to get very far. I set up a win32 window and a backbuffer and not much else. As far as that goes, it was a lot more complicated than just calling glfwCreateWindow(). I'm hoping it'll become less cluttered compared to GL as I get into actual graphics programming.

Before, I played around with OpenGL 2 using the fixed function pipeline, as well as OpenGL 3 using shaders. Shaders seem to make things a lot more complicated, at least starting out. There's a lot more theory to remember, more syntax, and more that needs to be organized in my code - all for what appears to be the same end result. I understand the flexibility that shaders add, but I have a few more questions:

• Will the modern pipeline offer a performance boost over the fixed function pipeline when I'm going for Quake 1 complexity graphics (simple baked lighting, diffuse textures only, no real time shadows, etc)?
• At what point will Direct3D be easier than OpenGL? I've heard from most sources that it is, but what makes it easier? So far it all I can think of is that HLSL may have some support in Visual Studio while GLSL does not.

Debugging GLSL is definitely a thing i miss, GLSL does not communicate so easily with the application on the CPU. So I have written and tested some functionality in the application before moving it down to the shader. There are a few libraries/helpers that provide some functionality (can be searched), but i think that round clearly goes to D3D. If you don't need platform independence …