Imagine you are Valve or ID or Dice, and your team is going to create a new engine to run your company's main titles for the next decade. You want an engine that is innovative and flexible, can knock socks off next year and still impress gamers 5 years down the road.
Would someone in this position use helper libraries like GLUT aor GLFW or GLM or would they create their own libraries for their project and do the win API stuff manually?
It all depends. GLUT is ancient and irrelevant, but several other foundational libraries are perfectly viable as long as they're open source. The real issue nowadays is that graphics APIs are changing, platforms are coming and going, and professional studios need to be buffered against all of those changes. A math library needs to be flexibly ported to different CPU architectures with different SIMD instruction sets. Windowing libraries need to be expandable to handle platforms that may not even be publicly announced. You can't very well have MS come to you for an Xbox 4 demo and not be able to adapt to the platform.
For those reasons, these core libraries can act as very short term gains, but in the long view it's more beneficial to control the underpinnings yourself.
I don't think so. The open source libraries will usually not work for consoles, because those are using their own proprietary APIs. And the big studios can just put some coders onto implementing a platform specific API. I think it is also much easier than to worry about open source licenses. Plus in the end they will have a better customizable and optimizable solution.
Then there are also big well known helper libraries, which usually cost money, like Havoc physics, Simplygon, Fmod, etc... Big studios usually prefer these as they are not ambiguously licensed and well tested in a professional environment and come with support.
1 hour ago, NihilPointer said:Would someone in this position use helper libraries like GLUT aor GLFW or GLM or would they create their own libraries for their project and do the win API stuff manually?
Main problem of GL is library loader. Anything else very similar to DX. But it require a huge code to load a full set of functions. I has experimented with self-made loader. With safety-stubs for absent functions and extensions not supported by actual hardware, it require no less then 20k lines of code to implement. Fortuantely it can be done by parsing opengl extensions header file and generate required code by algo.
That's what I thought. I figured these libraries that every YouTube tutorial ever tells you to install before you can make your first rainbow colored triangle, are just convenience's and learning aids. Actually taking on a professional product is going to require a lot more customization and is probably a large reason many games from many developers tend to license well established engines like Unreal and Frostbite, and then go on to focus on content creation etc.
With that in mind, does anyone know of any good resources for learning how to interface with the OGL API directly through c++? Things like context creation through Win32 API or creating and compiling shaders without using those ever so convenient wrappers the toolkits provide?
3 minutes ago, NihilPointer said:With that in mind, does anyone know of any good resources for learning how to interface with the OGL API directly through c++? Things like context creation through Win32 API or creating and compiling shaders without using those ever so convenient wrappers the toolkits provide?
https://www.khronos.org/registry/OpenGL-Refpages/gl4/
Under windows it just require to cretae 1.1 context, get GL-specific loader proc (wglGetProcAddress under windows), that similar to GetProcAdress, and load required functions from driver. After obtain loader proc, that can be platform-specific, loading of functions works same for any platform. Really OGL 4.5 with extensions have over 5k functions with different signatures to load. Hardest part is to handle a set of pointers to functions, list of functions to load , stubs and warp-arounds with matching signatures.
