From: Mars_999 <ma...@si...> - 2008-08-25 18:10:57
|
I am going to throw this out there, since you are going to ask the author to modify the GLFW api to work with glSDK, could we just roll the extension loader into that version? I am assuming GLE is the extension loader? Instead of having so many different sections to the SDK? Or are we trying to keep the SDK more modular. ----- Original Message ----- From: Henri Häkkinen To: gls...@li... Sent: Monday, August 25, 2008 12:45 PM Subject: Re: [Glsdk-devel] util. lib brainstorming I had an idea that we could fork from GLFW, strip it to the minium needs of the SDK and maybe tweak the API a bit to make it more streamlined into our style. This would have the following benefits: - we have our own windowing layer that we can control, yet don't need to implement it from scratch - we don't depend on external dependencies We could also ask from the author of GLFW, if s/he would like to join our SDK project as the maintainer-developer of the GLFW-fork. The windowlib is not yet the topic but we should give this possibility a serious thought. On Mon, Aug 25, 2008 at 6:29 PM, Henri Häkkinen <hen...@gm...> wrote: GLFW/GLUT is the thing we should use if they can get a OpenGL3 support and our extlib can tap into it. On Mon, Aug 25, 2008 at 11:32 AM, Stefanos A. <sta...@gm...> wrote: On Sun, 2008-08-24 at 21:36 +0300, =?ISO-8859-1?Q? Henri_H=E4kkinen _ wrote: > I think having a simple menu bar would also be beneficial for the > demos, as you could change some of the demo parameters from that > interface. Such as, back face culling, front face winding etc. This is > open for a debate. > > On Sun, Aug 24, 2008 at 9:22 PM, Jason McKesson <ko...@gm...> > wrote: > Henri Häkkinen wrote: > > - windowing system abstraction? Candidates; GLUT and GLFW. > we could > > also choose to implement our own windowlib that woudl > integrate into > > our GLE. This library would have features for opening > windows, > > creating simple menu bars, input processing etc. > > Creating a window with an OpenGL context is the limit of what > we should > provide. > > Now, that being said, there is something to be said for being > able to > handle input to some degree. This is mostly for examples and > demos, so > it can wait. When you implement all this, you are basically left with a less portable, buggier(*) version of GLFW/GLUT. There's really no good reason to avoid GLFW - it follows the GL naming conventions, is lightweight, simple and to the point: glfwInit(); /* w h r g b a d s GLFW_WINDOW */ glfwOpenWindow(640, 480, 8, 8, 8, 8, 16, 0, GLFW_FULLSCREEN); while (glfwGetKey() != GLFW_KEY_ESC) /* Callbacks supported too */ glfwSleep(0.01); glfwTerminate(); Which covers everything the sdk samples are going to need. (*) Just look at the source code of GLFW. They work around several win32/x11/osx bugs so that the library works the same everywhere. Speaking from experience, this is no easy feat. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Glsdk-devel mailing list Gls...@li... https://lists.sourceforge.net/lists/listinfo/glsdk-devel -- Henri 'henux' Häkkinen -- Henri 'henux' Häkkinen ------------------------------------------------------------------------------ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ------------------------------------------------------------------------------ _______________________________________________ Glsdk-devel mailing list Gls...@li... https://lists.sourceforge.net/lists/listinfo/glsdk-devel |