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