glsdk-devel — Main development list for the OpenGL SDK

Re: [Glsdk-devel] SourceForge permissions

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

One more thing: What do you intend to do in the project. Just give me
a plain-text description, and I'll pick the best match from the
SourceForge "Role" options. It's not really important (it doesn't
affect any permissions), but it's an easy reference of who to bug for
what.

Thanks,
Branan

[Glsdk-devel] SourceForge permissions

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

I think we're at a point now where we have a good core team (Henri,
Korval, and myself, possilbe Rob (depending on how involved he wants
to be)).

The four of us currently have full admin permissions on the project,
meaning we can change everything. Additionally, I made sure that
Korval, Henri, and myself have full admin premissions on the trackers
(I didn't add Rob, so I'm not sure what his permissions are set to in
that regard).


So, to all: What trackers do you want access to, and do you want to be
a technician (items can be assigned to you) or an admin (you can
assign items, &c). Currently we have four trackers: Bugs, Patches,
Support, and Feature Requests.

And to Rob: Do you think you'll need full admin privalages? if not I
can send you an email with all the different permissions
possibilities, and I can set those up for you.


Thanks everyone,
Branan

Re: [Glsdk-devel] Update on extension loading

[Robert B. <RB...@bl...>]

I'll ask Mr. Leech what the plan is for getting those ready.


-----Original Message-----
From: gls...@li... on behalf of Jason McKesson
Sent: Sat 8/23/2008 3:38 PM
To: gls...@li...
Subject: [Glsdk-devel] Update on extension loading
 
I've looked a bit closer at the .spec files from the ARB, and there is a 
problem. Not an entirely insurmountable one, but non-trivial.

The .spec files that deal with enumerations are quite complete. The 
problem is that the .spec files for /functions/ are not. They do not 
have the GL 3.0-specific entrypoints, and they don't even have the new 
core ARB extensions.

What that means is that, to support a GL 3.0 context, we need to either 
wait for updated .spec files or collate a list of functions by hand 
(including vital extensions like WGL_ARB_context_create). Any ideas?

Re: [Glsdk-devel] Geometry generation

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

There's no point passing a *out variable. The generation function has
to allocate memory for the structure members anyway, so it may as well
allocate the whole structure.

And if we return a structure like that, do we have a glsDrawShape()
function, or do we make the user draw it?

On Sat, Aug 23, 2008 at 4:37 PM, Henri Häkkinen <hen...@gm...> wrote:
>
>
> On Sun, Aug 24, 2008 at 2:21 AM, Branan Riley <br...@gm...> wrote:
>>
>> I'm going to start on geometry generation functions. I think sphere,
>> cube, cylinder, and cone are good to start with.
>>
>> I do have a couple questions about how we want to use these, though.
>>
>> 1) Should they return data in a pre-defined format, so that the user
>> has to set up the VBOs to send the data (reinforcing the steps needed
>> to get geometry to the GL), or should they handle it automatically (to
>> make things simpler for code that's demonstrating shader effects)
>>
>> 2) What should the prefix be? I'm thinking gls for "OpenGL Shape"
>>
>> 3) If we want to have it return data, what's a good format for the data?
>>
>
> I propose a some sort structure or an object which the functions return.
>
> typedef struct GLSshape_s {
>   ...
> } GLSshape;
>
> void glsCreateSphere (GLSshape *out, GLfloat radius);
> ...
>
> Members are public so that the caller may directly access them. We could
> later extend this library to load .obj files.
>
>>
>> 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] Geometry generation

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

On Sun, Aug 24, 2008 at 2:21 AM, Branan Riley <br...@gm...> wrote:

> I'm going to start on geometry generation functions. I think sphere,
> cube, cylinder, and cone are good to start with.
>

> I do have a couple questions about how we want to use these, though.
>
> 1) Should they return data in a pre-defined format, so that the user
> has to set up the VBOs to send the data (reinforcing the steps needed
> to get geometry to the GL), or should they handle it automatically (to
> make things simpler for code that's demonstrating shader effects)
>
> 2) What should the prefix be? I'm thinking gls for "OpenGL Shape"
>
> 3) If we want to have it return data, what's a good format for the data?
>
>
I propose a some sort structure or an object which the functions return.

typedef struct GLSshape_s {
  ...
} GLSshape;

void glsCreateSphere (GLSshape *out, GLfloat radius);
...

Members are public so that the caller may directly access them. We could
later extend this library to load .obj files.


>
> 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] Geometry generation

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

I'm going to start on geometry generation functions. I think sphere,
cube, cylinder, and cone are good to start with.

I do have a couple questions about how we want to use these, though.

1) Should they return data in a pre-defined format, so that the user
has to set up the VBOs to send the data (reinforcing the steps needed
to get geometry to the GL), or should they handle it automatically (to
make things simpler for code that's demonstrating shader effects)

2) What should the prefix be? I'm thinking gls for "OpenGL Shape"

3) If we want to have it return data, what's a good format for the data?


Branan

Re: [Glsdk-devel] Update on extension loading

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

