OpenGL Window Framework Beta 1.1.1

Started by
16 comments, last by kburkhart84 18 years, 11 months ago
I just thought I'd let you all know I've just released beta 1.1 of the OpenGL Windowing Framework. The biggest change in this release is a basic user message handling system which enables you to handle a couple of message and overide them if needs be. This was added due to some problems someone who was using it was having. Since my last pimp of this at version Beta 1.0.2 accured a number of changes and improvements have taken place, the details of which can be found here. OpenGL Window Framework Website OpenGL Window Framework Sourceforge site All feedback welcomed [smile] (a linux verison is still 'on the way') [Edited by - _the_phantom_ on April 30, 2005 10:58:31 AM]
Advertisement
Just a bump to bring peoples attension to the 1.1.1 release [smile]

Adds support for a default 'move' message and allows the user to override it. This was to correct a slight case of crazyness due to how the 'resize' event was interacting with the rest of the system.
Very interesting. I've just changed my engine to use GLFW, so I'm not likely to change it right at once to use something else. I'm curious, though, what direct benefits does it have in comparison to GLFW?

When will the Linux version be ready?
it seems, from what i read on his site, that GLFW doesn't have very good support for multithreading and is too C-like.

Beginner in Game Development?  Read here. And read here.

 

Quote:Original post by James Trotter
I'm curious, though, what direct benefits does it have in comparison to GLFW?


Well, the fact you can use a multisample buffer I see as a win [wink]
The interface is C++ as my biggest gripe with all the other systems is the C-ness of them.
Multiple windows via handles.
A generlise event system, which works with functor and functions. You can hook one in to handle all events, have a different function for each event and finally different function for each event per window.
Automatic extension setup via GLee.
You can retrive both OpenGL and display modes.
No need for an explicate shutdown function, just destory the window manager and everything goes away automagically [smile]
The ability to create a window and handle its event pump in one thread while rendering in another totally different thread (no one has shown me how todo this in another API as yet).
You dont even need to init the system, just create the window manager, ask for a window mode which is compatible with your specs, a GL context which is the same and then create the window and go [smile]

What it doesnt do however is;
- handle input (my next project infact, I intend to make a sane cross platform input system)
- handle sound (OpenAL is my own choice for this)
- handle texture loading (Corona is my choice for this)
- handle anything else infact apart from the creation and management of OpenGL windows.

You might wonder why this is and the reason is simple; dont try todo lots of things, do one thing and do it well.
I'm not really claiming its 'better' than anything, just offer an alternative [smile]

Quote:
When will the Linux version be ready?

Hopefully soonish. Right now it compiles and links but the simple test app seg faults and dies [sad] I've not had a chance to work out why as yet.

Right now I've got a GLSL chapter to write and some vehical code for HL2 which needs finishing, however my normal state of mind is doing 3 things at once so if things go well a couple of week, if they dont a couple of months.
(I also need to intergate the new event code into the linux version, but that shouldnt be too hard).

Really, I created this for myself as I was sick of the dross with the windows setup and didnt like anything out there, if people like it and use it then cool, if not well I like it [wink]
Quote:Original post by _the_phantom_
Quote:Original post by James Trotter
I'm curious, though, what direct benefits does it have in comparison to GLFW?


Well, the fact you can use a multisample buffer I see as a win [wink]
The interface is C++ as my biggest gripe with all the other systems is the C-ness of them.
Multiple windows via handles.
A generlise event system, which works with functor and functions. You can hook one in to handle all events, have a different function for each event and finally different function for each event per window.
Automatic extension setup via GLee.
You can retrive both OpenGL and display modes.
No need for an explicate shutdown function, just destory the window manager and everything goes away automagically [smile]
The ability to create a window and handle its event pump in one thread while rendering in another totally different thread (no one has shown me how todo this in another API as yet).
You dont even need to init the system, just create the window manager, ask for a window mode which is compatible with your specs, a GL context which is the same and then create the window and go [smile]


