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).
Related
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 would like to start learning OpenGL, to use it in software written in C++ language. The natural thing I do when attempting to learn something new is acquiring proper literature and online tutorials.
With OpenGL however, I got stuck. Different literature and tutorials that I have checked almost immediately mention terms, like :
Unofficial OpenGL SDK
GLSL
FreeGLUT
SFLW
GLEW
GLFW
others ...
Even though I checked the websites of these tools or wiki entries, I still don't understand things like : what are they actually with relation to OpenGL, why use one and not another, what do they have in common, what are the differences... And probably most importantly, how do I find what I ( don't ) need ?
So I would very much like to hear an explanation on this topic. Reference to a proper online reading is good as well. Thank you.
Open Graphics Library (OpenGL) is a cross-language, cross-platform application programming interface (API) for rendering 2D and 3D vector graphics. As such, it only provides means for drawing basic primitives (like points, lines, triangles), but no high-level functionality. Let's work through your list:
The "Unofficial OpenGL SDK"
This is just a collection of libraries offering some (more or less) often required functionality, like loading image files, or working with 3D objects, or helper libraries for creating and managing OpenGL contexts (it does include some of the other libraries you mention, we're coming to that.) I wouldn't recommend using that SDK as a beginner, but just learn the basics and carefully select the additional libraries you want to use.
OpenGL Shading Language (abbreviated: GLSL or GLslang), is a high-level shading language based on the syntax of the C programming language.
This is not a separate tool, but a central concept of modern OpenGL. You will need it to write your shaders (which are required in modern GL). That's something you definitively have to learn, but the compiler for this language comes with your GL implementation, so this is nothing you have to install separately.
FreeGLUT, GLFW, SFLM
As I already said, OpenGL is defined platform-independent. One still needs a platform-specific API to actually create the OpenGL contexts and "connect" them to the windows (or whatever "drawables" there are on the platform). OpenGL does not even have a concept of a "window", and as such, also no means for input event handling, detecting window resizes. These libraries implement wrappers for those platform-specific GL binding APIs and the window and event management, so you can just create a OpenGL context and a suitable window without having to care about all those platform-specific details. FreeGLUT and GLFW are quite focused on providing a simple framework for OpenGL development, while SFML is a more generic multimedia framework (also supporting things like audio output) and is capable of creating OpenGL contexts and windows. Other such libraries would be SDL (which is often used for games), or Qt which supports OpenGL widgets.
GLEW is short for "OpenGL extension wrangler".
This is a OpenGL loading library. OpenGL is an extensible
API. As such, features might or might not be present on the machine your application is executed. Furthermore, the way the OpenGL is defined on some platforms, only a certain set of functions is guaranteed to be exported by the libraries. If you need features of newer versions, you have to use the extension mechanism. This means that, instead of directly linking a function at link time, you have to query the function pointers at runtime to get access to those functions. To simplify that process, such loader libraries as GLEW do exist. With GLEW, all you need to do is call glewInit() and then you can use any GL function as you like (as long as it is supported by the implementation), forgetting about all those details of the extension mechanism.
What you really "need" of this list: GLSL, but that's not a tool. The other stuff is for convenience, but I highly recommend using some platform-independent window and context management library (GLFW is quite lightweight, but it is hard to tell what you will need. For learning OpenGL, GLFW is surely a good choice.) and also some GL loader like GLEW.
I've had much experience writing in Java, python, C#, and C, mostly for hobby. In all of the applications I've coded that involve displays (simulations, graphers, etc.), I've always just used the stock "Canvas" class of whatever framework I'm using (Swing Canvas, .NET Canvas, pygame once for python).
The downside of this is that all of these have slightly different paradigms in drawing.
I'm starting a project in C++ and was wondering what the best solution is for cross-platform drawing. OpenGL is obviously very low level, but some sort of library on top of OpenGL would be good. I've heard of/read about things like Cairo, SDL, etc., but don't yet know what to go with. I'm already using wxWidgets for interface, but would prefer to use something more standard instead of just a wxWidgets canvas. Obviously, the ability to draw lines and shapes is important, not just display pictures or whatnot.
Thanks for any direction!
I would consider using Qt, and notably its Graphics View framework. (Qt works on Linux, Windows, MacOSX).
SDL is SimpleMedia Direct Layer, which is basically a common interface to interface with the framebuffer and audio devices. If you wanted to create windows and such, it doesn't have general purpose constructs that work cross-platform.
Cairo is for drawing graphics, but still operates at a level that's lower than what WxWidgets provides.
C++ doesn't provide anything standard, so either you go with some platform specific, or you use a cross platform library like Qt (already mentioned by Basile) or stick with wxWidgets. Both are popular and widely used, though Qt is probably much more well-known and used (though that is just opinion). I've used Qt for work and it is very much cross platform and pretty easy to use (but very extensive, so prepare to read a lot of documentation). Luckily it also has a lot of documentation and many examples available.
Plus, both wxWidgets and Qt have bindings in many languages, so you could take the knowledge with either and use it with many other languages.
Open Frameworks is very easy to use and comes with a lot of examples...
it's platform independent and somehow reminds me of processing
I read something from here that said using GLUT is considered unprofessional. Swiftless has a fair amount of tutorials and I would consider him among NeHe as "go to OpenGL examples and tutorials". I have used GLUT in several languages in a few projects, though mostly for school projects. I find it very easy to make cross platform OpenGL apps with it.
Is using GLUT unprofessional? If so why?
GLUT is no longer under active development, that's one reason not to use it.
Another is that other wrappers (GLFW, SDL) are not only under active development, but generally more powerful.
Also the callback-oriented API of GLUT is usually not considered very usable. I mean, it works and it is certainly possible to use it, but both GLFW and SDL want you to write the main loop of your program yourself (SDL also has platform-independent yet explicit message handling) which, at least in my opinion, results in MUCH more clear and flexible code.
My conclusion: using some platform independent wrapper for OpenGL is certainly better than, say, WinAPI, but GLUT is probably not the best choice among the wrappers which are available.
No, it is not unprofessional. Use whatever is easiest and fits your requirements. I find freeglut better then glut (different license, and provides better flexibility), but it should be fairly easy to switch from glut to qt or sdl.
I can only argue for it being unprofessional on one point only: it may not be so portable to other platforms (such as Bada OS).