We can ask the ARB guys if they can give us an ETA on .spec files.
Seems like it's probably one of those things they consider to be
lower-priority.

It's also possible that NVIDIA or AMD have there own .spec files, and
they might be willing to share.

If both of those fail, we'll need to do it ourselves.

Branan


On Sat, Aug 23, 2008 at 3:38 PM, Jason McKesson <ko...@gm...> wrote:
> I've looked a bit closer at the .spec files from the ARB, and there is a
> problem. Not an entirely insurmountable one, but non-trivial.
>
> The .spec files that deal with enumerations are quite complete. The problem
> is that the .spec files for functions are not. They do not have the GL
> 3.0-specific entrypoints, and they don't even have the new core ARB
> extensions.
>
> What that means is that, to support a GL 3.0 context, we need to either wait
> for updated .spec files or collate a list of functions by hand (including
> vital extensions like WGL_ARB_context_create). Any ideas?
> -------------------------------------------------------------------------
> 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] The use of anonymous structures

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

Thanks for this info. As you can see, the exact mathlib interface is still
in a state of flux.

On Sun, Aug 24, 2008 at 1:24 AM, Orhun Birsoy <orh...@gm...> wrote:

> Hi,
>
> I just wanted to note that anonymous unions generate the following warning
> in Visual C++ (9.0) at warning level 4.
>
> glsdk\trunk\inc\GLSDK/glm.h(19) : warning C4201: nonstandard extension used
> : nameless struct/union
>
>
> It might be early to report such problems but I had to make several changes
> to make glm.c compile with Visual C++.
>
> - windows.h has to be included before glm.h.
> - I had to define _USE_MATH_DEFINES to have M_PI defined.
>  . From MSDN
> > The "Math Constants" are not defined in Standard C/C++. Therefore, in
> order to use them, you have to first define _USE_MATH_DEFINES and then
> include cmath or math.h as below.
>
> --
> Orhun Birsoy
>
> -------------------------------------------------------------------------
> 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] The use of anonymous structures

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

Okay, lets discuss on this matter. I have written the library with the
implementation of using struct/union approach as I thought this was the
implementation we decided on in the forums.

We have multiple approaches:

Proposal #1: the array approach

typedef GLfloat GLMvec2f[2];

void glmVecSet2f (GLMvec2f out, GLfloat x, GLfloat y);
void glmVecAdd2f (GLMvec2f out, const GLMvec2f v1, const GLMvec2f v2);

This allows the user code to call like this:

GLMvec2f a, b, c;
glmVecSet2f (a, 1.0f, 1.0f);
glmVecSet2f (b, 2.0f, 2.0f);
glmVecAdd2f (c, a, b);

However GCC will generate warnings on args 2 and 3 for glmVecAdd2f.

We cannot define glmVecSet2f like this:

GLMvec2f glmVecSet2f (GLMvec2f out, GLfloat x, GLfloat y);

This is impossible because functions cannot return arrays. The bad side of
this approach is that function calls cannot be nested like this:

glmVecAdd2f (c, glmVecSet2f (a, 1.0f, 1.0f), glmVecSet2f (b, 2.0f, 2.0f));


Proposal #2: struct/union approach (the current implementation)

typedef struct GLMvec2f_s {
  union {
    GLfloat v[2];
    struct GLMvec2f_data_s {
      GLfloat x, y;
    };
  };
} GLMvec2f;

GLMvec2f *glmVecSet2f (GLMvec2f *out, GLfloat x, GLfloat y);
GLMvec2f *glmVecAdd2f (GLMvec2f *out, const GLMvec2f *v1, const GLMvec2f
*v2);

This allows function calls to be nested:

GLMvec2f a, b, c;
glmVecAdd2f (&c, glmVecSet2f (&a, 1.0f, 1.0f), glmVecSet2f (&b, 2.0f,
2.0f));

Data can be also passed directly to OpenGL functions:

GLMmat4f mat;
glmMatIdentity4f (&mat);
glLoadMatrixf (mat.m);
(or some equivalent GL3 API call)

Member can also be accessed by a moniker:

mat.m11 = 1.0f;
vec.x = 2.0f;
col.r = 0.5f;

As a sidenote, this is also how they do this in D3DX (the util library of
D3D).

The only con is the use of union, but I don't see this as a problem. They
are not particularly complicated either IMO.


Proposal #3: the struct-only approach

struct GLMvec2f_s {
  GLfloat x, y;
} GLMvec2f;

GLMvec2f *glmVecSet2f (GLMvec2f *out, GLfloat x, GLfloat y);
GLMvec2f *glmVecAdd2f (GLMvec2f *out, const GLMvec2f *v1, const GLMvec2f
*v2);

This is almost the same as #2 except that avoidance of unions.

I would go with the struct/union.



On Sun, Aug 24, 2008 at 1:22 AM, Jason McKesson <ko...@gm...> wrote:

