I want to write some OpenGL 3.2, likely also OpenGL 4 stuff on Linux, and I just saw that libsdl 1.2 (the latest stable release) supports only 2.x. LibSDL 1.3 (which is in development) should support it, but it'll be a while before it gets into mainstream distributions. Is there any library out there right now which allows me to create an OpenGL window with a context of my choice, and preferably also help me with the input?
If not, is there some small library which reduces the pain with Xlib? My Windows path for OpenGL is written with plain-old WinAPI, with own message pump etc., and I wonder if X11 is worse than that. A quick web search indicates that one should use a library above Xlib. I'd be happy with something that just wraps XLib, so I can do the OpenGL context on my own with glX if XLib is really that horrible.
GLFW (GL Framework) supports creating 3.0+ contexts, and has input support, you can read about it on:
http://gpwiki.org/index.php/GLFW
http://www.glfw.org/
Sadly, the main page is down now.
Related
When I build an OpenGL application on Windows 10 I have to link to opengl32.lib. I use GLEW for loading OpenGL functions. GLEW internally uses wglGetProcAddress(). opengl32.lib provides support only for OpenGL 1.1. How does opengl32.lib work when wglGetProcAddress() asks for some newer OpenGL functionality? Does it act as a proxy and communicate with a graphics driver, for example OpenGL nvidia library?
Does it work the same way on Linux?
On Windows you have a so called OpenGL ICD (= Installable Client Driver). Essentially for every function that the OpenGL-1.1 specification defines this ICD provides an implementation proper that's passed through to by opengl32.dll, based on the currently active OpenGL context (i.e. you can have multiple ICDs installed, serving different OpenGL contexts within the same program).
The wglGetProcAddress function is part of that set, which is the reason, why you've to load extending/newer functions for each context separately on Windows. So essentially when you call wglGetProcAddress it will just call the actual ...GetProcAddress of the ICD.
On Linux we never had the concept of ICDs. A couple of years ago we finally got GLvnd (GL vendor neutral dispatch) which essentially gives Linux an ICD like mechanism. However the GLX specification clearly states, that the addresses obtained through glXGetProcAddress are invariant and identical for all OpenGL contexts. That means, that it's the OpenGL implementation's task (and not the intermediary layer between) to dispatch functions based on the context. The Mesa developers describe it here: https://docs.mesa3d.org/dispatch.html
In short: It's a mess.
OCaml comes with the Graphics module which allows the use of a graphical window.
Is it possible to open two graphical window, and switch between them ?
The Graphics module provides machine-independent tools but in case of a negative answer, perhaps it would also be interesting to have solutions for different window system, such as X11.
I looked through the Graphics module API and I don't see support for multiple windows. I would assume Graphics was intended as something useful but simple enough to be part of the base OCaml release.
For more complex graphics, it makes sense just to provide OCaml bindings to an existing library. If I go to opam.ocaml.org/packages and search for "graphics" I see a few possibilities.
I have done OpenGL coding in OCaml but in fact I had to build some wrappers for OS-native GUI functionality to create the windows. This was many years ago, however.
The Graphics module is quite limited and is more intended as a simple basic library for teaching purposes. A possible replacement for Graphics might be the tsdl package which is a thin wrapper around the SDL C library which should work on most platforms.
I'm migrating an OpenGL program over to C++. I have all of the library includes transitioned except for one. In my display function, I have this line (to display text on the screen):
glWindowPos2i(5,5);
This works fine when I run the program as a .c or when I run it as a .cpp in OSX. But I need it to compile as a .cpp on Linux, also. When I go to compile it there, I get this error:
error: 'glWindowPos2i' was not declared in this scope
I can't figure out if this is a missing library or what is going on. Does anyone know what I need to do to get this line to compile?
That is because glWindowPos__ (...) started life out as an extension: GL_ARB_window_pos. It was integrated into core OpenGL in version 1.4.
You are fortunate on OS X to have an implementation of OpenGL that supports OpenGL 2.1/3.2 (in newer versions) out-of-the-box. In Linux, the situation is much different. You have to use the GLX API to load the glWindowPos__ (...) function entry-points at run-time (because they are provided by the display driver).
The easiest way to solve this in all honesty would be to integrate the GLEW library into your build environment for non-OS X targeted builds. You will encounter this same problem in Microsoft Windows, because Windows only ships with OpenGL 1.1 libraries out-of-the-box - display drivers extend it at run-time just as in Linux.
GLEW will take care of loading the function entry-points that are not provided with the shipping OpenGL libraries on both Windows and Linux, and make the whole process painless. Just remember to disable GLEW when you build your software on OS X, it is not necessary and it actually creates more problems if you do link to it in OS X.
I've been playing around with Direct3D 11 a little bit lately and have been frustrated by the lack of documentation on the basics of the API (such as simple geometry rendering). One of the points of confusion brought on by the sparse documentation is the (apparent) move away from the use of effects for shaders.
In D3D11 all of the effect (.fx) support has been removed from the D3DX libraries and buried away in a hard to find (sparsely documented, of course) shared source library. None of the included examples use it, preferring instead to compile HLSL files directly. All of this says to me that Microsoft is trying to get people to stop using the effect file format. Is that true? Is there any documentation of any kind that states that? I'm fine doing it either way, but for years now they've been promoting the .fx format so it seems odd that they would suddenly decide to drop it.
Many professional game and graphics developers don't use the effects interfaces in Direct3D, and many of the leading game engines do not use them either. Instead, custom material/effects subsystems are built on top of the lower-level shader and graphics state state management facilities. This allows developers to do things like target both Direct3D and OpenGL through a common asset management pipeline.
The main issue is that the fx_5_0 profile which is needed to compile Effects 11 shaders with the required metadata is deprecated by the HLSL compiler team. The runtime is shared-source, but the compiler is not. In the latest D3DCompiler (#47) it emits a warning about this. fx_5_0 was never updated for some newer language aspects in DirectX 11.1 and 11.2, but works "as is" for Direct3D 11.
The second issue is that you need D3DCompile APIs at runtime to make use of Effects 11. Since D3DCompile was 'development only' for Windows Store apps for Windows 8.0 and Windows phone 8.0, it wasn't an option there. It is technically possible to use Effects 11 today with Windows Store apps for Windows 8.1 and Windows phone 8.1 since D3DCompile #47 is part of the OS and includes the 'deprecated/as-is' compiler support for fx_5_0, but this use is not encouraged.
The bulk of the DirectX SDK samples and all the Windows Store samples avoid use of Effects 11. I did post a few Win32 desktop samples that use it to GitHub.
UPDATE: With the release of the legacy Microsoft.DXSDK.D3DX NuGet repacking of the original D3DX #43, I was able to update the rest of the legacy DirectX SDK samples so they can build with the modern Windows SDK and not require the legacy DirectX SDK to be installed. Most of the Direct3D 9 and Direct3D 10 samples, and a few Direct3D 11 samples, all use legacy Effects. See GitHub.
So in short, yes you are discouraged from using it but you still can at the moment if you can live with the disclaimers.
I'm in the exact same position, and after Googling like crazy for even the simplest sample that uses D3DX11CreateEffectFromMemory, I've too come to the conclusion that .fx file support isn't their highest prio. Although it is strange that they've added the EffectGroup concept, which is new to 11, if they don't want us to use it.
I've played a little with the new reflection API, so it looks like it will be pretty easy to hack together your own functions for setting variables etc, in essence creating your own Effect-class, and the next step is going to be to see what support their is for creating render state blocks via the API. Being able to edit those directly in the .fx file was very nice, so hopefully something like that still exists (or, at worst, I can rip that part from the Effect11 code).
There is an effect runtime provided as a sample in the DirectX SDK that should be able to help you to use .fx files.
Check out the directory: %DXSDK_DIR%\Samples\C++\Effects11
http://msdn.microsoft.com/en-us/library/ff476261(v=VS.85).aspx
This suggests that it can take a shader or an effect.
http://msdn.microsoft.com/en-us/library/ff476190(v=VS.85).aspx
Also, what is the difference between a shader and an effect?
I would like to learn graphics programming with OpenGL. And since I will just start learning it I decided to learn the new/OpenGL3 way of doing things.As far as I can see one has to create an OpenGL 3 context for this (Core profile in the new OpenGL 3.2 if I understand this correctly). Well I thought about using Qt for this, currently using version 4.5.2, since I know it already and like it and it supports creating the OpenGL widget. What I have the problem with is that it looks like the OpenGL widget is always crated with the old OpenGL 2 context and I can't see the option to make it in/switch it to OpenGL 3 way. Am I missing some obvious thing here or do I need something a bit more tricky to create OpenGL 3 context with Qt? Is it even supported in current version of Qt? I'm using Linux, if it makes any difference.
Mesa software rendering is still stuck on OpenGL 2.1. If you're using the binary NVidia drivers they provide OpenGL 3.2 support on sufficiently recent hardware. AMD's latest fglrx supports 3.1. Open Source drivers seem to top out around 1.3-1.4.
If you've gotten this far you'll probably have to hack the Qt sources to use GLX_ARB_create_context instead of GLXCreateContext to get a OpenGL 3.2 Core context.
This guy seems to have had partial success, if you haven't already come across the thread via Google.