glsdk-devel — Main development list for the OpenGL SDK

Re: [Glsdk-devel] Geometry generation

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

I have to agree with Jason on this one. If the user wants custom
geometry, they need to learn how to deal with drawing it. For the sake
of tutorials, we just need objects to show off transformations and
shaders with. An opaque format reduces the risk of abuse not only by
newbies, but also by people coding SDK examples.

One thing that does need to be clear is how vertex attributes map to
the arrays generated by the shape function. Something like:

Attrib 0 is the position (vec4)
Attrib 1 is the normal (vec3)
Attrib 2 is the texcoord (vec2)

That way shaders can always get the correct variables. I think I'll
add preprocessor defines for this - GLS_POSITION_ATTRIBUTE,
GLS_NORMAL_ATTRIBUTE, and GLS_TEXCOORD_ATTRIBUTE, so that there are no
magic numbers floating around.

On Sat, Aug 23, 2008 at 8:00 PM, Jason McKesson <ko...@gm...> wrote:
> Stefanos A. wrote:
>> If I understand correctly, what we actually need is a way to generate
>> geometry for the tutorials. Which means we just need the
>> vertex/texcoord/normal/element arrays.
>>
>> While it's good to have functions that *generate* this data, is it really
>> a good idea to hide the *drawing* part behind a glsDrawShape function?
>> Maybe it would be better to simply return these four arrays and handle the
>> drawing inside the tutorial?
>>
>> Just trying to understand the focus of the shape functions. What do you
>> say?
>>
> Well, the problem with any form of generation of that type is this:
> where are you going to put it? You can't put it into a user-supplied
> buffer object because it might be too big (and having a query for the
> size makes creating them very complex). And if you have it create the
> buffer, how do you communicate the data format to the user?
>
> Basically, we want these things to be as simple as possible for the user
> to use. This isn't production code, so flexibility is not a concern. We
> want them to be able to go:
>
> //initialize GL/create window.
> GLSshape myBox = glsCreateShapeBox(params);
>
> while(true)
> {
>  //setup context.
>  glsShapeDraw(myBox);
> }
>
> glsDestroyShape(param);
>
> The goal being that you can't make that fail. The user can't do
> something wrong. And it's immediately obvious how it works.
>
> -------------------------------------------------------------------------
> 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...>]

Indeed. At the moment, I don't have an access to a Windows box, but could
somebody who has, kindly test out the possibility of this.

Does the MSVC produce warnings, when you try to compile something like this:

typedef struct FOO_s {
  union {
    struct {
      int di;
    };
    in do;
  };
} FOO;

int main()
{
  FOO f;
  f.di = 1;
  f.do = 2;
  return 0;
}


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

>  Henri Häkkinen wrote:
>
>
>
> On Sun, Aug 24, 2008 at 5:14 AM, Stefanos A. <sta...@gm...> wrote:
>
>> Την Sun, 24 Aug 2008 04:05:06 +0300,ο(η) Henri Häkkinen
>> <hen...@gm...> έγραψε:
>>
>> > Does anyone have anything to say on this, please? I am currently working
>> > hard on the GLM and I think we should resolve the issue of how we
>> > actually
>> > define the math types.
>> >
>>
>>  I'd go for #2 (struct/union), just slightly modified.
>>
>> Why use a struct? Because typing vec.x is cleaner than vec[0].
>>
>> Why have a union? So you can pass the struct to OpenGL without a cast.
>> Compare:
>>
>> foo(vec.data);       // approach #2 (struct/union)
>> vs
>> foo((GLfloat*)vec);  // approach #3 (struct)
>> vs
>> foo(&vec.x);         // approach #3 (struct)
>>
>> To that end, it might be better to define structs like this:
>>
>> typedef struct GLMFoo_t
>> {
>>     union GLMFoo_data
>>     {
>>         GLfloat data[2];   // Instead of v[] or m[]
>>         struct GLMFoo_fields
>>         {
>>             GLfloat x, y;
>>         }
>>     }
>> } GLMFoo;
>>
>> This makes clear that the "data" field provides the storage for the vector
>> data - v or m might be somewhat cryptic at first glance.
>>
>
> I agree that we should go with the struct-union combination. However, I
> have discovered a problem:
>
> typedef struct FOO_s {
>   union {
>     int di;
>     struct BAS_s {
>       int do;
>     };
>   };
> } FOO;
>
> FOO f;
> f.di = 1;
> f.do = 2;
>
> This fails on GCC; f.do is not accessible (try it). I am not sure is this a
> bug in GCC or is this standard conforming behaviour. So therefore, we cannot
> go with the non-anonymous inner struct.
>
> I recommend that we go with struct-union, and with anonymous inner struct,
> and just use compiler #pragma (disable : warning) on Windows platform to
> drop the warning it produces.
>
> What do you think?
>
> As you pointed out, D3DX defines a matrix thusly:
>
> typedef struct _D3DMATRIX {
>     union {
>         struct {
>             float        _11, _12, _13, _14;
>             float        _21, _22, _23, _24;
>             float        _31, _32, _33, _34;
>             float        _41, _42, _43, _44;
>
>         };
>         float m[4][4];
>     };
> } D3DMATRIX;
>
>
> Anonymous inner struct and all. It doesn't produce warnings or anything.
> Maybe you just need to have the struct come first in the union.
>
> -------------------------------------------------------------------------
> 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] Geometry generation

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

Stefanos A. wrote:
> If I understand correctly, what we actually need is a way to generate  
> geometry for the tutorials. Which means we just need the  
> vertex/texcoord/normal/element arrays.
>
> While it's good to have functions that *generate* this data, is it really  
> a good idea to hide the *drawing* part behind a glsDrawShape function?  
> Maybe it would be better to simply return these four arrays and handle the  
> drawing inside the tutorial?
>
> Just trying to understand the focus of the shape functions. What do you  
> say?
>   
Well, the problem with any form of generation of that type is this: 
where are you going to put it? You can't put it into a user-supplied 
buffer object because it might be too big (and having a query for the 
size makes creating them very complex). And if you have it create the 
buffer, how do you communicate the data format to the user?

Basically, we want these things to be as simple as possible for the user 
to use. This isn't production code, so flexibility is not a concern. We 
want them to be able to go:

//initialize GL/create window.
GLSshape myBox = glsCreateShapeBox(params);

while(true)
{
  //setup context.
  glsShapeDraw(myBox);
}

glsDestroyShape(param);

The goal being that you can't make that fail. The user can't do 
something wrong. And it's immediately obvious how it works.

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

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