>  Henri Häkkinen wrote:
>
> No no... We had this conversation already in the forums few days ago.
>
> The struct approach is superior over typedef GLfloat GLMmat2f[4]; for the
> following reason:
>
> - it allows matrix data to be accessed as either using index or members.
> You can see the memory layout of the matrix from the ordering of the mXX
> members.
>
> - the following piece of code:
>
> typedef float FOO[2];
>
> FOO *test (FOO *out, const FOO *f)
> {
>   (*out)[0] = (*f)[0];
>   (*out)[1] = (*f)[1];
>   return out;
> }
>
> The function "test" should not take pointers. Objects of type "FOO" already
> are pointers, so it does not need to take FOO*'s.
>
>

>  int main ()
> {
>   FOO a, b;
>   test (&a, &b);
>   return 0;
> }
>
>
> Produces the following warning on GCC 4.2.3:
> warning: passing argument 2 of 'test' from incompatible pointer type
>
> Which is why virtually every book on programming tells you *not* to define
> multiple variables on the same line.
>


This has nothing to do how the variables are declared, but how the function
test is called.



>
>  Compare this:
>
> typedef struct {
>   union {
>     float f[2];
>     struct {
>       float x, y;
>     };
>   };
> } FOO;
>
> FOO *test (FOO *out, const FOO *f)
> {
>   out->x = f->x;
>   out->y = f->y;
>   return out;
> }
>
> I don't like the idea of these functions all taking pointers to the types
> rather than the types themselves. I know C doesn't have an equivalent to the
> & reference in C++, but the user code would be a lot cleaner if you only
> passed pointers for parameters that are outputs (or large objects). That's
> the general convention for most C libraries I've seen.
>


But it is also a lot more efficient to pass them as pointers.



>
>  This code is a lot more clear and usable than the previous one. Also:
>
> vec[0] = -vec[0];
>
> You cannot be sure if this vec is an array of vectors or are you accessing
> the first element of a 2D vector.
>
> Implementing math datatypes as structure is a lot more cleaner approach
> than the array approach. Perhaps we should think if the union there is
> redundant but typedef GLfloat GLMvec2f[2]; is not a good idea. And I don't
> think we should hinder our design by the assumed ignorance of the
> afromentioned newbies. Besides, I have already implemented the library by
> the struct approach design. See the OpenGL forums for the discussion we
> underwent there fore more points.
>
> If you feel that the math types should be structs, then let them be struct.
> But they should *not* be structs containing a union of an array and a
> struct. That violates principle #2: simplicity. A principle you agreed on,
> as you previously stated. Simplicity means you pick one side: struct or
> array.
>
> -------------------------------------------------------------------------
> 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] Update on extension loading

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

I've looked a bit closer at the .spec files from the ARB, and there is a 
problem. Not an entirely insurmountable one, but non-trivial.

The .spec files that deal with enumerations are quite complete. The 
problem is that the .spec files for /functions/ are not. They do not 
have the GL 3.0-specific entrypoints, and they don't even have the new 
core ARB extensions.

What that means is that, to support a GL 3.0 context, we need to either 
wait for updated .spec files or collate a list of functions by hand 
(including vital extensions like WGL_ARB_context_create). Any ideas?

Re: [Glsdk-devel] The use of anonymous structures

[Orhun B. <orh...@gm...>]

Hi,

I just wanted to note that anonymous unions generate the following warning
in Visual C++ (9.0) at warning level 4.

glsdk\trunk\inc\GLSDK/glm.h(19) : warning C4201: nonstandard extension used
: nameless struct/union


It might be early to report such problems but I had to make several changes
to make glm.c compile with Visual C++.

- windows.h has to be included before glm.h.
- I had to define _USE_MATH_DEFINES to have M_PI defined.
 . From MSDN
> The "Math Constants" are not defined in Standard C/C++. Therefore, in
order to use them, you have to first define _USE_MATH_DEFINES and then
include cmath or math.h as below.

-- 
Orhun Birsoy

Re: [Glsdk-devel] The use of anonymous structures

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