Very cool. I've many times thought that some of those libraries might benefit from a more object-oriented C++ approach.

Quote:
What it doesnt do however is;
- handle input (my next project infact, I intend to make a sane cross platform input system)
- handle sound (OpenAL is my own choice for this)
- handle texture loading (Corona is my choice for this)
- handle anything else infact apart from the creation and management of OpenGL windows.

You might wonder why this is and the reason is simple; dont try todo lots of things, do one thing and do it well.

I definitely agree! That's my gripe with alot of projects. They usually try to do all things at once, and in my opinion it either bloats the code or makes it extremely hard to maintain. I find SDL has this problem.

All I need in a library like this is creating a window, and handling input.

Quote:
Quote:
When will the Linux version be ready?

Hopefully soonish. Right now it compiles and links but the simple test app seg faults and dies [sad] I've not had a chance to work out why as yet.

Right now I've got a GLSL chapter to write and some vehical code for HL2 which needs finishing, however my normal state of mind is doing 3 things at once so if things go well a couple of week, if they dont a couple of months.
(I also need to intergate the new event code into the linux version, but that shouldnt be too hard).

Really, I created this for myself as I was sick of the dross with the windows setup and didnt like anything out there, if people like it and use it then cool, if not well I like it [wink]


Give me a shout when the Linux version is done, though. Perhaps I can help testing it, and ironing out bugs or whatever...
I found that GLFW had a few bugs in it's Linux windowing code when I tested it...
Quote:Original post by James Trotter
Give me a shout when the Linux version is done, though. Perhaps I can help testing it, and ironing out bugs or whatever...
I found that GLFW had a few bugs in it's Linux windowing code when I tested it...


No worries, I'll make a note so that when stuff is ready I can give you a shout... ofcourse, if I forget chances are you'll see my post joyfully proclaiming some linux support when it happens [grin]

Looks great, but I shy away from things like this because of the third party libs. Staying up with current revs of dependencies is a pain, and frankly clutter up my hard drive.

Something like this that is completely stand alone like GLFW is better (for me) for these reasons.

J
I'm making a sort of similar framework, although my purpose is more towards a complete engine that can handle window creation/input etc. I currently have a working version on both Windows and Linux, and am putting some of the final touches on the input system. I do need to do some extensive testing, and I will be adding some more features for window creation (currently only size). A large part of my code comes from GLFW which I've been refactoring to support multiple windows. As an idea of how easy it is to get a window with input control see the following code:

#include "DGL/dgl.h"#include "System/Window/window.h"class MyWindow : public System::PlatformWindow{public:  MyWindow()  {    // If ESC is pressed close the window    mKeyMap.AddMapping(      DKEY_ESC,      KEY_DOWN,      bind(&Window::Close, this) );  }  float r,g,b;	void Draw( void )	{		glViewport(0,0,mWidth,mHeight);		glClearColor(0.f, 0.f, 0.f, 0.f);		glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );		glMatrixMode( GL_PROJECTION );		glLoadIdentity();		glOrtho(-10, 10, -10, 10, -10, 10);		glMatrixMode( GL_MODELVIEW );		glLoadIdentity();                glColor3f(r,g,b);		glRectf(-5,-5, 8,8);	}};// Init is automatically called from within the engineint Init(){  MyWindow *p = new MyWindow;  p->Create();  p->r = 1.f;  p->g = 0.f;  p->b = 0.f;  return 0;}


Currently there are no dependencies but I am heavily considering using boost for my task system.

James: if you're willing, this is pretty much ready to get some testing on Linux.

ps. _the_phantom_: sorry for barging in like this, but I thought it might be easiest to just hop in here. If you'd rather I remove this post, just let me know and I'll do so.
Hi Rick,

I can help you in testing it with linux/windows XP as well. These are my sys specs

Nvidia GeForce MX 4000 (not a very high end card)
Slackware 10.0 gcc 3.3.x

Windows XP home edition
VC++ 2005 Beta





The more applications I write, more I find out how less I know

This topic is closed to new replies.

Advertisement