Henri Häkkinen wrote:
>
>
> On Sun, Aug 24, 2008 at 5:14 AM, Stefanos A. <sta...@gm... 
> <mailto:sta...@gm...>> wrote:
>
>     Την Sun, 24 Aug 2008 04:05:06 +0300,ο(η) Henri Häkkinen
>     <hen...@gm... <mailto:hen...@gm...>> έγραψε:
>
>     > Does anyone have anything to say on this, please? I am currently
>     working
>     > hard on the GLM and I think we should resolve the issue of how we
>     > actually
>     > define the math types.
>     >
>
>     I'd go for #2 (struct/union), just slightly modified.
>
>     Why use a struct? Because typing vec.x is cleaner than vec[0].
>
>     Why have a union? So you can pass the struct to OpenGL without a cast.
>     Compare:
>
>     foo(vec.data);       // approach #2 (struct/union)
>     vs
>     foo((GLfloat*)vec);  // approach #3 (struct)
>     vs
>     foo(&vec.x);         // approach #3 (struct)
>
>     To that end, it might be better to define structs like this:
>
>     typedef struct GLMFoo_t
>     {
>         union GLMFoo_data
>         {
>             GLfloat data[2];   // Instead of v[] or m[]
>             struct GLMFoo_fields
>             {
>                 GLfloat x, y;
>             }
>         }
>     } GLMFoo;
>
>     This makes clear that the "data" field provides the storage for
>     the vector
>     data - v or m might be somewhat cryptic at first glance.
>
>
> I agree that we should go with the struct-union combination. However, 
> I have discovered a problem:
>
> typedef struct FOO_s {
>   union {
>     int di;
>     struct BAS_s {
>       int do;
>     };
>   };
> } FOO;
>
> FOO f;
> f.di = 1;
> f.do = 2;
>
> This fails on GCC; f.do is not accessible (try it). I am not sure is 
> this a bug in GCC or is this standard conforming behaviour. So 
> therefore, we cannot go with the non-anonymous inner struct.
>
> I recommend that we go with struct-union, and with anonymous inner 
> struct, and just use compiler #pragma (disable : warning) on Windows 
> platform to drop the warning it produces.
>
> What do you think?
As you pointed out, D3DX defines a matrix thusly:

typedef struct _D3DMATRIX {
    union {
        struct {
            float        _11, _12, _13, _14;
            float        _21, _22, _23, _24;
            float        _31, _32, _33, _34;
            float        _41, _42, _43, _44;

        };
        float m[4][4];
    };
} D3DMATRIX;


Anonymous inner struct and all. It doesn't produce warnings or anything. 
Maybe you just need to have the struct come first in the union.

Re: [Glsdk-devel] Geometry generation

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

Fine. You have made good points there and I listen to them. I have brought
up my view which you counter argumented with other points. We both have
brought up points from different angles and this is a good thing. My
intentions are not to be counter-productive.

I think we should let the author of the library to have the final word on
this.

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

>  Henri Häkkinen wrote:
>
>
>
> On Sun, Aug 24, 2008 at 4:25 AM, Jason McKesson <ko...@gm...> wrote:
>
>>  Henri Häkkinen wrote:
>>
>> There are good ideas, but how about this:
>>
>> The GLSshape is not opaque pointer, but a public structure like this:
>>
>> typedef struct GLSshape_s {
>>   GLuint vertex_buffer;
>>   GLuint vertex_arrays;
>>   // etc.
>> } GLSshape;
>>
>> In this way, the caller could setup the structure himself and pass it on
>> DrawShape.
>>
>>  If a user needs to create one of those structs in order to render with
>> buffer objects and vertex array objects that he has already created, then
>> our tutorials will have failed miserably. We are talking about an object
>> that is basically a wrapper around a vertex array object, after all. It's a
>> "bind" and "glDrawElements" call away from being drawn. The hard work is in
>> the creation of the various buffers, VAO bindings, and so forth.
>>
>
> Again; I clearly did not say that a user must or need to setup struct on
> his own, but pointed out the possibility and the benefits of it.
>
> Yes, and we have argued that the benefits do not outweigh the costs. I'm
> not sure what you're getting at here.
>
>
>>
>> Or if we decide to handle GLSshape as opaque, we could also declare it
>> like this:
>>
>> typedef struct GLShape_s *GLSshape;
>>
>> In this way we can get minimal type checking if the user tries to push
>> something weird.
>>
>> Also, I like Branan's idea of multiple entry-points. I would prefer their
>> names to be shorter (glsCreateSphere instead of glsCreateShapeSphere).
>>
>>  I can see a need for multiple entrypoints, but the longer names should
>> stay.
>>
>> The convention should be:
>>
>> gls - Create (because it is creating an object) - Shape (the object being
>> created) - etc (for the various different ways of creating a shape).
>>
>> It would be weird to call glsDestroy*Shape* on something returned by
>> glsCreate*Sphere*.
>>
>
> IMO, it would not be that weird; glsCreateShape return GLSshape object.
> Shorter names are more convenient, IMO.
>
> The purpose for having a naming convention is to create a consistency of
> naming among all named things. If that means a name gets "too long," so be
> it; having inconsistent naming is far worse in the long run than having to
> type 5 more characters. I've used many APIs that have inconsistent naming
> (hello, Win32), and it's *never* a good thing, no matter what the original
> reason for it was.
>
>   Either way, I am just trying to be constructive by giving ideas which
> you seem to smash first-handedly just because of your own personal
> conventions of doing things.
>
> Just because your ideas are being shot down, or even argued against, does
> not make the criticism non-constructive.
>
> This is going to be a long project. People are going to have opinions and
> disagree. People are going to argue for their points of view, and they're
> going to make arguments against other people's points of view. Attacking
> someone for doing so is not conducive to a productive atmosphere.
>
> -------------------------------------------------------------------------
> 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] Geometry generation

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

On Sun, Aug 24, 2008 at 5:27 AM, Stefanos A. <sta...@gm...> wrote:

> If I understand correctly, what we actually need is a way to generate
> geometry for the tutorials. Which means we just need the
> vertex/texcoord/normal/element arrays.
>

We want to support OpenGL3 which only has vertex attributes.



>
> While it's good to have functions that *generate* this data, is it really
> a good idea to hide the *drawing* part behind a glsDrawShape function?
> Maybe it would be better to simply return these four arrays and handle the
> drawing inside the tutorial?
>

Basically, I think, we want a library that easies the drawing of simple
objects. We will be having tutorials, of course, of how to draw basic
triangles and stuff. But for a slightly more advanced tutorials and samples,
we need to have some ready made library for drawing stuff. This is how I see
it.


>
> Just trying to understand the focus of the shape functions. What do you
> say?
>
> -------------------------------------------------------------------------
> 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] Geometry generation

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