Henri Häkkinen wrote:
> No no... We had this conversation already in the forums few days ago.
>
> The struct approach is superior over typedef GLfloat GLMmat2f[4]; for 
> the following reason:
>
> - it allows matrix data to be accessed as either using index or 
> members. You can see the memory layout of the matrix from the ordering 
> of the mXX members.
>
> - the following piece of code:
>
> typedef float FOO[2];
>
> FOO *test (FOO *out, const FOO *f)
> {
>   (*out)[0] = (*f)[0];
>   (*out)[1] = (*f)[1];
>   return out;
> }
The function "test" should not take pointers. Objects of type "FOO" 
already are pointers, so it does not need to take FOO*'s.
> int main ()
> {
>   FOO a, b;
>   test (&a, &b);
>   return 0;
> }
>
> Produces the following warning on GCC 4.2.3:
> warning: passing argument 2 of 'test' from incompatible pointer type
Which is why virtually every book on programming tells you /not/ to 
define multiple variables on the same line.
> Compare this:
>
> typedef struct {
>   union {
>     float f[2];
>     struct {
>       float x, y;
>     };
>   };
> } FOO;
>
> FOO *test (FOO *out, const FOO *f)
> {
>   out->x = f->x;
>   out->y = f->y;
>   return out;
> }
I don't like the idea of these functions all taking pointers to the 
types rather than the types themselves. I know C doesn't have an 
equivalent to the & reference in C++, but the user code would be a lot 
cleaner if you only passed pointers for parameters that are outputs (or 
large objects). That's the general convention for most C libraries I've 
seen.
> This code is a lot more clear and usable than the previous one. Also:
>
> vec[0] = -vec[0];
>
> You cannot be sure if this vec is an array of vectors or are you 
> accessing the first element of a 2D vector.
>
> Implementing math datatypes as structure is a lot more cleaner 
> approach than the array approach. Perhaps we should think if the union 
> there is redundant but typedef GLfloat GLMvec2f[2]; is not a good 
> idea. And I don't think we should hinder our design by the assumed 
> ignorance of the afromentioned newbies. Besides, I have already 
> implemented the library by the struct approach design. See the OpenGL 
> forums for the discussion we underwent there fore more points.
If you feel that the math types should be structs, then let them be 
struct. But they should /not/ be structs containing a union of an array 
and a struct. That violates principle #2: simplicity. A principle you 
agreed on, as you previously stated. Simplicity means you pick one side: 
struct or array.

Re: [Glsdk-devel] The use of anonymous structures

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

I don't think the problem is in structs, it's in a union of
struct/array that makes things complicated.

Having mat2f defined as:

typedef struct GLMmat2f_t
{
float m00, m01, m10, m11;
} GLMmat2f;

is perfectly fine. It's the union that's complicated and confusing.

Branan

On Sat, Aug 23, 2008 at 2:32 PM, Henri Häkkinen <hen...@gm...> wrote:
> No no... We had this conversation already in the forums few days ago.
>
> The struct approach is superior over typedef GLfloat GLMmat2f[4]; for the
> following reason:
>
> - it allows matrix data to be accessed as either using index or members. You
> can see the memory layout of the matrix from the ordering of the mXX
> members.
>
> - the following piece of code:
>
> typedef float FOO[2];
>
> FOO *test (FOO *out, const FOO *f)
> {
>   (*out)[0] = (*f)[0];
>   (*out)[1] = (*f)[1];
>   return out;
> }
>
> int main ()
> {
>   FOO a, b;
>   test (&a, &b);
>   return 0;
> }
>
> Produces the following warning on GCC 4.2.3:
> warning: passing argument 2 of 'test' from incompatible pointer type
>
> Compare this:
>
> typedef struct {
>   union {
>     float f[2];
>     struct {
>       float x, y;
>     };
>   };
> } FOO;
>
> FOO *test (FOO *out, const FOO *f)
> {
>   out->x = f->x;
>   out->y = f->y;
>   return out;
> }
>
> This code is a lot more clear and usable than the previous one. Also:
>
> vec[0] = -vec[0];
>
> You cannot be sure if this vec is an array of vectors or are you accessing
> the first element of a 2D vector.
>
> Implementing math datatypes as structure is a lot more cleaner approach than
> the array approach. Perhaps we should think if the union there is redundant
> but typedef GLfloat GLMvec2f[2]; is not a good idea. And I don't think we
> should hinder our design by the assumed ignorance of the afromentioned
> newbies. Besides, I have already implemented the library by the struct
> approach design. See the OpenGL forums for the discussion we underwent there
> fore more points.
>
>
> On Sun, Aug 24, 2008 at 12:04 AM, Jason McKesson <ko...@gm...> wrote:
>>
>> Henri Häkkinen wrote:
>>
>> Somebody mentioned in the OpenGL forums that we should avoid the use of
>> anonymous structures. Is this worth the concern?
>>
>> For example, compare these:
>>
>> typedef struct GLMmat2f_s {
>>   union {
>>     GLfloat m[4];
>>     struct GLMmat2fdata_s {
>>       GLfloat m00, m01, m10, m11;
>>     };
>>   };
>> } GLMmat2f;
>>
>> vs.
>>
>> typedef struct {
>>   union {
>>     GLfloat m[4];
>>     struct {
>>       GLfloat m00, m01, m10, m11;
>>     };
>>   };
>> } GLMmat2f;
>>
>> We need to enclose the mXX variables into a struct in order for the union
>> to take them as a whole.
>>
>> --
>> Henri 'henux' Häkkinen
>>
>> I would suggest that those struct definitions violate the design principle
>> of simplicity. You need to pick one: either a matrix is an array of floats
>> or it is a struct with member fields. It should not be both. If you're
>> having to use a union, you've already done something wrong. Unions are
>> confusing and scary to neophyte programmers.
>>
>> I'd prefer that a matrix were defined as:
>>
>> typedef GLfloat[4] GLMmat2f;
>>
>> It's simpler and gets the job done without being confusing to a programmer
>> as to what is going on. Yes, it will need to have conventions associated
>> with it, but that's a small price to pay for the obviousness of what the
>> matrix is doing.
>>
>> -------------------------------------------------------------------------
>> 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] The purpose of the GL SDK

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

