glsdk-devel — Main development list for the OpenGL SDK

Re: [Glsdk-devel] License

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

I have committed changes with the MIT license in each source (perhaps too
hastly). We can later change it to the Khronos license.

On Mon, Aug 25, 2008 at 10:54 PM, Rick Yorgason <ri...@fi...> wrote:

> Henri Häkkinen wrote:
> > Okay good. If anyone else does not have objections or points, can we
> > conclude we use the MIT license? Someone post a verbatim copy of the
> > license here so I can include it to my GLM sources, please.
>
> Why not the Khronos license?  http://glew.sourceforge.net/khronos.txt
>
> It's basically just the MIT license, but with a name OpenGL users are
> familiar with.
>
> -Rick-
>
> -------------------------------------------------------------------------
> 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

Re: [Glsdk-devel] GLSDK packaging

[Branan R. <br...@gm...>]

I've got a big enough hard drive I can install several Linux
distributions to build packages with, if necessary.

Branan

On Mon, Aug 25, 2008 at 1:20 PM, Henri Häkkinen <hen...@gm...> wrote:
> Thank you for willingness to contribute. Packaging is not yet an issue, but
> we will perhaps contact you when the time is right.
>
> Paths for other IDEs besides MSVC is a good idea and we will probably have
> that too.
>
>
> On Mon, Aug 25, 2008 at 11:02 PM, Rick Yorgason <ri...@fi...> wrote:
>>
>> Henri Häkkinen wrote:
>> > Some thoughts about GLSDK packaging:
>> >
>> > - on Windows; we could distribute GLSDK as .zipped source package and a
>> > .msi installer
>>
>> I have a fair bit of experience with NSIS.  I'd be willing to create
>> Windows .exe installers, and it probably wouldn't be too difficult to
>> have the installer offer to set up the proper command line and Visual
>> Studio paths.  (Maybe also an OSS IDE, like Code::Blocks?)
>>
>> > - on Linux; as a source tarballs and debian packages
>>
>> I know less about this, but it would be nice to maintain a Ubuntu
>> package so that users could install the SDK straight through the package
>> manager.  (It would also be a source of cross-advertising.) I'd be
>> willing to look into that as well, but I don't have Linux at my office,
>> so if I'm in charge of the Linux package it may lag behind the Windows
>> installer.
>>
>> -Rick-
>>
>> -------------------------------------------------------------------------
>> 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
>
>
> -------------------------------------------------------------------------
> 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
>
>

Re: [Glsdk-devel] GLSDK packaging

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

Thank you for willingness to contribute. Packaging is not yet an issue, but
we will perhaps contact you when the time is right.

Paths for other IDEs besides MSVC is a good idea and we will probably have
that too.


On Mon, Aug 25, 2008 at 11:02 PM, Rick Yorgason <ri...@fi...> wrote:

> Henri Häkkinen wrote:
> > Some thoughts about GLSDK packaging:
> >
> > - on Windows; we could distribute GLSDK as .zipped source package and a
> > .msi installer
>
> I have a fair bit of experience with NSIS.  I'd be willing to create
> Windows .exe installers, and it probably wouldn't be too difficult to
> have the installer offer to set up the proper command line and Visual
> Studio paths.  (Maybe also an OSS IDE, like Code::Blocks?)
>
> > - on Linux; as a source tarballs and debian packages
>
> I know less about this, but it would be nice to maintain a Ubuntu
> package so that users could install the SDK straight through the package
> manager.  (It would also be a source of cross-advertising.) I'd be
> willing to look into that as well, but I don't have Linux at my office,
> so if I'm in charge of the Linux package it may lag behind the Windows
> installer.
>
> -Rick-
>
> -------------------------------------------------------------------------
> 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

Re: [Glsdk-devel] [GLm] api

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

We are currently using floats, but may want to reserve the possibility of
havings doubles too. Therefore we use the -f postfix. This is also the GL
convention of doing things:

glVertex2f

and therefore we have:

glmVecSet2f

instead of:

glmVec2Set

Also, we don't have glmVecDiv or glmVecMul. Why? Because vector division or
multiplication are not defined in linear-algebra. There are two kinds of
vector products: cross and dot. These are handled by the -Cross and -Dot
entry points. Member-wise div or mul are not mathemtically defined
operations in vector calculus AFAIK.

We have now several open issues with the GLM API:

1) Should we provide -Mul and -Div for vectors?
My opinion: no, as they are not defined in mathematics and they generally
are not needed

2) Should we use short naming convention or is the current convention fine?

The current convention is, for example:

glmVecSet2f
glmVecAdd2f
glmVecLength2f
glmVecTransform2f
glmMatSet2f
glmMatIdentity2f

The proposed short convention would be, for example:

glmVecLen2f
glmVecTrans2f
glmMatIdent2f
glmMatDet2f

3) Should we drop the -f postfix, or should we keep it for future possible
double types?,

glmVecSet2f (the current API) vs. glmVecSet2 (the proposed)