Henri Häkkinen wrote:
>
>
> On Sun, Aug 24, 2008 at 4:25 AM, Jason McKesson <ko...@gm... 
> <mailto:ko...@gm...>> wrote:
>
>     Henri Häkkinen wrote:
>>     There are good ideas, but how about this:
>>
>>     The GLSshape is not opaque pointer, but a public structure like this:
>>
>>     typedef struct GLSshape_s {
>>       GLuint vertex_buffer;
>>       GLuint vertex_arrays;
>>       // etc.
>>     } GLSshape;
>>
>>     In this way, the caller could setup the structure himself and
>>     pass it on DrawShape.
>     If a user needs to create one of those structs in order to render
>     with buffer objects and vertex array objects that he has already
>     created, then our tutorials will have failed miserably. We are
>     talking about an object that is basically a wrapper around a
>     vertex array object, after all. It's a "bind" and "glDrawElements"
>     call away from being drawn. The hard work is in the creation of
>     the various buffers, VAO bindings, and so forth.
>
>
> Again; I clearly did not say that a user must or need to setup struct 
> on his own, but pointed out the possibility and the benefits of it.
Yes, and we have argued that the benefits do not outweigh the costs. I'm 
not sure what you're getting at here.

>
>>
>>     Or if we decide to handle GLSshape as opaque, we could also
>>     declare it like this:
>>
>>     typedef struct GLShape_s *GLSshape;
>>
>>     In this way we can get minimal type checking if the user tries to
>>     push something weird.
>>
>>     Also, I like Branan's idea of multiple entry-points. I would
>>     prefer their names to be shorter (glsCreateSphere instead of
>>     glsCreateShapeSphere).
>     I can see a need for multiple entrypoints, but the longer names
>     should stay.
>
>     The convention should be:
>
>     gls - Create (because it is creating an object) - Shape (the
>     object being created) - etc (for the various different ways of
>     creating a shape).
>
>     It would be weird to call glsDestroy/Shape/ on something returned
>     by glsCreate/Sphere/.
>
>
> IMO, it would not be that weird; glsCreateShape return GLSshape 
> object. Shorter names are more convenient, IMO.
The purpose for having a naming convention is to create a consistency of 
naming among all named things. If that means a name gets "too long," so 
be it; having inconsistent naming is far worse in the long run than 
having to type 5 more characters. I've used many APIs that have 
inconsistent naming (hello, Win32), and it's /never/ a good thing, no 
matter what the original reason for it was.
> Either way, I am just trying to be constructive by giving ideas which 
> you seem to smash first-handedly just because of your own personal 
> conventions of doing things.
Just because your ideas are being shot down, or even argued against, 
does not make the criticism non-constructive.

This is going to be a long project. People are going to have opinions 
and disagree. People are going to argue for their points of view, and 
they're going to make arguments against other people's points of view. 
Attacking someone for doing so is not conducive to a productive atmosphere.

Re: [Glsdk-devel] Geometry generation

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

If I understand correctly, what we actually need is a way to generate  
geometry for the tutorials. Which means we just need the  
vertex/texcoord/normal/element arrays.

While it's good to have functions that *generate* this data, is it really  
a good idea to hide the *drawing* part behind a glsDrawShape function?  
Maybe it would be better to simply return these four arrays and handle the  
drawing inside the tutorial?

Just trying to understand the focus of the shape functions. What do you  
say?

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

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

On Sun, Aug 24, 2008 at 5:14 AM, Stefanos A. <sta...@gm...> wrote:

> Την Sun, 24 Aug 2008 04:05:06 +0300,ο(η) Henri Häkkinen
> <hen...@gm...> έγραψε:
>
> > Does anyone have anything to say on this, please? I am currently working
> > hard on the GLM and I think we should resolve the issue of how we
> > actually
> > define the math types.
> >
>
> I'd go for #2 (struct/union), just slightly modified.
>
> Why use a struct? Because typing vec.x is cleaner than vec[0].
>
> Why have a union? So you can pass the struct to OpenGL without a cast.
> Compare:
>
> foo(vec.data);       // approach #2 (struct/union)
> vs
> foo((GLfloat*)vec);  // approach #3 (struct)
> vs
> foo(&vec.x);         // approach #3 (struct)
>
> To that end, it might be better to define structs like this:
>
> typedef struct GLMFoo_t
> {
>     union GLMFoo_data
>     {
>         GLfloat data[2];   // Instead of v[] or m[]
>         struct GLMFoo_fields
>         {
>             GLfloat x, y;
>         }
>     }
> } GLMFoo;
>
> This makes clear that the "data" field provides the storage for the vector
> data - v or m might be somewhat cryptic at first glance.
>

I agree that we should go with the struct-union combination. However, I have
discovered a problem:

typedef struct FOO_s {
  union {
    int di;
    struct BAS_s {
      int do;
    };
  };
} FOO;

FOO f;
f.di = 1;
f.do = 2;

This fails on GCC; f.do is not accessible (try it). I am not sure is this a
bug in GCC or is this standard conforming behaviour. So therefore, we cannot
go with the non-anonymous inner struct.

I recommend that we go with struct-union, and with anonymous inner struct,
and just use compiler #pragma (disable : warning) on Windows platform to
drop the warning it produces.

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] The use of anonymous structures

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

Την Sun, 24 Aug 2008 04:05:06 +0300,ο(η) Henri Häkkinen  
<hen...@gm...> έγραψε:

> Does anyone have anything to say on this, please? I am currently working
> hard on the GLM and I think we should resolve the issue of how we  
> actually
> define the math types.
>

I'd go for #2 (struct/union), just slightly modified.

Why use a struct? Because typing vec.x is cleaner than vec[0].

Why have a union? So you can pass the struct to OpenGL without a cast.  
Compare:

foo(vec.data);	     // approach #2 (struct/union)
vs
foo((GLfloat*)vec);  // approach #3 (struct)
vs
foo(&vec.x);         // approach #3 (struct)

To that end, it might be better to define structs like this:

typedef struct GLMFoo_t
{
     union GLMFoo_data
     {
         GLfloat data[2];   // Instead of v[] or m[]
         struct GLMFoo_fields
         {
             GLfloat x, y;
         }
     }
} GLMFoo;

This makes clear that the "data" field provides the storage for the vector  
data - v or m might be somewhat cryptic at first glance.

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

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

See this link,

http://msdn.microsoft.com/en-us/library/bb172573(VS.85).aspx

In Direct3D they are using similar design.



On Sun, Aug 24, 2008 at 4:55 AM, Henri Häkkinen <hen...@gm...> wrote:

>
>
> On Sun, Aug 24, 2008 at 4:53 AM, Henri Häkkinen <hen...@gm...>wrote:
>
>>
>>
>> On Sun, Aug 24, 2008 at 4:44 AM, Jason McKesson <ko...@gm...>wrote:
>>
>>>  Henri Häkkinen wrote:
>>>
>>>
>>>
>>> On Sun, Aug 24, 2008 at 4:19 AM, Jason McKesson <ko...@gm...>wrote:
>>>
>>>>  Henri Häkkinen wrote:
>>>>
>>>> Does anyone have anything to say on this, please? I am currently working
>>>> hard on the GLM and I think we should resolve the issue of how we actually
>>>> define the math types.
>>>>
>>>>  Well, the VC++ compiler issue pretty much ends #2 as a possibility. If
>>>> #1 doesn't work for you, that leaves #3.
>>>>
>>>
>>> Well no, this is not true at all. The VC compiler issues is only about
>>> anonymous structures. For example, this generates a warning:
>>>
>>> typedef struct GLMvec2f_s {
>>>   union {
>>>     GLfloat v[2];
>>>     struct {
>>>       GLfloat x, y;
>>>     }
>>>   };
>>> } GLMvec2f;
>>>
>>> While this does not:
>>>
>>> typedef struct GLMvec2f_s {
>>>   union {
>>>     GLfloat v[2];
>>>     struct GLMvec2fcoords_s {
>>>       GLfloat x, y;
>>>     }
>>>   };
>>> } GLMvec2f;
>>>
>>>   Admittedly it's been a while since I last used pure C, but if I'm
>>> reading that right, to access the x or y members, I would need:
>>>
>>> GLMvec2f someValue;
>>>
>>> someValue.GLMvec3fcoords_s.x = 0.5f
>>>
>>> This is a pretty clear violation of design goal #2: Simplicity. And if
>>> the inner struct can't be accessed with a simple ".x", then what's the point
>>> in having it at all?
>>>
>>
>> No that is not correct at all.
>>
>> There is a difference between the name of the structure and the name of
>> the variable. When you write in C like this:
>>
>> struct FOO {
>>   int baz;
>> } fizban;
>>
>> You access baz inside the struct like this:
>>
>> fizban.baz = 12;
>>
>> When we have the vector type:
>>
>> typedef struct GLMvec2f_s {
>>   union {
>>     GLfloat v[2];
>>     struct GLMvec2fcoords_s {
>>       GLfloat x, y;
>>     };
>>   };
>> } GLMvec2f;
>>
>> You access it normally;
>>
>> GLMvec2f v;
>> v.x = 10.0f;
>>
>> The 'GLMvec2fcoords_s' is a structure name, nor a variable name.
>>
>
> TYPO: s/nor/not/
>
>
>>
>>
>>
>>>
>>> -------------------------------------------------------------------------
>>> 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
>
>


-- 
Henri 'henux' Häkkinen

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

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

On Sun, Aug 24, 2008 at 4:53 AM, Henri Häkkinen <hen...@gm...> wrote:

>
>
> On Sun, Aug 24, 2008 at 4:44 AM, Jason McKesson <ko...@gm...> wrote:
>
>>  Henri Häkkinen wrote:
>>
>>
>>
>> On Sun, Aug 24, 2008 at 4:19 AM, Jason McKesson <ko...@gm...>wrote:
>>
>>>  Henri Häkkinen wrote:
>>>
>>> Does anyone have anything to say on this, please? I am currently working
>>> hard on the GLM and I think we should resolve the issue of how we actually
>>> define the math types.
>>>
>>>  Well, the VC++ compiler issue pretty much ends #2 as a possibility. If
>>> #1 doesn't work for you, that leaves #3.
>>>
>>
>> Well no, this is not true at all. The VC compiler issues is only about
>> anonymous structures. For example, this generates a warning:
>>
>> typedef struct GLMvec2f_s {
>>   union {
>>     GLfloat v[2];
>>     struct {
>>       GLfloat x, y;
>>     }
>>   };
>> } GLMvec2f;
>>
>> While this does not:
>>
>> typedef struct GLMvec2f_s {
>>   union {
>>     GLfloat v[2];
>>     struct GLMvec2fcoords_s {
>>       GLfloat x, y;
>>     }
>>   };
>> } GLMvec2f;
>>
>>   Admittedly it's been a while since I last used pure C, but if I'm
>> reading that right, to access the x or y members, I would need:
>>
>> GLMvec2f someValue;
>>
>> someValue.GLMvec3fcoords_s.x = 0.5f
>>
>> This is a pretty clear violation of design goal #2: Simplicity. And if the
>> inner struct can't be accessed with a simple ".x", then what's the point in
>> having it at all?
>>
>
> No that is not correct at all.
>
> There is a difference between the name of the structure and the name of the
> variable. When you write in C like this:
>
> struct FOO {
>   int baz;
> } fizban;
>
> You access baz inside the struct like this:
>
> fizban.baz = 12;
>
> When we have the vector type:
>
> typedef struct GLMvec2f_s {
>   union {
>     GLfloat v[2];
>     struct GLMvec2fcoords_s {
>       GLfloat x, y;
>     };
>   };
> } GLMvec2f;
>
> You access it normally;
>
> GLMvec2f v;
> v.x = 10.0f;
>
> The 'GLMvec2fcoords_s' is a structure name, nor a variable name.
>

TYPO: s/nor/not/


>
>
>
>>
>> -------------------------------------------------------------------------
>> 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] The use of anonymous structures

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

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

>  Henri Häkkinen wrote:
>
>
>
> On Sun, Aug 24, 2008 at 4:19 AM, Jason McKesson <ko...@gm...> wrote:
>
>>  Henri Häkkinen wrote:
>>
>> Does anyone have anything to say on this, please? I am currently working
>> hard on the GLM and I think we should resolve the issue of how we actually
>> define the math types.
>>
>>  Well, the VC++ compiler issue pretty much ends #2 as a possibility. If #1
>> doesn't work for you, that leaves #3.
>>
>
> Well no, this is not true at all. The VC compiler issues is only about
> anonymous structures. For example, this generates a warning:
>
> typedef struct GLMvec2f_s {
>   union {
>     GLfloat v[2];
>     struct {
>       GLfloat x, y;
>     }
>   };
> } GLMvec2f;
>
> While this does not:
>
> typedef struct GLMvec2f_s {
>   union {
>     GLfloat v[2];
>     struct GLMvec2fcoords_s {
>       GLfloat x, y;
>     }
>   };
> } GLMvec2f;
>
>   Admittedly it's been a while since I last used pure C, but if I'm
> reading that right, to access the x or y members, I would need:
>
> GLMvec2f someValue;
>
> someValue.GLMvec3fcoords_s.x = 0.5f
>
> This is a pretty clear violation of design goal #2: Simplicity. And if the
> inner struct can't be accessed with a simple ".x", then what's the point in
> having it at all?
>

No that is not correct at all.

There is a difference between the name of the structure and the name of the
variable. When you write in C like this:

struct FOO {
  int baz;
} fizban;

You access baz inside the struct like this:

fizban.baz = 12;

When we have the vector type:

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

You access it normally;

GLMvec2f v;
v.x = 10.0f;

The 'GLMvec2fcoords_s' is a structure name, nor a variable name.