I agree 100%.

On Sat, Aug 23, 2008 at 12:15 PM, Jason McKesson <ko...@gm...> wrote:
> Personally, whenever I begin a project of any particular size, the first
> question I ask is what it should do. What is the purpose in creating it. I
> find this useful, as any debate about what should or should not be included
> in the project can usually be cleared up by looking at its purpose. Or, at
> the very least, it is easier to see which alternative fills the purpose
> better than the other.
>
> Normally, I would do this by making a (prioritized) list of goals. However
> for this project, I think it would be easier to list who should want to use
> the GL SDK and for what reasons. The audience for the SDK should drive all
> aspects of the design of the project.
>
> I would say that our audience is two-fold. One section of our audience is
> the "new to OpenGL/graphics" programmer: the neophyte. This is someone who
> decided to do some graphics work, heard about OpenGL, and wants to have a go
> at it. This person cares about seeing something working and learning about
> how and why it is working. This person wants detailed examples, a clear,
> well-documented codebase, and above all, for it to work with as little fuss
> as possible.
>
> The other section of our audience is the hobbiest GL programmer. This is
> someone who may probably has some GL experience. This programmer has some
> understanding of graphics, and may be interested in getting a greater
> understanding. However, the hobbiest differs from the neophyte in a very
> specific way: the hobbiest wants to code something specific. The neophyte
> just wants to learn; the hobbiest wants to implement some form of shadow
> mapping. He is not interested (at the moment) in building a large,
> complicated engine for doing it. He is more interested in getting a specific
> result, interfacing with OpenGL and getting it to do that cool think he
> heard about. The hobbiest wants to make little demo programs that do
> cool-looking things.
>
> The neophyte is interested in examples, tutorials, documentation, and a
> simple, easy-to-use codebase. The hobbiest is interested in comprehensive
> documentation and the functionality of the codebase. Both of them are
> interested in playing with graphics, but the hobbiest knows more about
> graphics and is mostly interested in how to translate some idea into an
> on-screen result.
>
> So the first thing I would put forward is that the GL SDK should serve the
> needs of both of these groups. There's enough overlap, particularly in the
> general code department, that serving both of their needs should be doable
> without much additional effort.
>
> So, given the needs of the above, I would put forth the following as a
> prioritized list of design goals:
>
> Cross-platform. That's a given, as it is OpenGL's primary strength.
> Simple. The code design should be written in a style that can be understood.
> Comprehensive. We should provide full coverage over OpenGL's functionality.
> This means tutorials on lots of different aspects of GL, appropriate base
> code support, etc.
> Well Documented. All code needs to have clear documentation about every
> function, object, etc.
> Easy-to-"Install". I'm not necessarily suggesting a packaged installer
> (though I wouldn't be against it), but the library should be something that
> can be easily installed onto a system. And, most importantly, compiled.
> Generally, that means no external dependencies; that means we ship the
> library with any actual dependencies (if we use libpng, we ship our lib with
> a version of libpng, etc).
> Functionality. To the extent that the prior goals are followed, we should
> provide a base code that gives reasonably comprehensive functionality to the
> user.
>
> So, what do you think?
>
> -------------------------------------------------------------------------
> 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

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

OK, CUnit sounds good. It should be easy enough to integrate into CMake

Branna

On Sat, Aug 23, 2008 at 11:22 AM, Henri Häkkinen <hen...@gm...> wrote:
> Yes, I agree that we should keep the technical discussion in the mailing
> lists. However sometimes we may want to engage into real-time discussions,
> if for nothing else but to say hi to our community, and in that case IRC is
> fine.
>
> I have began to write unit tests for the GLM library and I have chosen CUnit
> framework that.
>
>
> On Sat, Aug 23, 2008 at 8:53 PM, Jason McKesson <ko...@gm...> wrote:
>>
>> Henri Häkkinen wrote:
>> > branan: I assume your registered nick on freenode is 'branan'
>> >
>> > Korval: have you registered into freenode? 'Korval' is not found
>> >
>> No, not really.
>>
>> Personally, I don't find an IRC channel to be an effective method of
>> communication. Particularly for highly technical discussions like these.
>>
>> -------------------------------------------------------------------------
>> 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] The use of anonymous structures

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

No no... We had this conversation already in the forums few days ago.

The struct approach is superior over typedef GLfloat GLMmat2f[4]; for the
following reason:

- it allows matrix data to be accessed as either using index or members. You
can see the memory layout of the matrix from the ordering of the mXX
members.

- the following piece of code:

typedef float FOO[2];

FOO *test (FOO *out, const FOO *f)
{
  (*out)[0] = (*f)[0];
  (*out)[1] = (*f)[1];
  return out;
}

int main ()
{
  FOO a, b;
  test (&a, &b);
  return 0;
}

Produces the following warning on GCC 4.2.3:
warning: passing argument 2 of 'test' from incompatible pointer type