My opinion: we should keep the -f, it is more OpenGL-like and we reserve the
possibility of -d

4) Should we have the dimension of the type in the end of the entry-point
(like in OpenGL) or in the middle?

glmVecSet2f (the current API) vs. glmVec2Setf (the proposed)

My opinion: glmVecSet2f, it is more OpenGL-like


Issues are open for discussion. Please comment.



On Mon, Aug 25, 2008 at 10:10 PM, Mars_999 <ma...@si...> wrote:

>  I haven't looked at the lib yet, but aren't we just going to work with
> floats all the time?
>
> glmVec2Sub
> glmVec3Sub
> glmVec4Sub
>
> glmVec2Add
> glmVec3Add
> glmVec4Add
>
> glmVec2Mul
> glmVec2Div
>
> glmVec2Norm
> glmVec2Transf
> glmVec3Cross
> glmVec3Dot
>
> I like that format...
>
> ----- Original Message -----
> *From:* Henri Häkkinen <hen...@gm...>
> *To:* glsdk-devel <gls...@li...>
> *Sent:* Monday, August 25, 2008 2:04 PM
> *Subject:* [Glsdk-devel] [GLm] api
>
> The GLM API seems at this moment to use two sets of naming styles. Compare
> these two for example:
>
> glmVecSub2f
> glmVecLength2f
>
> The first function is using a short form for the operation ('sub' as from
> 'substract') while the other is using long form. Should we simplify the API
> to look like this:
>
> glmVecSub2f
> glmVecLen2f
>
> Althought on the other hand, how do we shorten such stuff as Normalize,
> Transform, Identity, Inverse? This does not necessary look good:
>
> glmVecNorm
> glmVecTrans
> glmMatTrans
> glmMatInv
> glmMatIdent
>
> Is this even a big issue? Comments?
>
> If we decide to keep the API as it is now, I think we should lock it in and
> begin to outline the API reference for it. For later versions, I would like
> to implement such stuff as colors, quaternions and maybe planes and matrix
> stacks but this can wait. Bigger priority is to get the current version
> working and tested for.
>
> For Korval: I outlined some API ref in a plain text format. You may find it
> in 'docs/sdk_reference/glm-apiref' in the latest revision. You may use this
> as ideas for the DocBook API ref and this file needs to get removed once you
> migrate it into DocBook.
>
> --
> 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
>
>
> -------------------------------------------------------------------------
> 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

Re: [Glsdk-devel] util. lib brainstorming

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

We may discuss and you may contact the GLFW folks but there is absolutely no
kind of hurry. We might also want to discuss of using freeglut or a fork of
it for our SDK.

GLUT is simpler, but GLFW more advanced, which is better? For tutorials,
GLUT-like system may be enought and more cohorent.

About image library and wrapping glTexImage:

An imagelib wrapping glTexImage may be a good idea. We will need tutorials
on different levels:

1) Beginner level, which explains the basic usage of OpenGL3. At this level,
we don't use other than the mathlib, extlib and windowlib (no shapelib or
imagelib involved). We probably also want to create platform-specific
tutorials, like how to create GL context with WGL, GLX, CGL, even EGL...

2) Intermadiate level, which explains stuff like shader programs and some
tricks. At this level we don't want to involve low-level stuff like loading
images and objects, so we can wrap them in libs.

3) Advanced level; shader effects...

For initial SDK releases, we focus on beginner level, then move on to
intermediate and finally into advanced...


On Mon, Aug 25, 2008 at 10:26 PM, Branan Riley <br...@gm...> wrote:

> If no one else has gotten in touch with the GLFW people yet, I'll get
> in touch with them, talk to them about our design goals for the SDK,
> and see if we can integrate them into our SVN (maybe using svn
> externals on a stable tagged version so we don't actually duplicate
> anything)
>
> On Mon, Aug 25, 2008 at 12:19 PM, Mars_999 <ma...@si...> wrote:
> > As for textures what about Nvidias texture library file they have? They
> have
> > a texture pack on their developer site for use. It has normal maps and
> > textures, ect...
> >
> > I am fine with GLFW it support all three platforms and that is the main
> goal
> > for now, if some other platform needs it, they could port the
> tutorials(SDK)
> > to their platform if they want to. I would venture to say someone will
> port
> > this all to Java/JOGL someday if it gets finished... and we aren't coding
> > Java for the SDK so I would expect it.
> >
> >
> >
> > ----- Original Message -----
> > From: <gl...@mo...>
> > To: <gls...@li...>
> > Sent: Monday, August 25, 2008 2:10 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.
> >>
> >> I'd vote against. Let's try not to start our work by just putting more
> and
> >> more work on ourselves ;)
> >> Having support from GLFW author(s) would be nice though. I'd keep the
> >> library as it is and extend it to support OpenGL 3.0. That's it.
> >>
> >>
> >> Going back to general discussion.
> >> I'll focus on things that I believe haven't been decided yet.
> >>
> >> 1. Math
> >> It's Henri's lib for most of tutorial/sample stuff and possibly my lib
> for
> >> tech demos only (these meant to show capabilities of OpenGL).
> >>
>