>
> -------------------------------------------------------------------------
> 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:
>
>
> On Sun, Aug 24, 2008 at 4:19 AM, Jason McKesson <ko...@gm... 
> <mailto:ko...@gm...>> wrote:
>
>     Henri Häkkinen wrote:
>>     Does anyone have anything to say on this, please? I am currently
>>     working hard on the GLM and I think we should resolve the issue
>>     of how we actually define the math types.
>     Well, the VC++ compiler issue pretty much ends #2 as a
>     possibility. If #1 doesn't work for you, that leaves #3.
>
>
> Well no, this is not true at all. The VC compiler issues is only about 
> anonymous structures. For example, this generates a warning:
>
> typedef struct GLMvec2f_s {
>   union {
>     GLfloat v[2];
>     struct {
>       GLfloat x, y;
>     }
>   };
> } GLMvec2f;
>
> While this does not:
>
> typedef struct GLMvec2f_s {
>   union {
>     GLfloat v[2];
>     struct GLMvec2fcoords_s {
>       GLfloat x, y;
>     }
>   };
> } GLMvec2f;
>
Admittedly it's been a while since I last used pure C, but if I'm 
reading that right, to access the x or y members, I would need:

GLMvec2f someValue;

someValue.GLMvec3fcoords_s.x = 0.5f

This is a pretty clear violation of design goal #2: Simplicity. And if 
the inner struct can't be accessed with a simple ".x", then what's the 
point in having it at all?

Re: [Glsdk-devel] Geometry generation

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

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

>  Henri Häkkinen wrote:
>
> There are good ideas, but how about this:
>
> The GLSshape is not opaque pointer, but a public structure like this:
>
> typedef struct GLSshape_s {
>   GLuint vertex_buffer;
>   GLuint vertex_arrays;
>   // etc.
> } GLSshape;
>
> In this way, the caller could setup the structure himself and pass it on
> DrawShape.
>
> If a user needs to create one of those structs in order to render with
> buffer objects and vertex array objects that he has already created, then
> our tutorials will have failed miserably. We are talking about an object
> that is basically a wrapper around a vertex array object, after all. It's a
> "bind" and "glDrawElements" call away from being drawn. The hard work is in
> the creation of the various buffers, VAO bindings, and so forth.
>

Again; I clearly did not say that a user must or need to setup struct on his
own, but pointed out the possibility and the benefits of it.


>
>
> The point of making it an opaque pointer is so that shapes, pre-defined
> meshes are protected from user intrusion and alteration. It also allows us
> to *change* the internal representation as the GL API changes and matures.
>

That is a valid point.


>
>
> Or if we decide to handle GLSshape as opaque, we could also declare it like
> this:
>
> typedef struct GLShape_s *GLSshape;
>
> In this way we can get minimal type checking if the user tries to push
> something weird.
>
> Also, I like Branan's idea of multiple entry-points. I would prefer their
> names to be shorter (glsCreateSphere instead of glsCreateShapeSphere).
>
> I can see a need for multiple entrypoints, but the longer names should
> stay.
>
> The convention should be:
>
> gls - Create (because it is creating an object) - Shape (the object being
> created) - etc (for the various different ways of creating a shape).
>
> It would be weird to call glsDestroy*Shape* on something returned by
> glsCreate*Sphere*.
>

IMO, it would not be that weird; glsCreateShape return GLSshape object.
Shorter names are more convenient, IMO. Either way, I am just trying to be
constructive by giving ideas which you seem to smash first-handedly just
because of your own personal conventions of doing things.

In the long run, shorter names may be more convenient as it is obvious from
the name of the function what kind of thing it is creating.



>
>
> On Sun, Aug 24, 2008 at 3:49 AM, Branan Riley <br...@gm...> wrote:
>
>> OK, that looks pretty good to me.
>>
>> I'd prefer multiple entrypoints, rather than one
>> glsCreateShapePredefined. So I'd rather it be something like:
>>
>> glsCreateShapeShpere();
>> glsCreateShapeCube();
>> glsCreateShapeFromOBJ(); // naming convention for models is up for debate
>>
>>
>> On Sat, Aug 23, 2008 at 5:42 PM, Jason McKesson <ko...@gm...>
>> wrote:
>> > Branan Riley 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?
>> >>
>> > There are simple parts of this and there are complicated parts of this.
>> >
>> > The easiest part: the SDK should not promote the use of any 3.0
>> > deprecated functionality. So buffer objects and shaders for everything.
>> >
>> > Slightly easier: these "shape" generators are convenience functions.
>> > Therefore, they should be quick, simple, and not very complicated. So
>> > they shouldn't burden the user with unnecessary details (like creating
>> > certain GL objects, etc). It should be an object that the user gets with
>> > which the user can draw, through a "DrawShape" function.
>> >
>> > Harder: Unlike C++, C doesn't really have a language concept of data
>> > hiding. But data hiding is really important. Accessors are really
>> > important. It doesn't add any complexity to make an object opaque, so
>> > long as the object has appropriate accessor functions to get at
>> > necessary data. In short, I think shapes should be entirely opaque, not
>> > exposing the internal data structure to the user. Instead, they should
>> > just do their job.
>> >
>> > My personal preference would be as follows:
>> >
>> > typedef void* GLSshape;
>> >
>> > GLSshape glsCreateShapePredefined(params);
>> > void glsDestroyShape(GLSshape);
>> > void glsDrawShape(GLSshape);
>> >
>> > The first function uses "predefined" so that later we can add shapes
>> > that aren't predefined (loads from a file, user-created somehow, etc).
>> > The second function destroys the shape object. And the last binds and
>> > renders it using the state currently bound to the context.
>> >
>> > It has the least chance of breakage (GLSshape is opaque, so the user
>> > can't mess with it), and is very self-contained. We may need accessors
>> > to query the attribute indices, or an API to specify attribute indices
>> > at creation time. But that's about it.
>> >
>> >
>> -------------------------------------------------------------------------
>> > 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 worldhttp://moblin-contest.org/redirect.php?banner_id=100&url=/
>
> ------------------------------
>
> _______________________________________________
> Glsdk-devel mailing lis...@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] The use of anonymous structures

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

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

>  Henri Häkkinen wrote:
>
> Does anyone have anything to say on this, please? I am currently working
> hard on the GLM and I think we should resolve the issue of how we actually
> define the math types.
>
> Well, the VC++ compiler issue pretty much ends #2 as a possibility. If #1
> doesn't work for you, that leaves #3.
>

Well no, this is not true at all. The VC compiler issues is only about
anonymous structures. For example, this generates a warning:

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

While this does not:

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




>
> BTW, the whole point of having accessor functions like glmVecSet2f is that
> there is no alternative way to set them. If you do have an alternative
> (directly setting the fields in the struct), why bother with a function?
>