Compare this:

typedef struct {
  union {
    float f[2];
    struct {
      float x, y;
    };
  };
} FOO;

FOO *test (FOO *out, const FOO *f)
{
  out->x = f->x;
  out->y = f->y;
  return out;
}

This code is a lot more clear and usable than the previous one. Also:

vec[0] = -vec[0];

You cannot be sure if this vec is an array of vectors or are you accessing
the first element of a 2D vector.

Implementing math datatypes as structure is a lot more cleaner approach than
the array approach. Perhaps we should think if the union there is redundant
but typedef GLfloat GLMvec2f[2]; is not a good idea. And I don't think we
should hinder our design by the assumed ignorance of the afromentioned
newbies. Besides, I have already implemented the library by the struct
approach design. See the OpenGL forums for the discussion we underwent there
fore more points.


On Sun, Aug 24, 2008 at 12:04 AM, Jason McKesson <ko...@gm...> wrote:

>  Henri Häkkinen wrote:
>
> Somebody mentioned in the OpenGL forums that we should avoid the use of
> anonymous structures. Is this worth the concern?
>
> For example, compare these:
>
> typedef struct GLMmat2f_s {
>   union {
>     GLfloat m[4];
>     struct GLMmat2fdata_s {
>       GLfloat m00, m01, m10, m11;
>     };
>   };
> } GLMmat2f;
>
> vs.
>
> typedef struct {
>   union {
>     GLfloat m[4];
>     struct {
>       GLfloat m00, m01, m10, m11;
>     };
>   };
> } GLMmat2f;
>
> We need to enclose the mXX variables into a struct in order for the union
> to take them as a whole.
>
> --
> Henri 'henux' Häkkinen
>
> I would suggest that those struct definitions violate the design principle
> of *simplicity*. You need to pick one: either a matrix is an array of
> floats or it is a struct with member fields. It should not be both. If
> you're having to use a *union*, you've already done something wrong.
> Unions are confusing and scary to neophyte programmers.
>
> I'd prefer that a matrix were defined as:
>
> typedef GLfloat[4] GLMmat2f;
>
> It's simpler and gets the job done without being confusing to a programmer
> as to what is going on. Yes, it will need to have conventions associated
> with it, but that's a small price to pay for the obviousness of what the
> matrix is doing.
>
> -------------------------------------------------------------------------
> 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] The use of anonymous structures

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

Henri Häkkinen wrote:
> Somebody mentioned in the OpenGL forums that we should avoid the use 
> of anonymous structures. Is this worth the concern?
>
> For example, compare these:
>
> typedef struct GLMmat2f_s {
>   union {
>     GLfloat m[4];
>     struct GLMmat2fdata_s {
>       GLfloat m00, m01, m10, m11;
>     };
>   };
> } GLMmat2f;
>
> vs.
>
> typedef struct {
>   union {
>     GLfloat m[4];
>     struct {
>       GLfloat m00, m01, m10, m11;
>     };
>   };
> } GLMmat2f;
>
> We need to enclose the mXX variables into a struct in order for the 
> union to take them as a whole.
>
> -- 
> Henri 'henux' Häkkinen
I would suggest that those struct definitions violate the design 
principle of /simplicity/. You need to pick one: either a matrix is an 
array of floats or it is a struct with member fields. It should not be 
both. If you're having to use a /union/, you've already done something 
wrong. Unions are confusing and scary to neophyte programmers.

I'd prefer that a matrix were defined as:

typedef GLfloat[4] GLMmat2f;

It's simpler and gets the job done without being confusing to a 
programmer as to what is going on. Yes, it will need to have conventions 
associated with it, but that's a small price to pay for the obviousness 
of what the matrix is doing.

[Glsdk-devel] The use of anonymous structures

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

Somebody mentioned in the OpenGL forums that we should avoid the use of
anonymous structures. Is this worth the concern?

For example, compare these:

typedef struct GLMmat2f_s {
  union {
    GLfloat m[4];
    struct GLMmat2fdata_s {
      GLfloat m00, m01, m10, m11;
    };
  };
} GLMmat2f;

vs.

typedef struct {
  union {
    GLfloat m[4];
    struct {
      GLfloat m00, m01, m10, m11;
    };
  };
} GLMmat2f;

We need to enclose the mXX variables into a struct in order for the union to
take them as a whole.

-- 
Henri 'henux' Häkkinen

Re: [Glsdk-devel] build system

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