> >> However if people will prefer to use other math lib, then mine should be
> >> excluded from SDK. Three is a crowd.
> >>
>

> >>
> >>
> >> 2. Platform abstraction
> >> I'm all for GLFW here. Anyway we have to make decision soon enough.
> >>
> >>
> >>
> >> 3. Texture library
> >> I'm using FreeImage and I'm a happy man ;) Too bad it doesn't have it's
> >> own namespace though.
> >>
> >>> // load image and return it as texture
> >>> GLuint gltLoadTexture (const char *filename);
> >>>
> >>> // load image, convert it to the given format and return as texture
> >>> GLuint gltLoadTexture2 (const char *filename, GLenum format);
> >>>
> >>> // load from a buffer
> >>> GLuint gltLoadBuf (const GLvoid *buf, GLsizei size);
> >>
> >> I strongly object the idea of wrapping glTexImage.
> >> Let's just provide a way to load/store/free image. Uploading to OpenGL
> >> should be done without hepler functions. Don't forget that we're
> teaching
> >> OpenGL here ;)
> >>
> >> This library should come with some basic texture package like
> brickwalls,
> >> normalmaps, environment cubemaps (some in float format) and some
> textures
> >> for teaching alpha blending and alpha testing.
> >>
> >>
> >>
> >> 4. Shader library
> >>
> >> I also suggest limiting this part to helper functions for loading shader
> >> from file and a structure to store shader code. We should teach people
> to
> >> create programs, shaders and bind them together. Otherwise we're not
> >> teaching them how to use OpenGL but our helper functions.
> >>
> >> What shader library should really be is... shader library :)
> >> But I guess that's obvious.
> >>
> >>
> >> So, our TODO list extends by textures, shaders and some meshes later.
> >>
> >>
> >> Since I can't find ehough time recently and things tend to get even
> worse
> >> I'm not declaring to be of any help - I'll just focus on my math library
> >> for now.
> >>
> >> Cheers.
> >>
> >>
> >>
> -------------------------------------------------------------------------
> >> 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
> >>
> >
> >
> > -------------------------------------------------------------------------
> > 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
> >
>
> -------------------------------------------------------------------------
> 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

Re: [Glsdk-devel] GLSDK packaging

[Rick Y. <ri...@fi...>]

Henri Häkkinen wrote:
> Some thoughts about GLSDK packaging:
> 
> - on Windows; we could distribute GLSDK as .zipped source package and a 
> .msi installer

I have a fair bit of experience with NSIS.  I'd be willing to create 
Windows .exe installers, and it probably wouldn't be too difficult to 
have the installer offer to set up the proper command line and Visual 
Studio paths.  (Maybe also an OSS IDE, like Code::Blocks?)

> - on Linux; as a source tarballs and debian packages

I know less about this, but it would be nice to maintain a Ubuntu 
package so that users could install the SDK straight through the package 
manager.  (It would also be a source of cross-advertising.) I'd be 
willing to look into that as well, but I don't have Linux at my office, 
so if I'm in charge of the Linux package it may lag behind the Windows 
installer.

-Rick-

Re: [Glsdk-devel] License

[Rick Y. <ri...@fi...>]

Henri Häkkinen wrote:
> Okay good. If anyone else does not have objections or points, can we 
> conclude we use the MIT license? Someone post a verbatim copy of the 
> license here so I can include it to my GLM sources, please.

Why not the Khronos license?  http://glew.sourceforge.net/khronos.txt

It's basically just the MIT license, but with a name OpenGL users are 
familiar with.

-Rick-

Re: [Glsdk-devel] util. lib brainstorming

[Branan R. <br...@gm...>]

If no one else has gotten in touch with the GLFW people yet, I'll get
in touch with them, talk to them about our design goals for the SDK,
and see if we can integrate them into our SVN (maybe using svn
externals on a stable tagged version so we don't actually duplicate
anything)