For obvious reasons. 1) function calls can be chained, 2) it is more
convenient to set up the structure with one call than manually assigning
values for each member. While we have the constructor function xxSet, this
does not rule out the possibility of having an open struct. In some cases,
the caller may want to access one member, while in another cases he wants to
setup it one go.

IMO, I see no trouble or complication at this point from having unions in
our structs. They are an advantage, not a hindurance.


>
>
>  On Sun, Aug 24, 2008 at 1:43 AM, Henri Häkkinen <hen...@gm...>wrote:
>
>> 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.
>>
>
>
> -------------------------------------------------------------------------
> 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] Geometry generation

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

Henri Häkkinen wrote:
> There are good ideas, but how about this:
>
> The GLSshape is not opaque pointer, but a public structure like this:
>
> typedef struct GLSshape_s {
>   GLuint vertex_buffer;
>   GLuint vertex_arrays;
>   // etc.
> } GLSshape;
>
> In this way, the caller could setup the structure himself and pass it 
> on DrawShape.
If a user needs to create one of those structs in order to render with 
buffer objects and vertex array objects that he has already created, 
then our tutorials will have failed miserably. We are talking about an 
object that is basically a wrapper around a vertex array object, after 
all. It's a "bind" and "glDrawElements" call away from being drawn. The 
hard work is in the creation of the various buffers, VAO bindings, and 
so forth.

The point of making it an opaque pointer is so that shapes, pre-defined 
meshes are protected from user intrusion and alteration. It also allows 
us to /change/ the internal representation as the GL API changes and 
matures.
>
> Or if we decide to handle GLSshape as opaque, we could also declare it 
> like this:
>
> typedef struct GLShape_s *GLSshape;
>
> In this way we can get minimal type checking if the user tries to push 
> something weird.
>
> Also, I like Branan's idea of multiple entry-points. I would prefer 
> their names to be shorter (glsCreateSphere instead of 
> glsCreateShapeSphere).
I can see a need for multiple entrypoints, but the longer names should stay.

The convention should be:

gls - Create (because it is creating an object) - Shape (the object 
being created) - etc (for the various different ways of creating a shape).

It would be weird to call glsDestroy/Shape/ on something returned by 
glsCreate/Sphere/.
>
> On Sun, Aug 24, 2008 at 3:49 AM, Branan Riley <br...@gm... 
> <mailto:br...@gm...>> wrote:
>
>     OK, that looks pretty good to me.
>
>     I'd prefer multiple entrypoints, rather than one
>     glsCreateShapePredefined. So I'd rather it be something like:
>
>     glsCreateShapeShpere();
>     glsCreateShapeCube();
>     glsCreateShapeFromOBJ(); // naming convention for models is up for
>     debate
>
>
>     On Sat, Aug 23, 2008 at 5:42 PM, Jason McKesson <ko...@gm...
>     <mailto:ko...@gm...>> wrote:
>     > Branan Riley 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?
>     >>
>     > There are simple parts of this and there are complicated parts
>     of this.
>     >
>     > The easiest part: the SDK should not promote the use of any 3.0
>     > deprecated functionality. So buffer objects and shaders for
>     everything.
>     >
>     > Slightly easier: these "shape" generators are convenience functions.
>     > Therefore, they should be quick, simple, and not very
>     complicated. So
>     > they shouldn't burden the user with unnecessary details (like
>     creating
>     > certain GL objects, etc). It should be an object that the user
>     gets with
>     > which the user can draw, through a "DrawShape" function.
>     >
>     > Harder: Unlike C++, C doesn't really have a language concept of data
>     > hiding. But data hiding is really important. Accessors are really
>     > important. It doesn't add any complexity to make an object
>     opaque, so
>     > long as the object has appropriate accessor functions to get at
>     > necessary data. In short, I think shapes should be entirely
>     opaque, not
>     > exposing the internal data structure to the user. Instead, they
>     should
>     > just do their job.
>     >
>     > My personal preference would be as follows:
>     >
>     > typedef void* GLSshape;
>     >
>     > GLSshape glsCreateShapePredefined(params);
>     > void glsDestroyShape(GLSshape);
>     > void glsDrawShape(GLSshape);
>     >
>     > The first function uses "predefined" so that later we can add shapes
>     > that aren't predefined (loads from a file, user-created somehow,
>     etc).
>     > The second function destroys the shape object. And the last
>     binds and
>     > renders it using the state currently bound to the context.
>     >
>     > It has the least chance of breakage (GLSshape is opaque, so the user
>     > can't mess with it), and is very self-contained. We may need
>     accessors
>     > to query the attribute indices, or an API to specify attribute
>     indices
>     > at creation time. But that's about it.
>     >
>     >
>     -------------------------------------------------------------------------
>     > 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=/
>     <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>     > _______________________________________________
>     > Glsdk-devel mailing list
>     > Gls...@li...
>     <mailto: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=/
>     <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>     _______________________________________________
>     Glsdk-devel mailing list
>     Gls...@li...
>     <mailto: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

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

First draft of the GLShape API:

BEGIN FILE gls.h

#ifndef GLSDK_GLS_H
#define GLSDK_GLS_H

#ifdef WIN32
#  include <windows.h>
#endif

#include <GL/gl.h>


typedef void* GLSshape;


// Predefined creation functions
GLSshape glsCreateShapeSphere (GLfloat radius, GLuint segments, GLuint rings);
GLSshape glsCreateShapeCylinder (GLfloat radius, GLfloat height,
GLboolean capped, GLuint segments, GLuint rings);
GLSshape glsCreateShapeCone (GLfloat radius, GLfloat height, GLboolean
capped, GLuint segments, GLuing rings);
GLSshape glsCreateShapeCube (GLfloat length, GLfloat width, GLfloat height);

// Cleanup functions
void glsDestroyShape (GLSshape shape);

// Drawing functions
void glsDrawShape(GLSshape shape);

#endif

ENDI FILE gls.h

On Sat, Aug 23, 2008 at 6:16 PM, Branan Riley <br...@gm...> wrote:
> I think an opaque pointer is better. It makes the interface cleaner -
> these APIs are meant for simple code, not production-level stuff, so
> low-level access isn't needed.
>
> Branan
>
> On Sat, Aug 23, 2008 at 6:03 PM, Henri Häkkinen <hen...@gm...> wrote:
>> There are good ideas, but how about this:
>>
>> The GLSshape is not opaque pointer, but a public structure like this:
>>
>> typedef struct GLSshape_s {
>>   GLuint vertex_buffer;
>>   GLuint vertex_arrays;
>>   // etc.
>> } GLSshape;
>>
>> In this way, the caller could setup the structure himself and pass it on
>> DrawShape.
>>
>> Or if we decide to handle GLSshape as opaque, we could also declare it like
>> this:
>>
>> typedef struct GLShape_s *GLSshape;
>>
>> In this way we can get minimal type checking if the user tries to push
>> something weird.
>>
>> Also, I like Branan's idea of multiple entry-points. I would prefer their
>> names to be shorter (glsCreateSphere instead of glsCreateShapeSphere).
>>
>>
>> On Sun, Aug 24, 2008 at 3:49 AM, Branan Riley <br...@gm...> wrote:
>>>
>>> OK, that looks pretty good to me.
>>>
>>> I'd prefer multiple entrypoints, rather than one
>>> glsCreateShapePredefined. So I'd rather it be something like:
>>>
>>> glsCreateShapeShpere();
>>> glsCreateShapeCube();
>>> glsCreateShapeFromOBJ(); // naming convention for models is up for debate
>>>
>>>
>>> On Sat, Aug 23, 2008 at 5:42 PM, Jason McKesson <ko...@gm...> wrote:
>>> > Branan Riley 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?
>>> >>
>>> > There are simple parts of this and there are complicated parts of this.
>>> >
>>> > The easiest part: the SDK should not promote the use of any 3.0
>>> > deprecated functionality. So buffer objects and shaders for everything.
>>> >
>>> > Slightly easier: these "shape" generators are convenience functions.
>>> > Therefore, they should be quick, simple, and not very complicated. So
>>> > they shouldn't burden the user with unnecessary details (like creating
>>> > certain GL objects, etc). It should be an object that the user gets with
>>> > which the user can draw, through a "DrawShape" function.
>>> >
>>> > Harder: Unlike C++, C doesn't really have a language concept of data
>>> > hiding. But data hiding is really important. Accessors are really
>>> > important. It doesn't add any complexity to make an object opaque, so
>>> > long as the object has appropriate accessor functions to get at
>>> > necessary data. In short, I think shapes should be entirely opaque, not
>>> > exposing the internal data structure to the user. Instead, they should
>>> > just do their job.
>>> >
>>> > My personal preference would be as follows:
>>> >
>>> > typedef void* GLSshape;
>>> >
>>> > GLSshape glsCreateShapePredefined(params);
>>> > void glsDestroyShape(GLSshape);
>>> > void glsDrawShape(GLSshape);
>>> >
>>> > The first function uses "predefined" so that later we can add shapes
>>> > that aren't predefined (loads from a file, user-created somehow, etc).
>>> > The second function destroys the shape object. And the last binds and
>>> > renders it using the state currently bound to the context.
>>> >
>>> > It has the least chance of breakage (GLSshape is opaque, so the user
>>> > can't mess with it), and is very self-contained. We may need accessors
>>> > to query the attribute indices, or an API to specify attribute indices
>>> > at creation time. But that's about it.
>>> >
>>> >
>>> > -------------------------------------------------------------------------
>>> > 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] The use of anonymous structures

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

