Any OpenGL framework with these features?
Author
Does anyone around here know of any opengl framework which supports all (or at least the first three) the following features:
* Cross-platform
* Separating event polling from buffer swapping (required for point 3)
* Making the OpenGL context current in a second thread (so, also unbinding the context from the first, in which the window was created)
* Enumerating available video modes & Changing video mode when running
Currently I am using SFML, which is good, but doesn't support points 2 and 3 (but I requested these features in their forum)
Author
OSG is a higher-level scene graph library, not an opengl framework (although it is based on opengl), so I doubt it provides what I want.
I don't know how advanced the thread-support is, nor if it is possible to change the video mode while running, but I'm currently using GLFW and enjoying it.
Take a look at glfw.sourceforge.net and find out. :)
Good luck.
Take a look at glfw.sourceforge.net and find out. :)
Good luck.
Author
I already know of GLFW. Changing video mode while running is possible btw (but not switching between windowed and fullscreen)
Out of all frameworks (and despite it's imo pretty ugly C interface) it does get closest, but it does not support #3 from my list. But I hacked in that feature for the Win32 implementation (im not much of an expert in X11 and Mac OS programming). So for the moment this hacked version is what I'll be using until I find something better.
Out of all frameworks (and despite it's imo pretty ugly C interface) it does get closest, but it does not support #3 from my list. But I hacked in that feature for the Win32 implementation (im not much of an expert in X11 and Mac OS programming). So for the moment this hacked version is what I'll be using until I find something better.
It's days like this I realise I should have got my window framework ported as it pretty much covers what you want to do in your list [oh]
Win32 version works, but Linux support never got written and I lack an OS X machine to write a backend for that... I should probably bring that project back to life at some point...
Win32 version works, but Linux support never got written and I lack an OS X machine to write a backend for that... I should probably bring that project back to life at some point...
Author
Quote:Original post by phantom
It's days like this I realise I should have got my window framework ported as it pretty much covers what you want to do in your list [oh]
Win32 version works, but Linux support never got written and I lack an OS X machine to write a backend for that... I should probably bring that project back to life at some point...
Yeah, I looked at your framework's site as well, and the lack of Linux and OS X support kept me from trying it at all, too bad, I guess.
Sounds like OpenTK is what you want.
* Cross-platform - check (Linux/OSX through X11, Windows, native OSX in the works)
* Separating event polling from buffer swapping (required for point 3) - check
* Making the OpenGL context current in a second thread (so, also unbinding the context from the first, in which the window was created) - check
* Enumerating available video modes & Changing video mode when running - check
Moreover: automatic extension loading, truetype fonts, documentation and a very intuitive interface.
You didn't specify programming language however. This is a .Net/Mono library, which may or may not be acceptable. :)
Edit, to get a little more concrete:
* Cross-platform: no recompilation needed, the same exe/dll runs on all supported platforms, simply by copy-pasting.
* Event polling: generally handled internally. Details depend on the windowing class you use (GameWindow, Windows.Forms GLControl), but it's intuitive and flexible (you can mold event handling to your needs).
* OpenGL context: the GraphicsContext class is separate from the windowing classes. Completely flexible: you can create as many contexts as you like, make them current/not current on any thread, and bind them on any available window. Can't get any better than this ;)
* Video modes: completely multi-monitor aware. One DisplayDevice per monitor and you can query and change resolution/bitdepths.
Apart from these it is a low-level library. The OpenGL interface has undergone a little surgery (e.g. GL.Arb.ActiveTexture instead of glActiveTextureARB, and GL.Enable(EnableCap.DepthTest) instead of glEnable(GL_DEPTH_TEST)), and is much more intuitive to use.
Ok, I won't advertise anymore, just to pique your curiosity :)
[Edited by - Fiddler on February 4, 2008 5:22:24 AM]
* Cross-platform - check (Linux/OSX through X11, Windows, native OSX in the works)
* Separating event polling from buffer swapping (required for point 3) - check
* Making the OpenGL context current in a second thread (so, also unbinding the context from the first, in which the window was created) - check
* Enumerating available video modes & Changing video mode when running - check
Moreover: automatic extension loading, truetype fonts, documentation and a very intuitive interface.
You didn't specify programming language however. This is a .Net/Mono library, which may or may not be acceptable. :)
Edit, to get a little more concrete:
* Cross-platform: no recompilation needed, the same exe/dll runs on all supported platforms, simply by copy-pasting.
* Event polling: generally handled internally. Details depend on the windowing class you use (GameWindow, Windows.Forms GLControl), but it's intuitive and flexible (you can mold event handling to your needs).
* OpenGL context: the GraphicsContext class is separate from the windowing classes. Completely flexible: you can create as many contexts as you like, make them current/not current on any thread, and bind them on any available window. Can't get any better than this ;)
* Video modes: completely multi-monitor aware. One DisplayDevice per monitor and you can query and change resolution/bitdepths.
Apart from these it is a low-level library. The OpenGL interface has undergone a little surgery (e.g. GL.Arb.ActiveTexture instead of glActiveTextureARB, and GL.Enable(EnableCap.DepthTest) instead of glEnable(GL_DEPTH_TEST)), and is much more intuitive to use.
Ok, I won't advertise anymore, just to pique your curiosity :)
[Edited by - Fiddler on February 4, 2008 5:22:24 AM]
Hmmm, I might have to take a shifty at OpenTK's source for OS X and X11 window stuff.. I'm just glad it's licensed under MIT, makes it sane for me to look at and use the code in my own stuff [smile] (with credit of course, and OGLWFW is zlib itself so it's all good, yay!)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