On Mon, Aug 25, 2008 at 12:19 PM, Mars_999 <ma...@si...> wrote:
> As for textures what about Nvidias texture library file they have? They have
> a texture pack on their developer site for use. It has normal maps and
> textures, ect...
>
> I am fine with GLFW it support all three platforms and that is the main goal
> for now, if some other platform needs it, they could port the tutorials(SDK)
> to their platform if they want to. I would venture to say someone will port
> this all to Java/JOGL someday if it gets finished... and we aren't coding
> Java for the SDK so I would expect it.
>
>
>
> ----- Original Message -----
> From: <gl...@mo...>
> To: <gls...@li...>
> Sent: Monday, August 25, 2008 2:10 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.
>>
>> I'd vote against. Let's try not to start our work by just putting more and
>> more work on ourselves ;)
>> Having support from GLFW author(s) would be nice though. I'd keep the
>> library as it is and extend it to support OpenGL 3.0. That's it.
>>
>>
>> Going back to general discussion.
>> I'll focus on things that I believe haven't been decided yet.
>>
>> 1. Math
>> It's Henri's lib for most of tutorial/sample stuff and possibly my lib for
>> tech demos only (these meant to show capabilities of OpenGL).
>>
>> However if people will prefer to use other math lib, then mine should be
>> excluded from SDK. Three is a crowd.
>>
>>
>>
>> 2. Platform abstraction
>> I'm all for GLFW here. Anyway we have to make decision soon enough.
>>
>>
>>
>> 3. Texture library
>> I'm using FreeImage and I'm a happy man ;) Too bad it doesn't have it's
>> own namespace though.
>>
>>> // load image and return it as texture
>>> GLuint gltLoadTexture (const char *filename);
>>>
>>> // load image, convert it to the given format and return as texture
>>> GLuint gltLoadTexture2 (const char *filename, GLenum format);
>>>
>>> // load from a buffer
>>> GLuint gltLoadBuf (const GLvoid *buf, GLsizei size);
>>
>> I strongly object the idea of wrapping glTexImage.
>> Let's just provide a way to load/store/free image. Uploading to OpenGL
>> should be done without hepler functions. Don't forget that we're teaching
>> OpenGL here ;)
>>
>> This library should come with some basic texture package like brickwalls,
>> normalmaps, environment cubemaps (some in float format) and some textures
>> for teaching alpha blending and alpha testing.
>>
>>
>>
>> 4. Shader library
>>
>> I also suggest limiting this part to helper functions for loading shader
>> from file and a structure to store shader code. We should teach people to
>> create programs, shaders and bind them together. Otherwise we're not
>> teaching them how to use OpenGL but our helper functions.
>>
>> What shader library should really be is... shader library :)
>> But I guess that's obvious.
>>
>>
>> So, our TODO list extends by textures, shaders and some meshes later.
>>
>>
>> Since I can't find ehough time recently and things tend to get even worse
>> I'm not declaring to be of any help - I'll just focus on my math library
>> for now.
>>
>> Cheers.
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>
>
> -------------------------------------------------------------------------
> 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
>

Re: [Glsdk-devel] util. lib brainstorming

[Mars_999 <ma...@si...>]

As for textures what about Nvidias texture library file they have? They have 
a texture pack on their developer site for use. It has normal maps and 
textures, ect...

I am fine with GLFW it support all three platforms and that is the main goal 
for now, if some other platform needs it, they could port the tutorials(SDK) 
to their platform if they want to. I would venture to say someone will port 
this all to Java/JOGL someday if it gets finished... and we aren't coding 
Java for the SDK so I would expect it.



----- Original Message ----- 
From: <gl...@mo...>
To: <gls...@li...>
Sent: Monday, August 25, 2008 2:10 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.
>
> I'd vote against. Let's try not to start our work by just putting more and
> more work on ourselves ;)
> Having support from GLFW author(s) would be nice though. I'd keep the
> library as it is and extend it to support OpenGL 3.0. That's it.
>
>
> Going back to general discussion.
> I'll focus on things that I believe haven't been decided yet.
>
> 1. Math
> It's Henri's lib for most of tutorial/sample stuff and possibly my lib for
> tech demos only (these meant to show capabilities of OpenGL).
>
> However if people will prefer to use other math lib, then mine should be
> excluded from SDK. Three is a crowd.
>
>
>
> 2. Platform abstraction
> I'm all for GLFW here. Anyway we have to make decision soon enough.
>
>
>
> 3. Texture library
> I'm using FreeImage and I'm a happy man ;) Too bad it doesn't have it's
> own namespace though.
>
>> // load image and return it as texture
>> GLuint gltLoadTexture (const char *filename);
>>
>> // load image, convert it to the given format and return as texture
>> GLuint gltLoadTexture2 (const char *filename, GLenum format);
>>
>> // load from a buffer
>> GLuint gltLoadBuf (const GLvoid *buf, GLsizei size);
>
> I strongly object the idea of wrapping glTexImage.
> Let's just provide a way to load/store/free image. Uploading to OpenGL
> should be done without hepler functions. Don't forget that we're teaching
> OpenGL here ;)
>
> This library should come with some basic texture package like brickwalls,
> normalmaps, environment cubemaps (some in float format) and some textures
> for teaching alpha blending and alpha testing.
>
>
>
> 4. Shader library
>
> I also suggest limiting this part to helper functions for loading shader
> from file and a structure to store shader code. We should teach people to
> create programs, shaders and bind them together. Otherwise we're not
> teaching them how to use OpenGL but our helper functions.
>
> What shader library should really be is... shader library :)
> But I guess that's obvious.
>
>
> So, our TODO list extends by textures, shaders and some meshes later.
>
>
> Since I can't find ehough time recently and things tend to get even worse
> I'm not declaring to be of any help - I'll just focus on my math library
> for now.
>
> Cheers.
>
>
> -------------------------------------------------------------------------
> 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
> 

