Is there not a simple sdk for opengl why there are glut or glew and what are the written using? Which one should I use? There are so many frameworks out there that it is so confusing? Why there isn't just one sdk for opengl?
why there are glut or glew and what are the written using?
GLUT, GLFW and similar frameworks exist, because the system level interfaces to create a window and a OpenGL context are extremely versatile in what they can do, but it also takes a lot of code, just to create a window and them some more to create the OpenGL context. …and then some lots more of code to also do things like UI event management and so on.
These system level APIs are that verbose, because on a system level, you don't want to pin down what you can and can not do with these APIs.
So the three calls
glutInitDisplayMode(…);
glutCreateWindow(…);
glutMainLoop();
encapsulate about 1.5k lines of code dealing with just the system. But then with GLUT you don't get nice buttons, menu bars and the likes. For that you'd use a different framework, like Qt, which has even more code, but uses the same system level APIs as GLUT does. Same goes for GLFW and so on.
GLEW we have, because OpenGL can be extended and the system level interface for extending it is again down for minimalism and flexibility.
Why there isn't just one sdk for opengl?
Because in the end OpenGL is a system level API and the "SDK" comes ready-to-use with your regular system default compiler.
If you want to, you can create OpenGL programs without GLEW, GLUT and so on. But it is tedious.
Related
I was watching this video about OpenGL 3 - https://www.youtube.com/watch?v=XMgfddy7S7Q
And while talking about libraries to work with OpenGL (at 3:00) he mentions GLFW, freeGLUT and GLUT to use to create the window.
But can they handle input and sound as well like SDL?
And if so should I be using SDL? Or is GLFW more tuned for making games specifically in OpenGL?
No, GLUT and GLFW are frameworks that manage OpenGL context creation and windowing (which includes input) mostly. GLUT has a few components that are actually designed to draw things, but by in large it is there to setup GL only.
SDL, on the other hand, includes sound which neither GLFW nor GLUT do but also includes utilities to load resources such as image files. It is a much more end-to-end solution, whereas GLFW and GLUT are only designed to facilitate rendering/windowing. To do the same thing using GLFW, you would need to throw in some libraries such as SOIL (or work directly with libpng, libjpeg, etc.) and also find an audio library.
You do not need any of these things to make a game in truth. I interact directly with OpenGL (WGL/GLX/CGL) on Windows, Linux and OS X in my work but the extra time necessary to debug and maintain each of these platforms at such a direct level can be a real nuisance. If writing extra code specific to each platform you run on is unappealing then you should definitely consider GLFW, etc.
I've recently started learning OpenGL (> 3.3) & I've noticed a lot of examples & tutorials use both freeglut & glew, but don't really explain the difference at all. The best description I've found, after googling & reading ad nauseum, has been this OpenGL Related toolkits and APIs but found it lacking. I've even read the tag info on SO.
As someone really new to OpenGL I'm still trying to get a grasp of the different concepts. I've gotten to the stage of creating a basic program that uses glew, create context (on windows, VS2010), & draw really basic shapes, all without the need for explicitly including freeglut. So I don't understand why I would need it.
So my question then is, what's the difference between:
-freeglut
-glew
-(& glfw)
What can one do that the other can't?
The OpenGL Extension Wrangler (GLEW) is used to access the modern OpenGL API functions(version 3.2 up to latest version).If we use an ancient version of OpenGL then we can access the OpenGL functions simply including as #include <GL/gl.h>.But in modern OpenGL, the API functions are determined at run time, not compile time. GLEW will handle the run time loading of the OpenGL API.About GLEW see here
GLFW or freeglut will allow us to create a window, and receive mouse and keyboard input in a cross-platform way. OpenGL does not handle window creation or input, so we have to use these library for handling window, keyboard, mouse, joysticks, input and other purpose.
GLFW and freeglut are alternative for us according to our need we can choose any one but GLEW is different from them which is used for run time loading of the OpenGL API.
I'm using both of them for some work at my university.
GLEW is a "cross-platform open-source C/C++ extension loading library" (from its website), while freeglut is a window manager that replaces the default OpenGL Utility Toolkit (GLUT) library.
So, as you see, both different have different purposes. The point of using freeglut is that it's still maintained, while the default GLUT isn't, so if you want bug fixes and new features you should use it :)
GLUT is a very old framework for OpenGL, and there seems to be a lot of negative attitude towards it. I hear SDL is an alternative, though to my understanding it does not handle the 3d component of OpenGL. What is a good option (which preferably has good documentation so it is easily learnable) that can do what GLUT does and provide more functionality, eg. to make a complete 3d game? I prefer not to use pre-made game engines, I'd much rather build my own code from scratch.
orginal GLUT is very old and I would not recommend it. But the new version of it: http://freeglut.sourceforge.net/ is quite interesting framework. Is is as simple as GLUT but adds more features: mouse scroll, new geometry objects, etc, etc.
last version of this library is from January 2012
here is a useful link with several frameworks for opengl: http://www.opengl.org/resources/libraries/windowtoolkits/
If you want to make w "whole" project I suggest combining more libraries:
http://www.opengl.org/wiki/Related_toolkits_and_APIs#Context.2FWindow_Toolkits
http://glsdk.sourceforge.net/docs/html/index.html
SOIL for texture loading
If you are to use modern OpenGL GLFW is the best option out there to manage context, window creation, user input. The lib is very active with constant new releases.
Just wanted to add that my consideration to move from GLUT and from FREEGLUT was the lack of ability to define color, stencil, depth bits and MSAA samples for created context. GLFW allows you doing this.
SDL can create windows with OpenGL context (see the SDL_WINDOW_OPENGL window flag), so you can use the OpenGL functions. So can SFML, and probably Allegro too.
I personally recommend SFML, especially version 2 (which is in development), as I find it very easy to set-up and start using, both generally and for OpenGL.
Anyone can tell me what's the relationship between SDL library and OpenGL library?
OpenGL is a graphics library that doesn't provide any feature in addition to drawing. It is neither able to embed an OpenGL view inside a window of any modern OS.
That's where SDL comes right into place and provides all the required functions needed to create an OpenGL window in a cross-platform manner in which you then draw by using OpenGL library itself. SDL also has a lot of facilities that are almost always necessary when working with games or graphical applications like timers, management of keyboard and mouse and whatever.
In any case you could use any other OpenGL wrapper like GLUT library or GLFW to achieve the same thing: creating an OpenGL view inside an application.
I am looking for the ability to open OpenGL contexts and draw native OpenGL in windows, macOS, linux distros with X, android and iOS
I don't want to rely on the "native" device framework for the actual UI, I don't need to use native components, all I want is an OpenGL context to natively draw in OpenGL. Many of the cross platform SDKs like Marmalade and MoSync focus on making use of the native UI components and stuff like that, all I need is an OpenGl context to draw as I intend to, absolutely no native UI functionality is required, however, access to native hardware features like microphone, camera and other sensors is desired if possible, as well as access to audio/video/network.
I don't want to use QT, I want to do something that is closer to the hardware to work on the low level. The general idea is to make a lightweight cross platform hardware accelerated GUI, written on a level low enough to be truly hardware native, without relying on any native software framework. I know for android I may have to use a java wrapper to launch the native code, but the idea is to have this wrapper minimized, with very little modifications needed to deploy the low level and thus hopefully TRULY cross-platform code, that is only dependent on OpenGL hardware and OpenGL context for it to work wit.h
So I need a bare minimum solution to avoid using non-cross platform features as much as possible.
At the time the only library that comes to my mind is SDL, but I am not sure it supports android and iOS property, so besides library recommendations, more information on how SDL handles android and iOS devices and their hardware is welcomed too.
How about:
GLFW
SDL
GLUT (FreeGLUT or OpenGLUT)
Blender's GHOST framework?
Essentially they open a window, create a OpenGL context on it, deliver you the input events and leave the rest up to you.
What you want is nothing more than a platform-specific OpenGL context setup (which is quite simple and well documented: the NeHe OpenGL tutorial provides code for many environments that does just this here (the explanation is Windows specific, scroll down for the code on different OSes).
Once you have the OpenGL context, nothing prevents you from creating a full GUI with all OpenGL elements.
If you want, you could use Qt to only set up an OpenGL context (ie don't use any QWidgets or anything, other than the window showing you your OpenGL scene). It takes care of the whole setup process, but for only that, Qt becomes a huge dependency, as it only really replaces at most 100 lines of code per platform.
With regards to SDL+Android, have you checked the README?
And for iOS check the same file here.