Henri Häkkinen wrote:
> Does anyone have anything to say on this, please? I am currently 
> working hard on the GLM and I think we should resolve the issue of how 
> we actually define the math types.
Well, the VC++ compiler issue pretty much ends #2 as a possibility. If 
#1 doesn't work for you, that leaves #3.

BTW, the whole point of having accessor functions like glmVecSet2f is 
that there is no alternative way to set them. If you do have an 
alternative (directly setting the fields in the struct), why bother with 
a function?

> On Sun, Aug 24, 2008 at 1:43 AM, Henri Häkkinen <hen...@gm... 
> <mailto:hen...@gm...>> wrote:
>
>     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.
>

Re: [Glsdk-devel] Geometry generation

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

I think an opaque pointer is better. It makes the interface cleaner -
these APIs are meant for simple code, not production-level stuff, so
low-level access isn't needed.

Branan

On Sat, Aug 23, 2008 at 6:03 PM, Henri Häkkinen <hen...@gm...> wrote:
> There are good ideas, but how about this:
>
> The GLSshape is not opaque pointer, but a public structure like this:
>
> typedef struct GLSshape_s {
>   GLuint vertex_buffer;
>   GLuint vertex_arrays;
>   // etc.
> } GLSshape;
>
> In this way, the caller could setup the structure himself and pass it on
> DrawShape.
>
> Or if we decide to handle GLSshape as opaque, we could also declare it like
> this:
>
> typedef struct GLShape_s *GLSshape;
>
> In this way we can get minimal type checking if the user tries to push
> something weird.
>
> Also, I like Branan's idea of multiple entry-points. I would prefer their
> names to be shorter (glsCreateSphere instead of glsCreateShapeSphere).
>
>
> On Sun, Aug 24, 2008 at 3:49 AM, Branan Riley <br...@gm...> wrote:
>>
>> OK, that looks pretty good to me.
>>
>> I'd prefer multiple entrypoints, rather than one
>> glsCreateShapePredefined. So I'd rather it be something like:
>>
>> glsCreateShapeShpere();
>> glsCreateShapeCube();
>> glsCreateShapeFromOBJ(); // naming convention for models is up for debate
>>
>>
>> On Sat, Aug 23, 2008 at 5:42 PM, Jason McKesson <ko...@gm...> wrote:
>> > Branan Riley 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?
>> >>
>> > There are simple parts of this and there are complicated parts of this.
>> >
>> > The easiest part: the SDK should not promote the use of any 3.0
>> > deprecated functionality. So buffer objects and shaders for everything.
>> >
>> > Slightly easier: these "shape" generators are convenience functions.
>> > Therefore, they should be quick, simple, and not very complicated. So
>> > they shouldn't burden the user with unnecessary details (like creating
>> > certain GL objects, etc). It should be an object that the user gets with
>> > which the user can draw, through a "DrawShape" function.
>> >
>> > Harder: Unlike C++, C doesn't really have a language concept of data
>> > hiding. But data hiding is really important. Accessors are really
>> > important. It doesn't add any complexity to make an object opaque, so
>> > long as the object has appropriate accessor functions to get at
>> > necessary data. In short, I think shapes should be entirely opaque, not
>> > exposing the internal data structure to the user. Instead, they should
>> > just do their job.
>> >
>> > My personal preference would be as follows:
>> >
>> > typedef void* GLSshape;
>> >
>> > GLSshape glsCreateShapePredefined(params);
>> > void glsDestroyShape(GLSshape);
>> > void glsDrawShape(GLSshape);
>> >
>> > The first function uses "predefined" so that later we can add shapes
>> > that aren't predefined (loads from a file, user-created somehow, etc).
>> > The second function destroys the shape object. And the last binds and
>> > renders it using the state currently bound to the context.
>> >
>> > It has the least chance of breakage (GLSshape is opaque, so the user
>> > can't mess with it), and is very self-contained. We may need accessors
>> > to query the attribute indices, or an API to specify attribute indices
>> > at creation time. But that's about it.
>> >
>> >
>> > -------------------------------------------------------------------------
>> > 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] The use of anonymous structures

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