Re: [Glsdk-devel] License

[Branan R. <br...@gm...>]

The ZLIB license is right here: http://zlib.net/zlib_license.html

Just fix the file and copyright info for whatever you're using it for.

Branan

On Mon, Aug 25, 2008 at 12:07 PM, Henri Häkkinen <hen...@gm...> wrote:
> Okay good. If anyone else does not have objections or points, can we
> conclude we use the MIT license? Someone post a verbatim copy of the license
> here so I can include it to my GLM sources, please.
>
> On Mon, Aug 25, 2008 at 9:57 PM, Jason McKesson <ko...@gm...> wrote:
>>
>> zlib (or generally, the MIT license) is usually my default open source
>> license, so I'm fine with it. It's also compatible with libpng, glfw,
>> and many other utility libraries we might be interested in using.
>>
>> On Mon, Aug 25, 2008 at 10:39 AM, Henri Häkkinen <hen...@gm...>
>> wrote:
>> > Yes indeed we need.
>> >
>> > I am fine with the zlib-like license. We could also make a modified
>> > license
>> > of our own, based on it.
>> >
>> > On Mon, Aug 25, 2008 at 7:21 PM, Branan Riley <br...@gm...> wrote:
>> >>
>> >> We've got several files in SVN now with a "TODO: license" line in the
>> >> header. I think we need to decide on a license for the code.
>> >>
>> >> Normally I'm a GPL advocate, but in this case we need to be concerned
>> >> with what's best for OpenGL, and I think the GPL is too restrictive in
>> >> this case. The dynamic-linking requirement of the LGPL is also
>> >> restrictive, especially for the math library (which needs to be
>> >> higher-performance than dynamic linking allows).
>> >>
>> >> I think in this case the zlib/libpng license is a good choice, for a
>> >> couple of reasons.
>> >>
>> >> 1) No usage restrictions. Anyone can use the code for anything.
>> >> 2) Simple to read and understand.
>> >>
>> >> We don't need to decide this immediately, but we should do it soon.
>> >> Hopefully we'll have all the baseline code (GLS, GLM, GLE, contexts,
>> >> and textures) finished within a couple of weeks. I'd like to do a
>> >> "preview release" of the SDK with just those libraries once they're
>> >> ready. We definitely need a license figured out before then.
>> >>
>> >> Branan
>> >>
>> >>
>> >> -------------------------------------------------------------------------
>> >> 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
>> >
>> >
>> >
>> > -------------------------------------------------------------------------
>> > 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
>> >
>> >
>>
>> -------------------------------------------------------------------------
>> 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
>
>
> -------------------------------------------------------------------------
> 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
>
>

Re: [Glsdk-devel] License

[Mars_999 <ma...@si...>]

The MIT License

Copyright (c) <year> <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.





  ----- Original Message ----- 
  From: Henri Häkkinen 
  To: gls...@li... 
  Sent: Monday, August 25, 2008 2:07 PM
  Subject: Re: [Glsdk-devel] License


  Okay good. If anyone else does not have objections or points, can we conclude we use the MIT license? Someone post a verbatim copy of the license here so I can include it to my GLM sources, please.


  On Mon, Aug 25, 2008 at 9:57 PM, Jason McKesson <ko...@gm...> wrote:

    zlib (or generally, the MIT license) is usually my default open source
    license, so I'm fine with it. It's also compatible with libpng, glfw,
    and many other utility libraries we might be interested in using.


    On Mon, Aug 25, 2008 at 10:39 AM, Henri Häkkinen <hen...@gm...> wrote:
    > Yes indeed we need.
    >
    > I am fine with the zlib-like license. We could also make a modified license
    > of our own, based on it.
    >
    > On Mon, Aug 25, 2008 at 7:21 PM, Branan Riley <br...@gm...> wrote:
    >>
    >> We've got several files in SVN now with a "TODO: license" line in the
    >> header. I think we need to decide on a license for the code.
    >>
    >> Normally I'm a GPL advocate, but in this case we need to be concerned
    >> with what's best for OpenGL, and I think the GPL is too restrictive in
    >> this case. The dynamic-linking requirement of the LGPL is also
    >> restrictive, especially for the math library (which needs to be
    >> higher-performance than dynamic linking allows).
    >>
    >> I think in this case the zlib/libpng license is a good choice, for a
    >> couple of reasons.
    >>
    >> 1) No usage restrictions. Anyone can use the code for anything.
    >> 2) Simple to read and understand.
    >>
    >> We don't need to decide this immediately, but we should do it soon.
    >> Hopefully we'll have all the baseline code (GLS, GLM, GLE, contexts,
    >> and textures) finished within a couple of weeks. I'd like to do a
    >> "preview release" of the SDK with just those libraries once they're
    >> ready. We definitely need a license figured out before then.
    >>
    >> Branan
    >>
    >> -------------------------------------------------------------------------
    >> 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
    >
    >
    > -------------------------------------------------------------------------
    > 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
    >
    >

    -------------------------------------------------------------------------
    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




