Re: [Glsdk-devel] util. lib brainstorming

[H. H. <hen...@gm...>]

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