Henri Häkkinen wrote:
> That is a good idea too. I have made only one commit which had the 
> message "added glm test suite".
>
> I propose we should use the subproject name enclosed in square 
> brackets at the beginning of the message. So for GLM I would use [GLM] 
> or [glm]. Also we should decide on the format of the commit messages. 
> Should we use complete sentences? How comprehensive messages do we 
> need to use? Do we list each files which are modified and every 
> modification done (the GNU convention)?
>
>
> On Sat, Aug 23, 2008 at 11:16 PM, Jason McKesson <ko...@gm... 
> <mailto:ko...@gm...>> wrote:
>
>     Actually, at work we have certain conventions in terms of what commit
>     messages we use. So, if you're working on animation code, you use
>     "CODE_ANIM", if you're checking in animation work, you use "ANIM", and
>     so forth. If we simply define a set of conventions that we
>     consistently
>     use, we should be able to build a change log for a sub-project
>     directly
>     from the SVN commit messages.
>
>
>
>
> -- 
> Henri 'henux' Häkkinen
>
We should not list the files that were modified: SVN changelists can 
already tell you what files were modified. And the description should be 
sufficient to tell you what those modifications entailed. If any more 
detailed information is necessary, a quick trip to SVN-diff can tell you 
anything more. Taking time to detail every file's revision is highly 
unnecessary.

As for the particular convention, brackets are probably a good idea, 
since they allow a tool to be faster at detecting which modules were 
changed.

Re: [Glsdk-devel] build system

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

That is a good idea too. I have made only one commit which had the message
"added glm test suite".

I propose we should use the subproject name enclosed in square brackets at
the beginning of the message. So for GLM I would use [GLM] or [glm]. Also we
should decide on the format of the commit messages. Should we use complete
sentences? How comprehensive messages do we need to use? Do we list each
files which are modified and every modification done (the GNU convention)?


On Sat, Aug 23, 2008 at 11:16 PM, Jason McKesson <ko...@gm...> wrote:

> Actually, at work we have certain conventions in terms of what commit
> messages we use. So, if you're working on animation code, you use
> "CODE_ANIM", if you're checking in animation work, you use "ANIM", and
> so forth. If we simply define a set of conventions that we consistently
> use, we should be able to build a change log for a sub-project directly
> from the SVN commit messages.
>
> -------------------------------------------------------------------------
> 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] build system

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

Henri Häkkinen wrote:
> Should we adopt the GNU convention of ChangeLog files? Should we keep 
> ChangeLogs per subproject or one ChangeLog for the whole SDK or 
> perhaps both? And where would the per subproject ChangeLogs go?
>
> I think a good idea is to keep per subproject ChangeLogs. And we 
> should make a doc/ directory under the main GLSDK/ dir for subproject 
> specific files. GLM ChangeLog would therefore go to 
> GLSDK/doc/glm/ChangeLog.
>
> What do you think?
>
> BTW, I have adopted a convention to put subproject test suites into 
> test/ directory. You can find the sources for GLM test suite at 
> GLSDK/test/glm.
Actually, at work we have certain conventions in terms of what commit 
messages we use. So, if you're working on animation code, you use 
"CODE_ANIM", if you're checking in animation work, you use "ANIM", and 
so forth. If we simply define a set of conventions that we consistently 
use, we should be able to build a change log for a sub-project directly 
from the SVN commit messages.

Re: [Glsdk-devel] build system

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

Should we adopt the GNU convention of ChangeLog files? Should we keep
ChangeLogs per subproject or one ChangeLog for the whole SDK or perhaps
both? And where would the per subproject ChangeLogs go?

I think a good idea is to keep per subproject ChangeLogs. And we should make
a doc/ directory under the main GLSDK/ dir for subproject specific files.
GLM ChangeLog would therefore go to GLSDK/doc/glm/ChangeLog.

What do you think?

BTW, I have adopted a convention to put subproject test suites into test/
directory. You can find the sources for GLM test suite at GLSDK/test/glm.

On Sat, Aug 23, 2008 at 10:59 PM, Henri Häkkinen <hen...@gm...> wrote:

> Yes okay, I can work with Makefile for now. I will not however commit that
> into the repos, only use it locally.
>
>
> On Sat, Aug 23, 2008 at 10:54 PM, Jason McKesson <ko...@gm...>wrote:
>
>> Henri Häkkinen wrote:
>> > Hello,
>> >
>> > I am now fully working on the GLM test suite and I am using CUnit for
>> > it. We will need to think on the build system which we will be using.
>> > Somebody mentioned CMake? I don't know about this system much or other
>> > systems, so I will lead this up to you completely. I wish someone else
>> > would take this to his/her responsibility. Choosing and implementing
>> > the build system would easy my work as for now I need to manually run
>> > the gcc commands from the terminal every time when I need to compile
>> > something.
>> >
>> > --
>> > Henri 'henux' Häkkinen
>> CMake would be a good choice, since it is fairly easy to use. Though it
>> is problematic in that it requires an additional external download,
>> which is something we should try to minimize.
>>
>> As for you own work, can't you just use a Makefile or something in the
>> interim? I mean, we're still pretty far away from having an initial
>> release, so you should use whatever build process you feel comfortable
>> with.
>>
>> -------------------------------------------------------------------------
>> 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] build system

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

Yes okay, I can work with Makefile for now. I will not however commit that
into the repos, only use it locally.

On Sat, Aug 23, 2008 at 10:54 PM, Jason McKesson <ko...@gm...> wrote:

> Henri Häkkinen wrote:
> > Hello,
> >
> > I am now fully working on the GLM test suite and I am using CUnit for
> > it. We will need to think on the build system which we will be using.
> > Somebody mentioned CMake? I don't know about this system much or other
> > systems, so I will lead this up to you completely. I wish someone else
> > would take this to his/her responsibility. Choosing and implementing
> > the build system would easy my work as for now I need to manually run
> > the gcc commands from the terminal every time when I need to compile
> > something.
> >
> > --
> > Henri 'henux' Häkkinen
> CMake would be a good choice, since it is fairly easy to use. Though it
> is problematic in that it requires an additional external download,
> which is something we should try to minimize.
>
> As for you own work, can't you just use a Makefile or something in the
> interim? I mean, we're still pretty far away from having an initial
> release, so you should use whatever build process you feel comfortable
> with.
>
> -------------------------------------------------------------------------
> 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] The purpose of the GL SDK

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

I think you put it out very clearly and right on the point. I agree on your
views and goals.


On Sat, Aug 23, 2008 at 10:15 PM, Jason McKesson <ko...@gm...> wrote:

>  Personally, whenever I begin a project of any particular size, the first
> question I ask is what it should do. What is the purpose in creating it. I
> find this useful, as any debate about what should or should not be included
> in the project can usually be cleared up by looking at its purpose. Or, at
> the very least, it is easier to see which alternative fills the purpose
> better than the other.
>
> Normally, I would do this by making a (prioritized) list of goals. However
> for this project, I think it would be easier to list who should want to use
> the GL SDK and for what reasons. The audience for the SDK should drive all
> aspects of the design of the project.
>
> I would say that our audience is two-fold. One section of our audience is
> the "new to OpenGL/graphics" programmer: the neophyte. This is someone who
> decided to do some graphics work, heard about OpenGL, and wants to have a go
> at it. This person cares about seeing something working and learning about
> how and why it is working. This person wants detailed examples, a clear,
> well-documented codebase, and above all, for it to work with as little fuss
> as possible.
>
> The other section of our audience is the hobbiest GL programmer. This is
> someone who may probably has some GL experience. This programmer has some
> understanding of graphics, and may be interested in getting a greater
> understanding. However, the hobbiest differs from the neophyte in a very
> specific way: the hobbiest wants to code something specific. The neophyte
> just wants to learn; the hobbiest wants to implement some form of shadow
> mapping. He is not interested (at the moment) in building a large,
> complicated engine for doing it. He is more interested in getting a specific
> result, interfacing with OpenGL and getting it to do that cool think he
> heard about. The hobbiest wants to make little demo programs that do
> cool-looking things.
>
> The neophyte is interested in examples, tutorials, documentation, and a
> simple, easy-to-use codebase. The hobbiest is interested in comprehensive
> documentation and the functionality of the codebase. Both of them are
> interested in playing with graphics, but the hobbiest knows more about
> graphics and is mostly interested in how to translate some idea into an
> on-screen result.
>
> So the first thing I would put forward is that the GL SDK should serve the
> needs of both of these groups. There's enough overlap, particularly in the
> general code department, that serving both of their needs should be doable
> without much additional effort.
>
> So, given the needs of the above, I would put forth the following as a
> prioritized list of design goals:
>
>    1. Cross-platform. That's a given, as it is OpenGL's primary strength.
>    2. Simple. The code design should be written in a style that can be
>    understood.
>     3. Comprehensive. We should provide full coverage over OpenGL's
>    functionality. This means tutorials on lots of different aspects of GL,
>    appropriate base code support, etc.
>    4. Well Documented. All code needs to have clear documentation about
>    every function, object, etc.
>    5. Easy-to-"Install". I'm not necessarily suggesting a packaged
>    installer (though I wouldn't be against it), but the library should be
>    something that can be easily installed onto a system. And, most importantly,
>    *compiled*. Generally, that means no *external* dependencies; that
>    means we ship the library with any actual dependencies (if we use libpng, we
>    ship our lib with a version of libpng, etc).
>     6. Functionality. To the extent that the prior goals are followed, we
>    should provide a base code that gives reasonably comprehensive functionality
>    to the user.
>
> So, what do you think?
>
> -------------------------------------------------------------------------
> 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] build system

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

Henri Häkkinen wrote:
> Hello,
>
> I am now fully working on the GLM test suite and I am using CUnit for 
> it. We will need to think on the build system which we will be using. 
> Somebody mentioned CMake? I don't know about this system much or other 
> systems, so I will lead this up to you completely. I wish someone else 
> would take this to his/her responsibility. Choosing and implementing 
> the build system would easy my work as for now I need to manually run 
> the gcc commands from the terminal every time when I need to compile 
> something.
>
> -- 
> Henri 'henux' Häkkinen
CMake would be a good choice, since it is fairly easy to use. Though it 
is problematic in that it requires an additional external download, 
which is something we should try to minimize.

As for you own work, can't you just use a Makefile or something in the 
interim? I mean, we're still pretty far away from having an initial 
release, so you should use whatever build process you feel comfortable with.