------------------------------------------------------------------------------


  -------------------------------------------------------------------------
  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

Re: [Glsdk-devel] [GLm] api

[Mars_999 <ma...@si...>]

I haven't looked at the lib yet, but aren't we just going to work with floats all the time? 

glmVec2Sub
glmVec3Sub
glmVec4Sub

glmVec2Add
glmVec3Add
glmVec4Add

glmVec2Mul
glmVec2Div

glmVec2Norm
glmVec2Transf
glmVec3Cross
glmVec3Dot

I like that format...
  ----- Original Message ----- 
  From: Henri Häkkinen 
  To: glsdk-devel 
  Sent: Monday, August 25, 2008 2:04 PM
  Subject: [Glsdk-devel] [GLm] api


  The GLM API seems at this moment to use two sets of naming styles. Compare these two for example:

  glmVecSub2f
  glmVecLength2f

  The first function is using a short form for the operation ('sub' as from 'substract') while the other is using long form. Should we simplify the API to look like this:

  glmVecSub2f
  glmVecLen2f

  Althought on the other hand, how do we shorten such stuff as Normalize, Transform, Identity, Inverse? This does not necessary look good:

  glmVecNorm
  glmVecTrans
  glmMatTrans
  glmMatInv
  glmMatIdent

  Is this even a big issue? Comments?

  If we decide to keep the API as it is now, I think we should lock it in and begin to outline the API reference for it. For later versions, I would like to implement such stuff as colors, quaternions and maybe planes and matrix stacks but this can wait. Bigger priority is to get the current version working and tested for.

  For Korval: I outlined some API ref in a plain text format. You may find it in 'docs/sdk_reference/glm-apiref' in the latest revision. You may use this as ideas for the DocBook API ref and this file needs to get removed once you migrate it into DocBook.

  -- 
  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

Re: [Glsdk-devel] util. lib brainstorming

[<gl...@mo...>]

> 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.

I'd vote against. Let's try not to start our work by just putting more and
more work on ourselves ;)
Having support from GLFW author(s) would be nice though. I'd keep the
library as it is and extend it to support OpenGL 3.0. That's it.


Going back to general discussion.
I'll focus on things that I believe haven't been decided yet.

1. Math
It's Henri's lib for most of tutorial/sample stuff and possibly my lib for
tech demos only (these meant to show capabilities of OpenGL).

However if people will prefer to use other math lib, then mine should be
excluded from SDK. Three is a crowd.



2. Platform abstraction
I'm all for GLFW here. Anyway we have to make decision soon enough.



3. Texture library
I'm using FreeImage and I'm a happy man ;) Too bad it doesn't have it's
own namespace though.

> // load image and return it as texture
> GLuint gltLoadTexture (const char *filename);
>
> // load image, convert it to the given format and return as texture
> GLuint gltLoadTexture2 (const char *filename, GLenum format);
>
> // load from a buffer
> GLuint gltLoadBuf (const GLvoid *buf, GLsizei size);

I strongly object the idea of wrapping glTexImage.
Let's just provide a way to load/store/free image. Uploading to OpenGL
should be done without hepler functions. Don't forget that we're teaching
OpenGL here ;)

This library should come with some basic texture package like brickwalls,
normalmaps, environment cubemaps (some in float format) and some textures
for teaching alpha blending and alpha testing.



4. Shader library

I also suggest limiting this part to helper functions for loading shader
from file and a structure to store shader code. We should teach people to
create programs, shaders and bind them together. Otherwise we're not
teaching them how to use OpenGL but our helper functions.

What shader library should really be is... shader library :)
But I guess that's obvious.


So, our TODO list extends by textures, shaders and some meshes later.


Since I can't find ehough time recently and things tend to get even worse
I'm not declaring to be of any help - I'll just focus on my math library
for now.

Cheers.

Re: [Glsdk-devel] License

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

Okay good. If anyone else does not have objections or points, can we
conclude we use the MIT license? Someone post a verbatim copy of the license
here so I can include it to my GLM sources, please.

On Mon, Aug 25, 2008 at 9:57 PM, Jason McKesson <ko...@gm...> wrote:

> zlib (or generally, the MIT license) is usually my default open source
> license, so I'm fine with it. It's also compatible with libpng, glfw,
> and many other utility libraries we might be interested in using.
>
> On Mon, Aug 25, 2008 at 10:39 AM, Henri Häkkinen <hen...@gm...>
> wrote:
> > Yes indeed we need.
> >
> > I am fine with the zlib-like license. We could also make a modified
> license
> > of our own, based on it.
> >
> > On Mon, Aug 25, 2008 at 7:21 PM, Branan Riley <br...@gm...> wrote:
> >>
> >> We've got several files in SVN now with a "TODO: license" line in the
> >> header. I think we need to decide on a license for the code.
> >>
> >> Normally I'm a GPL advocate, but in this case we need to be concerned
> >> with what's best for OpenGL, and I think the GPL is too restrictive in
> >> this case. The dynamic-linking requirement of the LGPL is also
> >> restrictive, especially for the math library (which needs to be
> >> higher-performance than dynamic linking allows).
> >>
> >> I think in this case the zlib/libpng license is a good choice, for a
> >> couple of reasons.
> >>
> >> 1) No usage restrictions. Anyone can use the code for anything.
> >> 2) Simple to read and understand.
> >>
> >> We don't need to decide this immediately, but we should do it soon.
> >> Hopefully we'll have all the baseline code (GLS, GLM, GLE, contexts,
> >> and textures) finished within a couple of weeks. I'd like to do a
> >> "preview release" of the SDK with just those libraries once they're
> >> ready. We definitely need a license figured out before then.
> >>
> >> Branan
> >>
> >>
> -------------------------------------------------------------------------
> >> 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
> >
> >
> > -------------------------------------------------------------------------
> > 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
> >
> >
>
> -------------------------------------------------------------------------
> 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

Re: [Glsdk-devel] util. lib brainstorming

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

Sounds good!

On Mon, Aug 25, 2008 at 9:55 PM, Jason McKesson <ko...@gm...> wrote:

> I agree that extension loading should be a separate operation from
> window creation/management.
>
> And yes, I'm still working on it, but it'll take some time. I'll
> probably have something to check in by the end of this weekend.
> Granted, it won't be 3.0 compatible, but we'll get there once the new
> .spec files come online.
>
> On Mon, Aug 25, 2008 at 11:31 AM, Henri Häkkinen <hen...@gm...>
> wrote:
> >
> >
> > On Mon, Aug 25, 2008 at 9:10 PM, Mars_999 <ma...@si...> wrote:
> >>
> >> 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.
> >>
> >
> > It was just a thought.
> >
> > At the moment, we are not concerned with the windowlib yet (me and branan
> > are the only active developers yet and we have our hands full, I think
> > Korval may be working on GLE but we haven't heard from it in some days).
> I
> > think it would be a better idea to separate the GLE (our proposed extlib)
> > and GLW (our proposed windowlib), but the GLW may directly call GLE. This
> > allows the possibility to use GLE as a separate library also. Things are
> > open for debate...
> >
> >>
> >> ----- 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
> >>
> >>
> -------------------------------------------------------------------------
> >> 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
> >
> >
> > -------------------------------------------------------------------------
> > 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
> >
> >
>
> -------------------------------------------------------------------------
> 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

[Glsdk-devel] [GLm] api

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

The GLM API seems at this moment to use two sets of naming styles. Compare
these two for example:

glmVecSub2f
glmVecLength2f

The first function is using a short form for the operation ('sub' as from
'substract') while the other is using long form. Should we simplify the API
to look like this:

glmVecSub2f
glmVecLen2f

Althought on the other hand, how do we shorten such stuff as Normalize,
Transform, Identity, Inverse? This does not necessary look good:

glmVecNorm
glmVecTrans
glmMatTrans
glmMatInv
glmMatIdent

Is this even a big issue? Comments?

If we decide to keep the API as it is now, I think we should lock it in and
begin to outline the API reference for it. For later versions, I would like
to implement such stuff as colors, quaternions and maybe planes and matrix
stacks but this can wait. Bigger priority is to get the current version
working and tested for.

For Korval: I outlined some API ref in a plain text format. You may find it
in 'docs/sdk_reference/glm-apiref' in the latest revision. You may use this
as ideas for the DocBook API ref and this file needs to get removed once you
migrate it into DocBook.

-- 
Henri 'henux' Häkkinen

Re: [Glsdk-devel] License

[Jason M. <ko...@gm...>]

zlib (or generally, the MIT license) is usually my default open source
license, so I'm fine with it. It's also compatible with libpng, glfw,
and many other utility libraries we might be interested in using.

On Mon, Aug 25, 2008 at 10:39 AM, Henri Häkkinen <hen...@gm...> wrote:
> Yes indeed we need.
>
> I am fine with the zlib-like license. We could also make a modified license
> of our own, based on it.
>
> On Mon, Aug 25, 2008 at 7:21 PM, Branan Riley <br...@gm...> wrote:
>>
>> We've got several files in SVN now with a "TODO: license" line in the
>> header. I think we need to decide on a license for the code.
>>
>> Normally I'm a GPL advocate, but in this case we need to be concerned
>> with what's best for OpenGL, and I think the GPL is too restrictive in
>> this case. The dynamic-linking requirement of the LGPL is also
>> restrictive, especially for the math library (which needs to be
>> higher-performance than dynamic linking allows).
>>
>> I think in this case the zlib/libpng license is a good choice, for a
>> couple of reasons.
>>
>> 1) No usage restrictions. Anyone can use the code for anything.
>> 2) Simple to read and understand.
>>
>> We don't need to decide this immediately, but we should do it soon.
>> Hopefully we'll have all the baseline code (GLS, GLM, GLE, contexts,
>> and textures) finished within a couple of weeks. I'd like to do a
>> "preview release" of the SDK with just those libraries once they're
>> ready. We definitely need a license figured out before then.
>>
>> Branan
>>
>> -------------------------------------------------------------------------
>> 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
>
>
> -------------------------------------------------------------------------
> 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
>
>

