I just recently changed all rendering in my application/game from SDL to OpenGL. I still use SDL for keyboard input, loading images and creating the window.
But since i only render in OpenGL do you think that i should change the window to a OpenGL initialized window instead of a SDL window. The header i use for OpenGL functions at the moment is "SDL_opengl.h". Does that affect things?
What are the advantages and disadvantages if i do this? Right now it feels like it's the logical "next step" since i got rid of all other SDL rendering code.
Just keep on using SDL for input and window management.
There's no provision for either in the OpenGL spec so there's really no such thing as an "OpenGL initialized window".
As genpfault said, you should keep using SDL for your window initialization. It's more clean and portable than OS-specific methods of initializing a window for OpenGL rendering.
I would also recommend switching from SDL_opengl.h to SDL.h and gl.h; the definitions in SDL_opengl.h aren't necessary for basic window management, and they conflict with the definitions in other OpenGL libraries like GLEW (which you may want to use later for pixel shaders and framebuffers).
Related
Is this possible in nature? What role of SDL library in OpenVR API? Does it needed for OpenGL context or only for mirroring the stereo image to SDL window?
It is possible. If you don't use SDL, you'll have to create your rendering context and window by yourself. The whole code would be too long for this answer, but on Windows you could use functions like CreateWindowEx and wglCreateContext. OpenVR doesn't require anything different from a normal context setup, but you need to use a somewhat modern version of OpenGL (4.1 at least works for me).
How do I set the number of samples in the default framebuffer, given by Windows?
I found this page, but although I use glew, there is no available wglChoosePixelFormatARB function in my context. What could be the cause of this?
With WGL, you can only set the pixel format for a window once when you create the context, and you can only call the wglChoosePixelFormatARB() function once the client driver is loaded, and the client driver is only loaded once you have an OpenGL context. Yes, that's circular. So, this means you have to do the following:
Create a window with an OpenGL context.
Get the function pointer for wglChoosePixelFormatARB().
Destroy the window, and create a new window with the desired pixel format.
If you've got any sense in you, you'll use SDL or GLFW to do this for you, because it's just a bunch of plumbing you have to write, there's no value in learning how to do it, and you probably want to get some real work done. SDL/GLFW/etc. is how 99% of the OpenGL game devs out there do it.
If you really want to do this yourself and get stuck, look at the SDL or GLFW source code to see how they do it.
In SDL, the src/video/windows/SDL_windowsopengl.c file has a function WIN_GL_ChoosePixelFormatARB() which does what you want. Also note the function WIN_GL_LoadLibrary().
In GLFW, the src/win32_window.c file has a function _glfwPlatformCreateWindow() which does what you want.
P.S. GLEW is a bit broken with core contexts and modern cards, so watch out. There are other GL loaders out there.
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'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"?
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.