Does anyone have anything to say on this, please? I am currently working
hard on the GLM and I think we should resolve the issue of how we actually
define the math types.

On Sun, Aug 24, 2008 at 1:43 AM, Henri Häkkinen <hen...@gm...> wrote:

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


-- 
Henri 'henux' Häkkinen

Re: [Glsdk-devel] Geometry generation

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

There are good ideas, but how about this:

The GLSshape is not opaque pointer, but a public structure like this:

typedef struct GLSshape_s {
  GLuint vertex_buffer;
  GLuint vertex_arrays;
  // etc.
} GLSshape;

In this way, the caller could setup the structure himself and pass it on
DrawShape.

Or if we decide to handle GLSshape as opaque, we could also declare it like
this:

typedef struct GLShape_s *GLSshape;

In this way we can get minimal type checking if the user tries to push
something weird.

Also, I like Branan's idea of multiple entry-points. I would prefer their
names to be shorter (glsCreateSphere instead of glsCreateShapeSphere).


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

> OK, that looks pretty good to me.
>
> I'd prefer multiple entrypoints, rather than one
> glsCreateShapePredefined. So I'd rather it be something like:
>
> glsCreateShapeShpere();
> glsCreateShapeCube();
> glsCreateShapeFromOBJ(); // naming convention for models is up for debate
>
>
> On Sat, Aug 23, 2008 at 5:42 PM, Jason McKesson <ko...@gm...> wrote:
> > Branan Riley 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?
> >>
> > There are simple parts of this and there are complicated parts of this.
> >
> > The easiest part: the SDK should not promote the use of any 3.0
> > deprecated functionality. So buffer objects and shaders for everything.
> >
> > Slightly easier: these "shape" generators are convenience functions.
> > Therefore, they should be quick, simple, and not very complicated. So
> > they shouldn't burden the user with unnecessary details (like creating
> > certain GL objects, etc). It should be an object that the user gets with
> > which the user can draw, through a "DrawShape" function.
> >
> > Harder: Unlike C++, C doesn't really have a language concept of data
> > hiding. But data hiding is really important. Accessors are really
> > important. It doesn't add any complexity to make an object opaque, so
> > long as the object has appropriate accessor functions to get at
> > necessary data. In short, I think shapes should be entirely opaque, not
> > exposing the internal data structure to the user. Instead, they should
> > just do their job.
> >
> > My personal preference would be as follows:
> >
> > typedef void* GLSshape;
> >
> > GLSshape glsCreateShapePredefined(params);
> > void glsDestroyShape(GLSshape);
> > void glsDrawShape(GLSshape);
> >
> > The first function uses "predefined" so that later we can add shapes
> > that aren't predefined (loads from a file, user-created somehow, etc).
> > The second function destroys the shape object. And the last binds and
> > renders it using the state currently bound to the context.
> >
> > It has the least chance of breakage (GLSshape is opaque, so the user
> > can't mess with it), and is very self-contained. We may need accessors
> > to query the attribute indices, or an API to specify attribute indices
> > at creation time. But that's about it.
> >
> > -------------------------------------------------------------------------
> > 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] Geometry generation

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

OK, that looks pretty good to me.

I'd prefer multiple entrypoints, rather than one
glsCreateShapePredefined. So I'd rather it be something like:

glsCreateShapeShpere();
glsCreateShapeCube();
glsCreateShapeFromOBJ(); // naming convention for models is up for debate


On Sat, Aug 23, 2008 at 5:42 PM, Jason McKesson <ko...@gm...> wrote:
> Branan Riley 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?
>>
> There are simple parts of this and there are complicated parts of this.
>
> The easiest part: the SDK should not promote the use of any 3.0
> deprecated functionality. So buffer objects and shaders for everything.
>
> Slightly easier: these "shape" generators are convenience functions.
> Therefore, they should be quick, simple, and not very complicated. So
> they shouldn't burden the user with unnecessary details (like creating
> certain GL objects, etc). It should be an object that the user gets with
> which the user can draw, through a "DrawShape" function.
>
> Harder: Unlike C++, C doesn't really have a language concept of data
> hiding. But data hiding is really important. Accessors are really
> important. It doesn't add any complexity to make an object opaque, so
> long as the object has appropriate accessor functions to get at
> necessary data. In short, I think shapes should be entirely opaque, not
> exposing the internal data structure to the user. Instead, they should
> just do their job.
>
> My personal preference would be as follows:
>
> typedef void* GLSshape;
>
> GLSshape glsCreateShapePredefined(params);
> void glsDestroyShape(GLSshape);
> void glsDrawShape(GLSshape);
>
> The first function uses "predefined" so that later we can add shapes
> that aren't predefined (loads from a file, user-created somehow, etc).
> The second function destroys the shape object. And the last binds and
> renders it using the state currently bound to the context.
>
> It has the least chance of breakage (GLSshape is opaque, so the user
> can't mess with it), and is very self-contained. We may need accessors
> to query the attribute indices, or an API to specify attribute indices
> at creation time. But that's about it.
>
> -------------------------------------------------------------------------
> 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

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

Branan Riley 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?
>   
There are simple parts of this and there are complicated parts of this.

The easiest part: the SDK should not promote the use of any 3.0 
deprecated functionality. So buffer objects and shaders for everything.

Slightly easier: these "shape" generators are convenience functions. 
Therefore, they should be quick, simple, and not very complicated. So 
they shouldn't burden the user with unnecessary details (like creating 
certain GL objects, etc). It should be an object that the user gets with 
which the user can draw, through a "DrawShape" function.

Harder: Unlike C++, C doesn't really have a language concept of data 
hiding. But data hiding is really important. Accessors are really 
important. It doesn't add any complexity to make an object opaque, so 
long as the object has appropriate accessor functions to get at 
necessary data. In short, I think shapes should be entirely opaque, not 
exposing the internal data structure to the user. Instead, they should 
just do their job.

My personal preference would be as follows:

typedef void* GLSshape;

GLSshape glsCreateShapePredefined(params);
void glsDestroyShape(GLSshape);
void glsDrawShape(GLSshape);

The first function uses "predefined" so that later we can add shapes 
that aren't predefined (loads from a file, user-created somehow, etc). 
The second function destroys the shape object. And the last binds and 
renders it using the state currently bound to the context.

It has the least chance of breakage (GLSshape is opaque, so the user 
can't mess with it), and is very self-contained. We may need accessors 
to query the attribute indices, or an API to specify attribute indices 
at creation time. But that's about it.

Re: [Glsdk-devel] SourceForge permissions

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

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

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

I added Rob to our project and I gave him everything we had.


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

This is not a big matter to me. I am interested to be a maintainer of the
main architech of the GLM library and possibly some other libraries also. I
could take an admin on Bugs.


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