Re: [Glsdk-devel] util. lib brainstorming

[Jason M. <ko...@gm...>]

I agree that extension loading should be a separate operation from
window creation/management.

And yes, I'm still working on it, but it'll take some time. I'll
probably have something to check in by the end of this weekend.
Granted, it won't be 3.0 compatible, but we'll get there once the new
.spec files come online.

On Mon, Aug 25, 2008 at 11:31 AM, Henri Häkkinen <hen...@gm...> wrote:
>
>
> On Mon, Aug 25, 2008 at 9:10 PM, Mars_999 <ma...@si...> wrote:
>>
>> 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.
>>
>
> It was just a thought.
>
> At the moment, we are not concerned with the windowlib yet (me and branan
> are the only active developers yet and we have our hands full, I think
> Korval may be working on GLE but we haven't heard from it in some days). I
> think it would be a better idea to separate the GLE (our proposed extlib)
> and GLW (our proposed windowlib), but the GLW may directly call GLE. This
> allows the possibility to use GLE as a separate library also. Things are
> open for debate...
>
>>
>> ----- 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
>>
>> -------------------------------------------------------------------------
>> 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
>
>
> -------------------------------------------------------------------------
> 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
>
>

Re: [Glsdk-devel] util. lib brainstorming

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

On Mon, Aug 25, 2008 at 9:10 PM, Mars_999 <ma...@si...> wrote:

>  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.
>
>

It was just a thought.

At the moment, we are not concerned with the windowlib yet (me and branan
are the only active developers yet and we have our hands full, I think
Korval may be working on GLE but we haven't heard from it in some days). I
think it would be a better idea to separate the GLE (our proposed extlib)
and GLW (our proposed windowlib), but the GLW may directly call GLE. This
allows the possibility to use GLE as a separate library also. Things are
open for debate...


>  ----- Original Message -----
> *From:* Henri Häkkinen <hen...@gm...>
> *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
>
>
> -------------------------------------------------------------------------
> 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

Re: [Glsdk-devel] util. lib brainstorming

[Mars_999 <ma...@si...>]

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

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

Re: [Glsdk-devel] License

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

Yes indeed we need.

I am fine with the zlib-like license. We could also make a modified license
of our own, based on it.

On Mon, Aug 25, 2008 at 7:21 PM, Branan Riley <br...@gm...> wrote:

> We've got several files in SVN now with a "TODO: license" line in the
> header. I think we need to decide on a license for the code.
>
> Normally I'm a GPL advocate, but in this case we need to be concerned
> with what's best for OpenGL, and I think the GPL is too restrictive in
> this case. The dynamic-linking requirement of the LGPL is also
> restrictive, especially for the math library (which needs to be
> higher-performance than dynamic linking allows).
>
> I think in this case the zlib/libpng license is a good choice, for a
> couple of reasons.
>
> 1) No usage restrictions. Anyone can use the code for anything.
> 2) Simple to read and understand.
>
> We don't need to decide this immediately, but we should do it soon.
> Hopefully we'll have all the baseline code (GLS, GLM, GLE, contexts,
> and textures) finished within a couple of weeks. I'd like to do a
> "preview release" of the SDK with just those libraries once they're
> ready. We definitely need a license figured out before then.
>
> Branan
>
> -------------------------------------------------------------------------
> 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

[Glsdk-devel] License

[Branan R. <br...@gm...>]

We've got several files in SVN now with a "TODO: license" line in the
header. I think we need to decide on a license for the code.

Normally I'm a GPL advocate, but in this case we need to be concerned
with what's best for OpenGL, and I think the GPL is too restrictive in
this case. The dynamic-linking requirement of the LGPL is also
restrictive, especially for the math library (which needs to be
higher-performance than dynamic linking allows).

I think in this case the zlib/libpng license is a good choice, for a
couple of reasons.

1) No usage restrictions. Anyone can use the code for anything.
2) Simple to read and understand.

We don't need to decide this immediately, but we should do it soon.
Hopefully we'll have all the baseline code (GLS, GLM, GLE, contexts,
and textures) finished within a couple of weeks. I'd like to do a
"preview release" of the SDK with just those libraries once they're
ready. We definitely need a license figured out before then.

Branan

Re: [Glsdk-devel] util. lib brainstorming

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

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

Re: [Glsdk-devel] util. lib brainstorming

[Stefanos A. <sta...@gm...>]

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.