I'm currently thinking about handling the OpenGL context recreation.
But for now there is some bugs. Some of my objects fails to be reloaded and sometimes the engine simply crash.
I use GLFW library for OpenGL context creation and GL3W for the extensions loader.
My question is quite simple: should I consider to call gl3wInit() again when I'm rebuilding the context ?
Yes, you might need to call it again.
I heard that at least on Windows, GL function pointers could be context-specific. If you make a new context, you need to obtain new function pointers (which is what gl3wInit() does).
Related
I'm rewriting my rendering library, and greatly enjoy how glTexStorage2D() works, as well as glBufferStorage(). They're wonderful, allocating the space and defining the object in an immutable way, which works very well with the interface I designed.
However, I just learned it is an OpenGL 4.2 feature. I'm targeting OpenGL 3.3 (I think?) but hoping for a way to avoid glTexImage2D() which uses mutable storage that has proven difficult to use safely.
Also... I'm gravely unfamiliar with how OpenGL's version system works, or what it even means to "target" one version over the other...
Is it as simple as just, this functionality is unavailable to me below 4.2 and that's that? Or are there alternative functions I could use? Or if I attempt to just create a 4.5 OpenGL context (the latest version I know of), would the OpenGL driver be required to emulate any features it doesn't have access to on the GPU? Or is that not even remotely how any of that works? I have very little knowledge about it, so maybe this all sounds foolish.
I just really like some of the newer OpenGL 4.x features like immutable storage and tessellation shaders, but don't want to exclude too many people from running my programs. Would I have to implement an alternative texture allocation method using glTexImage() if a platform isn't capable of running OpenGL 4.2?
I am relatively new to graphic programming so I wanted to start from the very basic. I see there is library like PyOpenGl which provides binding to the opengl api itself. Now, I really want to create things like PyOpenGl on my own so I can understand how everything work in the process.
Is it possible for me to creates library like PyOpenGl or GLFW? If so please give me some general tips of what should I do.
If not please explain to me why I can't create my own binding and I do apologize if my question above sounds absurd.
PyOpenGL is a fairly thin wrapper that, for the most part, simply turns Python function calls into calls of native machine code functions of the same name. There are a few little details like calling conventions in the mix, but these are actually boring stuff. The fact is that (as far as OpenGL is concerned) the source code you write in Python with PyOpenGL looks almost identical to the source code you'd write in C. There are a few "smart" things PyOpenGL does, like providing means to interface NumPy arrays to OpenGL calls that take a data pointer parameter, but that's just house keeping.
And when you do OpenGL calls in C or – even more extreme – assembly language (perfectly possible) that's the lowest level you can go (with OpenGL), short of writing your own GPU device driver. And writing a GPU device driver is super hard work; it takes literally millions of lines of C code (NVidia's OpenGL implementation is said to consist of about ~40M LoC, there are open source drivers for AMD and Intel GPUs, and each of them have MLoC, too).
If you're interested in some middle ground, have a look at the Vulkan API. If writing higher level wrappers for graphics is your thing I'd suggest you implement some higher level API / renderer for Vulkan and interface it to Python. This is likely to be much more rewarding, as a learning experience (IMHO).
The OpenGL API lives in the driver for the graphics card. All OpenGL functions are there. You only need to know how to get them. As Spektre said, the proccess is:
Create an OpenGL context. This is a job for the OS. Each OS has its
way and its issues. Read https://www.khronos.org/opengl/wiki/Load_OpenGL_Functions
Define function pointers as glext.h does and then extract them from
the driver. Apart from standard OpenGL funcs, vendors add their own
ones, called "extensions". You can see how GLEW does this job. If you want to set all functions and extensions then make a script that uses glext.h because there are about one thousand of them.
You can download glext.h from https://www.opengl.org/registry/
Doing something like GLFW requires, added to the previous two points, knowing how to create a window and handle its messages for keyboard and mouse. Again this is OS dependant. On Windows there is a way. On Linux it depends on the window manager used, GTK+ for example. Or X11 directly. Or...
Anyhow my best advise is that you can read how GLEW and GLFW did, looking into their code. BUT don't lose much time on it. Prefer getting experience on OpenGL and let those "diggins" for later time.
I've checked numerous posts and tutorial about using OpenGL and C++. There is one thing that still bothers me. In each tutorial you have some additional library like GLFW, GLU, GLUT, WIN32 and so on (mostly used for window creation). Although I was unable to find some tutorial using only OpenGL. The only clue is this answer syaing that you need to use some library for this.
Can someone explain how it really is? How it looks when I want to use code on different operating systems? Is application code written with OpenGL 100% portable?
You can't have a tutorial which uses only OpenGL just because it's an API which doesn't provide such functionality.
OpenGL is not meant to create a graphical context in an operating system and use it, it is meant only to work directly with the GPU through a set of defined functions.
So the main point is that what you are asking resides outside the purpose of OpenGL, which defines just a standard interface to graphical operations.
But many more or less complete libraries exist to handle this problem and you also quoted some, for example GLFW or SDL, which takes care of initializing the context and manage also additional issues (for example controls or sounds).
The product will be portable if a set of constraints is respected:
you are using a library which manages different OS for handling the graphical context (eg GLFW)
you are using an OpenGL profile which is supported by all the GPUs you mean to make your code work on
in case of portability between OpenGL and OpenGL ES you must ensure additional constraints since the latter managed certain things differently
I'm currently in the process of writing a game engine which is about to go through a major rewrite. First off, I'm considering what library to use in conjunction with the engine. Obviously, I'm going with OpenGL here and am going to do what I can to make it forward as well as backward compatible.
The main issue, though, is that from most of my research, I've found that great libraries like SDL (except for 1.3 - which, I don't believe is stable? I may be wrong about this) only support up to OpenGL 3 and not 4.2. FreeGlut, however, does support the latest and greatest, and seems like a good way to go for the basics of an engine.
The only thing, however, is setting up something such as Keyboard I/O and sound input audio, along with other things. Thus, I'm considering to see whether or not it's possible to use glut to initialize opengl and use opengl with it, and then have SDL do window management along with keyboard I/O, sound, etc.
Of course, there's always the option of using Qt with OpenGL, but I'd like to definitely have control over my main loop if possible (is this possible with Qt and OpenGL?).
I've heard of SFML, too, but ultimately I'd like to stick with libraries written in C as I plan to write a C library to take care of most of the primitive rendering (for the sake of pure speed and memory management, procedurally).
Thus, I'm at a loss as what to do here. IS Qt a good choice for this, or is there another C-like alternative (such as FreeGlut) which allows main-loop control (like SDL) and offers the necessary customization I'm looking for?
The main issue, though, is that from most of my research, I've found that great libraries like SDL (except for 1.3 - which, I don't believe is stable? I may be wrong about this) only support up to OpenGL 3 and not 4.2. FreeGlut, however, does support the latest and greatest, and seems like a good way to go for the basics of an engine.
Your research is lacking.
First, FreeGLUT should never be used for anything that you would call an "engine". Whatever you mean by that, FreeGLUT is not the tool for the job. It's designed for creating demos, which is why it owns the main loop. I understand that FreeGLUT does have a way to allow you some control over the main loop, but the standard way to use FreeGLUT doesn't do that.
Second, you are correct that SDL 1.2 is not capable of creating an OpenGL 3.2+ core context. However, you don't have to be able to create a core context to use GL 3.2+; compatibility contexts work just fine at those versions. The only platform that has no compatibility context is MacOSX's 3.2 support. So I wouldn't worry about it.
You could try GLFW. It's sort of like FreeGLUT only more game-centric. It gives you control of the render loop and so forth. It provides better input handling than FreeGLUT, as well as some light image loading functions (only TGA files). It even has a threading API (though I wouldn't suggest using these functions. GLFW 2.0 will drop them since both C++11 and C11 have native thread APIs).
However, it has no systems in place for audio.
I've heard of SFML, too, but ultimately I'd like to stick with libraries written in C as I plan to write a C library to take care of most of the primitive rendering (for the sake of pure speed and memory management, procedurally).
I'm going to ignore the fallacy about C++ not having the "pure speed and memory management;" that's a common canard that I'll ignore. The important point is this: SFML, as far as your rendering code is concerned, exists solely to create and manage the window. Your rendering code doesn't even have to talk to it. You call some SFML functions, create a couple of SFML objects, and your "C library" OpenGL code won't even have to know those C++ objects are there.
However, if you absolutely cannot work in C++ at all, you can always use Allegro version 5. It has a C API, and it provides support for OpenGL core contexts, input, audio, and most of what SFML does. It also has pretty decent documentation, and is modular (though in a different way from SFML).
I want to design & implement a simple windowing & widget for OpenGL running on top of SDL, much like Agar or GiGi, only much closer tied to SDL & OpenGL.
My general problem is this: what is the best design for a windowing system within an OpenGL context??
I want to have windows just for controls, and, if even possible, threaded windows with their own OpenGL contexts. The only way I've though about it even being possible is rendering to textures, and them adding window decoration around those...
I want to expose the workings to other programmers, but which way would be best. I am more of a C++ programmer and so inheritance was the first way I thought of. Make basic classes which I expose in a shared header file, the programmer then derives their own window object from that, overriding the Init() or Run() methods to implement what they need. The problem with this approach would be keeping the programmers in check, there would be no real way to 'keep' them from simply drawing wherever they want in the OpenGL screen.
Another possible way would be functors, passing the functors the programmer wants to use into the library which then calls it once it's finished rendering it's GUI components and what-not.
What is the best way of approaching any of this??
windows with their own OpenGL contexts
That's going to require hacking SDL, since it only provides one context per process. Unless you're thinking of doing a single GL context with multiple independent sub-viewports rendered in sequence.