I'd like to use certain functions of openGL, but nothing related to rendering visual content. Is there way to create it without ANY dependencies (not to windows, nor some package[SDL, SFML, GLUT])? Only libraries allowed are those without external libraries, just like GLEW which I use.
What you want to do is known in general as off-screen rendering. In theory it is possible perfectly well, however the practical implementation has a lot of caveats. Most importantly on all major high performance implementations: Even if no rendering window is visible you still need the graphics system running and being active and your program run in the environment of this graphics system.
On Windows the most straightforward way to go is creating invisible window, just a window you create with CreateWindowEx but not map with ShowWindow; you don't even need a event processing loop for that. In this window you create your OpenGL context as usual, but instead of rendering to the window framebuffer, you render to a Frame Buffer Object.
On X11/GLX it's even more straightforward: X11/GLX offers PBuffers without extensions (Windows has PBuffers, too, but for creating one you need a regular OpenGL context first). So on X11 you can create a PBuffer without a proxy window. The PBuffer iteself can be rendered to as off-screen buffer; Frame Buffer Object work in a PBuffer, as well, if the implementation supports them. Using a invisible window with a Frame Buffer Object, just like with Windows, works as well. Either way, with current drivers X11 must be active and the bound console, so you can not start an additional X server in the background and have your off-screen rendering happen there, but this is just a limitation of the drivers and not of X11, GLX or OpenGL.
Only libraries allowed are those without external libraries, just like GLEW which I use.
You can link GLEW statically to your program. If you're hardcore you can do extension loading manually, but why would you want to do that?
What is the lightest cross-platform library that can staticaly link and can create context.
How do you define "lightest?"
The two cross-platform libraries that do the least other than creating OpenGL windows are FreeGLUT and GLFW.
FreeGLUT has about a 5.2MB distribution (after unzipping), while GLFW has a 2.6MB distro. Does that make it "lighter"? FreeGLUT's compiled static library, in release mode under VS2008, is around 500KB; the one for GLFW under similar compilation is 120KB. Does that make it "lighter"?
Related
I am working on an openGL project. The application should handle window resize events and correctly adjust the aspect ratio accordingly. I've seen many solutions for window resize handling, but they all require GLUT. Is there a way that I can implement the window resize handling without using GLUT?
OpenGL does not know anything about windows, it just knows about a default framebuffer - sometimes called an window-system provided framebuffer or whatever. The default framebuffer can be a window, some output surface or even hardware overlay, or some off-screen resource (like pbuffers or some implementation and/or platform-specific stuff). The connection between an actual windows and a GL context is done via platform-specific GL binding APIs like egl (originated for mobile/embedded GLES, but nowadays also applicable for desktop GL), wgl (on Windows), glX on Unix X11 window system, and so on.
But managing the window is a topic completely outside of the realm of OpenGL.
Is there a way that I can implement the window resize handling without using GLUT?
Yes, GLUT is just a (very outdated!) cross-plattform wrapper around those platform-specifc APIs mentioned before. You can always directly implement all that stuff using the native APIs of your platform. Or you can use some other wrapper API or windowing toolkit with OpenGL support (like GLFW, SDL, Qt, gtk, wxWindows, whatever).
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.
Is it possible to learn ''modern'' OpenGL with SDL2.0, without using a loading wrapper?
I've read that I had to use an OpenGL loading library in order to use a function like glGenVertexArrays.
But if that is the case, which loading library should I use? GLEW doesn't seem to be maintained.
GLFW seems to be new, but if I use that, SDL is not needed any more right?
GLEW (which very much is maintained) and GLFW serve very different purposes. GLEW is an extension wrangler which allows you to access non-standard functionality, and in some cases, standard functionality which isn't exposed by the default development environment. The most common example of the latter is developing on Windows, where the standard OpenGL header hasn't been updated for any functionality subsequent to OpenGL 1.x.
GLFW on the other hand is an abstraction which is designed to allow you to create windows and OpenGL contexts on a variety of supported platforms without having to write code specific to that platform. The process of setting up a window on OSX is very different from that of setting up one on Microsoft Windows, and this is what GLFW shields you from. In this regard GLFW is a subset of the functionality of SDL, which attempts to do the same thing, but with a larger focus, allowing access to audio output and and game device inputs as well.
Whether or not you have to use a loading library such as GLEW with either SDL or GLFW is mostly dictated by the platform you're trying to target and the OpenGL functionality you want to use. If you're attempting to use modern OpenGL, i.e. 3.x or 4.x, and you're working with a platform that doesn't have full support for it in it's OpenGL headers, then you're probably going to have to rely on GLEW to fill in that gap for you.
I'm using cocos2d-x to develop an iPhone game and then it just came to my head why not release my game for PC too? The only problem is that setting the window to full screen mode is not implemented yet. Now I'm just stuck with how to create a full screen window? There are some window creation functions that are used but I'm not sure which one and how I should change.
There is the eglCreateWindowSurface function that cocos2d is calling to create a window. I'm not sure which option I should change so that it creates a full screen window. It would also be nice if I can implement a function that switches my game to full screen mode and back while running.
On Windows it's a bit more compilicated. Essentially you have to:
Create a proxy OpenGL context to get access to functionality above OpenGL-1.1 through extensions
Load the extensions required to create an OpenGL-ES compatible context
Create the higher version OpenGL context
Again Load the extensions, now for this context
Luckily all this has been wrapped up in several easy to use libraries. I recomment GLFW for Window/Context creation (it deals with all that proxy context stuff, too), and GLee or GLEW to make the OpenGL extensions available to the code.
http://www.glfw.org/
http://elf-stone.com/glee.php
http://glew.sourceforge.net/
Those libraries are cross platform, so your application/game itself does not use OS dependent functions, it will compile not only for Windows but also Linux, BSD and MacOS X.
We have an OpenGL Application (using Ogre3d and SDL, not directly calling OpenGL) and we are trying to change the Resolution at runtime. It seems that we need to re-initialize our OpenGL context with the new Resolution but a number of items are breaking along the way. On Linux it seems to work for a while, then we get graphical corruption on screen. On Windows it simply crashes the next time we try to render a frame. We have forced the reloading of textures in Ogre, and if we rendering nothing but textures (no 3d models) then this works fine, but any 3d models cause a crash and reloading before rendering them has no effect.
Here is a link to an in depth explanation of Ogre3d calls we are doing: http://www.ogre3d.org/forums/viewtopic.php?f=2&t=62825
All we really need to know is, When re-initializing an Opengl context what resources need to be restored?
Why does adjusting an OpenGL context affect other resources? Is it the way OpenGL works, or did one of the libraries we use introduce this issue? Could we have added this issue without knowing it?
Did you have a look at this forum thread ?
SDL seems to destroy the OpenGL when changing resolution. In this case, all you GL resources are destroyed with the context.
One possible solution would be to create another 'dummy' GL context, sharing resources with you 'real' GL context, and to keep it alive with SDL destroys the 'main' context. This way most of your resources should survive.
Note that some resources can't be shared, textures and VBO are fine, but VAO can't.
OpenGL support was added SDL after its surface code had been established. That's why changing the size of a SDL window is destructive. You were pointed to OpenGL context sharing and its caveats. However I'd avoid the problem alltogether by not using SDL for creating an OpenGL window. You can use all the other facilities SDL provides without a window managed by SDL, so the only thing that would change is input event processing and how the window's created. Instead of SDL I'd use GLFW, which like SDL requires you to implement your own event processing loop, so using GLFW as a drop-in replacement for OpenGL window and context creation is straightforward.