Menu
▾
▴
glsdk-devel
|
From: H. H. <hen...@gm...> - 2008-08-24 16:09:20
|
Here are some general ideas for GLSDK utility libraries. What libraries do we need? - OpenGL Math Library (GLM, nicknamed 'mathlib') for 3d math, under development by me... - OpenGL Shape Library (GLS, nicknamed 'shapelib') for basic 3d geometry drawing and perhaps model loading, under development by branan... - OpenGL Extension Library (GLE, nicknamed 'extlib') for GL3 context creation and API loading, under development by korval... - texture loading? I know two libraries for this; developer's image library (devil) and freeimage. FreeImage is a C library, but does not have OpenGL look & feel DevIL is a C library too and has somewhat OpenGL look & feel I am thinking that we might also want to develop imagelib of our own, which would just contain entry points that just simple load an image from a file and return it as GL texture: // load image and return it as texture GLuint gltLoadTexture (const char *filename); // load image, convert it to the given format and return as texture GLuint gltLoadTexture2 (const char *filename, GLenum format); // load from a buffer GLuint gltLoadBuf (const GLvoid *buf, GLsizei size); (the entry point names are debatable) DevIL has some nasties; it does not return textures directly etc. - windowing system abstraction? Candidates; GLUT and GLFW. we could also choose to implement our own windowlib that woudl integrate into our GLE. This library would have features for opening windows, creating simple menu bars, input processing etc. - anything else? -- Henri 'henux' Häkkinen |
|
From: Jason M. <ko...@gm...> - 2008-08-24 18:21:32
|
Henri Häkkinen wrote: > Here are some general ideas for GLSDK utility libraries. > > What libraries do we need? > > - OpenGL Math Library (GLM, nicknamed 'mathlib') for 3d math, under > development by me... > > - OpenGL Shape Library (GLS, nicknamed 'shapelib') for basic 3d > geometry drawing and perhaps model loading, under development by branan... > > - OpenGL Extension Library (GLE, nicknamed 'extlib') for GL3 context > creation and API loading, under development by korval... > > - texture loading? I know two libraries for this; developer's image > library (devil) and freeimage. > > FreeImage is a C library, but does not have OpenGL look & feel > DevIL is a C library too and has somewhat OpenGL look & feel I tried to use DevIL once, but I was unable to make it work. Also, until litterally yesterday, DevIL hadn't had a release in 2 years. FreeImage seems much more in development. > > I am thinking that we might also want to develop imagelib of our own, > which would just contain entry points that just simple load an image > from a file and return it as GL texture: > > // load image and return it as texture > GLuint gltLoadTexture (const char *filename); > > // load image, convert it to the given format and return as texture > GLuint gltLoadTexture2 (const char *filename, GLenum format); > > // load from a buffer > GLuint gltLoadBuf (const GLvoid *buf, GLsizei size); These loading functions are convenience functions, after all. Whether we internally use FreeImage, DevIL, or libpng directly is not something that should be exposed to the user. That's an implementation detail, and so it should be hidden from the user. > > (the entry point names are debatable) DevIL has some nasties; it does > not return textures directly etc. > > - windowing system abstraction? Candidates; GLUT and GLFW. we could > also choose to implement our own windowlib that woudl integrate into > our GLE. This library would have features for opening windows, > creating simple menu bars, input processing etc. Creating a window with an OpenGL context is the limit of what we should provide. Now, that being said, there is something to be said for being able to handle input to some degree. This is mostly for examples and demos, so it can wait. |
|
From: H. H. <hen...@gm...> - 2008-08-24 18:36:22
|
I think having a simple menu bar would also be beneficial for the demos, as you could change some of the demo parameters from that interface. Such as, back face culling, front face winding etc. This is open for a debate. On Sun, Aug 24, 2008 at 9:22 PM, Jason McKesson <ko...@gm...> wrote: > Henri Häkkinen wrote: > > Here are some general ideas for GLSDK utility libraries. > > > > What libraries do we need? > > > > - OpenGL Math Library (GLM, nicknamed 'mathlib') for 3d math, under > > development by me... > > > > - OpenGL Shape Library (GLS, nicknamed 'shapelib') for basic 3d > > geometry drawing and perhaps model loading, under development by > branan... > > > > - OpenGL Extension Library (GLE, nicknamed 'extlib') for GL3 context > > creation and API loading, under development by korval... > > > > - texture loading? I know two libraries for this; developer's image > > library (devil) and freeimage. > > > > FreeImage is a C library, but does not have OpenGL look & feel > > DevIL is a C library too and has somewhat OpenGL look & feel > I tried to use DevIL once, but I was unable to make it work. Also, until > litterally yesterday, DevIL hadn't had a release in 2 years. FreeImage > seems much more in development. > > > > I am thinking that we might also want to develop imagelib of our own, > > which would just contain entry points that just simple load an image > > from a file and return it as GL texture: > > > > // load image and return it as texture > > GLuint gltLoadTexture (const char *filename); > > > > // load image, convert it to the given format and return as texture > > GLuint gltLoadTexture2 (const char *filename, GLenum format); > > > > // load from a buffer > > GLuint gltLoadBuf (const GLvoid *buf, GLsizei size); > These loading functions are convenience functions, after all. Whether we > internally use FreeImage, DevIL, or libpng directly is not something > that should be exposed to the user. That's an implementation detail, and > so it should be hidden from the user. > > > > (the entry point names are debatable) DevIL has some nasties; it does > > not return textures directly etc. > > > > - windowing system abstraction? Candidates; GLUT and GLFW. we could > > also choose to implement our own windowlib that woudl integrate into > > our GLE. This library would have features for opening windows, > > creating simple menu bars, input processing etc. > Creating a window with an OpenGL context is the limit of what we should > provide. > > Now, that being said, there is something to be said for being able to > handle input to some degree. This is mostly for examples and demos, so > it can wait. > > > ------------------------------------------------------------------------- > 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 |
|
From: Stefanos A. <sta...@gm...> - 2008-08-25 08:32:15
|
On Sun, 2008-08-24 at 21:36 +0300, =?ISO-8859-1?Q? Henri_H=E4kkinen _
wrote:
> I think having a simple menu bar would also be beneficial for the
> demos, as you could change some of the demo parameters from that
> interface. Such as, back face culling, front face winding etc. This is
> open for a debate.
>
> On Sun, Aug 24, 2008 at 9:22 PM, Jason McKesson <ko...@gm...>
> wrote:
> Henri Häkkinen wrote:
> > - windowing system abstraction? Candidates; GLUT and GLFW.
> we could
> > also choose to implement our own windowlib that woudl
> integrate into
> > our GLE. This library would have features for opening
> windows,
> > creating simple menu bars, input processing etc.
>
> Creating a window with an OpenGL context is the limit of what
> we should
> provide.
>
> Now, that being said, there is something to be said for being
> able to
> handle input to some degree. This is mostly for examples and
> demos, so
> it can wait.
When you implement all this, you are basically left with a less portable, buggier(*) version of GLFW/GLUT. There's really no good reason to avoid GLFW - it follows the GL naming conventions, is lightweight, simple and to the point:
glfwInit();
/* w h r g b a d s GLFW_WINDOW */
glfwOpenWindow(640, 480, 8, 8, 8, 8, 16, 0, GLFW_FULLSCREEN);
while (glfwGetKey() != GLFW_KEY_ESC) /* Callbacks supported too */
glfwSleep(0.01);
glfwTerminate();
Which covers everything the sdk samples are going to need.
(*) Just look at the source code of GLFW. They work around several
win32/x11/osx bugs so that the library works the same everywhere.
Speaking from experience, this is no easy feat.
|
|
From: H. H. <hen...@gm...> - 2008-08-25 15:29:27
|
GLFW/GLUT is the thing we should use if they can get a OpenGL3 support and our extlib can tap into it. On Mon, Aug 25, 2008 at 11:32 AM, Stefanos A. <sta...@gm...> wrote: > On Sun, 2008-08-24 at 21:36 +0300, =?ISO-8859-1?Q? Henri_H=E4kkinen _ > wrote: > > I think having a simple menu bar would also be beneficial for the > > demos, as you could change some of the demo parameters from that > > interface. Such as, back face culling, front face winding etc. This is > > open for a debate. > > > > On Sun, Aug 24, 2008 at 9:22 PM, Jason McKesson <ko...@gm...> > > wrote: > > Henri Häkkinen wrote: > > > - windowing system abstraction? Candidates; GLUT and GLFW. > > we could > > > also choose to implement our own windowlib that woudl > > integrate into > > > our GLE. This library would have features for opening > > windows, > > > creating simple menu bars, input processing etc. > > > > Creating a window with an OpenGL context is the limit of what > > we should > > provide. > > > > Now, that being said, there is something to be said for being > > able to > > handle input to some degree. This is mostly for examples and > > demos, so > > it can wait. > > When you implement all this, you are basically left with a less portable, > buggier(*) version of GLFW/GLUT. There's really no good reason to avoid GLFW > - it follows the GL naming conventions, is lightweight, simple and to the > point: > > glfwInit(); > /* w h r g b a d s GLFW_WINDOW */ > glfwOpenWindow(640, 480, 8, 8, 8, 8, 16, 0, GLFW_FULLSCREEN); > > while (glfwGetKey() != GLFW_KEY_ESC) /* Callbacks supported too */ > glfwSleep(0.01); > > glfwTerminate(); > > Which covers everything the sdk samples are going to need. > > (*) Just look at the source code of GLFW. They work around several > win32/x11/osx bugs so that the library works the same everywhere. > Speaking from experience, this is no easy feat. > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Glsdk-devel mailing list > Gls...@li... > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > -- Henri 'henux' Häkkinen |
|
From: H. H. <hen...@gm...> - 2008-08-25 17:44:59
|
I had an idea that we could fork from GLFW, strip it to the minium needs of the SDK and maybe tweak the API a bit to make it more streamlined into our style. This would have the following benefits: - we have our own windowing layer that we can control, yet don't need to implement it from scratch - we don't depend on external dependencies We could also ask from the author of GLFW, if s/he would like to join our SDK project as the maintainer-developer of the GLFW-fork. The windowlib is not yet the topic but we should give this possibility a serious thought. On Mon, Aug 25, 2008 at 6:29 PM, Henri Häkkinen <hen...@gm...> wrote: > GLFW/GLUT is the thing we should use if they can get a OpenGL3 support and > our extlib can tap into it. > > > On Mon, Aug 25, 2008 at 11:32 AM, Stefanos A. <sta...@gm...> wrote: > >> On Sun, 2008-08-24 at 21:36 +0300, =?ISO-8859-1?Q? Henri_H=E4kkinen _ >> wrote: >> > I think having a simple menu bar would also be beneficial for the >> > demos, as you could change some of the demo parameters from that >> > interface. Such as, back face culling, front face winding etc. This is >> > open for a debate. >> > >> > On Sun, Aug 24, 2008 at 9:22 PM, Jason McKesson <ko...@gm...> >> > wrote: >> > Henri Häkkinen wrote: >> > > - windowing system abstraction? Candidates; GLUT and GLFW. >> > we could >> > > also choose to implement our own windowlib that woudl >> > integrate into >> > > our GLE. This library would have features for opening >> > windows, >> > > creating simple menu bars, input processing etc. >> > >> > Creating a window with an OpenGL context is the limit of what >> > we should >> > provide. >> > >> > Now, that being said, there is something to be said for being >> > able to >> > handle input to some degree. This is mostly for examples and >> > demos, so >> > it can wait. >> >> When you implement all this, you are basically left with a less portable, >> buggier(*) version of GLFW/GLUT. There's really no good reason to avoid GLFW >> - it follows the GL naming conventions, is lightweight, simple and to the >> point: >> >> glfwInit(); >> /* w h r g b a d s GLFW_WINDOW */ >> glfwOpenWindow(640, 480, 8, 8, 8, 8, 16, 0, GLFW_FULLSCREEN); >> >> while (glfwGetKey() != GLFW_KEY_ESC) /* Callbacks supported too */ >> glfwSleep(0.01); >> >> glfwTerminate(); >> >> Which covers everything the sdk samples are going to need. >> >> (*) Just look at the source code of GLFW. They work around several >> win32/x11/osx bugs so that the library works the same everywhere. >> Speaking from experience, this is no easy feat. >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Glsdk-devel mailing list >> Gls...@li... >> https://lists.sourceforge.net/lists/listinfo/glsdk-devel >> > > > > -- > Henri 'henux' Häkkinen > > -- Henri 'henux' Häkkinen |
|
From: <gl...@mo...> - 2008-08-25 19:11:01
|
> I had an idea that we could fork from GLFW, strip it to the minium needs > of > the SDK and maybe tweak the API a bit to make it more streamlined into our > style. I'd vote against. Let's try not to start our work by just putting more and more work on ourselves ;) Having support from GLFW author(s) would be nice though. I'd keep the library as it is and extend it to support OpenGL 3.0. That's it. Going back to general discussion. I'll focus on things that I believe haven't been decided yet. 1. Math It's Henri's lib for most of tutorial/sample stuff and possibly my lib for tech demos only (these meant to show capabilities of OpenGL). However if people will prefer to use other math lib, then mine should be excluded from SDK. Three is a crowd. 2. Platform abstraction I'm all for GLFW here. Anyway we have to make decision soon enough. 3. Texture library I'm using FreeImage and I'm a happy man ;) Too bad it doesn't have it's own namespace though. > // load image and return it as texture > GLuint gltLoadTexture (const char *filename); > > // load image, convert it to the given format and return as texture > GLuint gltLoadTexture2 (const char *filename, GLenum format); > > // load from a buffer > GLuint gltLoadBuf (const GLvoid *buf, GLsizei size); I strongly object the idea of wrapping glTexImage. Let's just provide a way to load/store/free image. Uploading to OpenGL should be done without hepler functions. Don't forget that we're teaching OpenGL here ;) This library should come with some basic texture package like brickwalls, normalmaps, environment cubemaps (some in float format) and some textures for teaching alpha blending and alpha testing. 4. Shader library I also suggest limiting this part to helper functions for loading shader from file and a structure to store shader code. We should teach people to create programs, shaders and bind them together. Otherwise we're not teaching them how to use OpenGL but our helper functions. What shader library should really be is... shader library :) But I guess that's obvious. So, our TODO list extends by textures, shaders and some meshes later. Since I can't find ehough time recently and things tend to get even worse I'm not declaring to be of any help - I'll just focus on my math library for now. Cheers. |
|
From: Mars_999 <ma...@si...> - 2008-08-25 18:10:57
|
I am going to throw this out there, since you are going to ask the author to modify the GLFW api to work with glSDK, could we just roll the extension loader into that version? I am assuming GLE is the extension loader? Instead of having so many different sections to the SDK? Or are we trying to keep the SDK more modular.
----- Original Message -----
From: Henri Häkkinen
To: gls...@li...
Sent: Monday, August 25, 2008 12:45 PM
Subject: Re: [Glsdk-devel] util. lib brainstorming
I had an idea that we could fork from GLFW, strip it to the minium needs of the SDK and maybe tweak the API a bit to make it more streamlined into our style. This would have the following benefits:
- we have our own windowing layer that we can control, yet don't need to implement it from scratch
- we don't depend on external dependencies
We could also ask from the author of GLFW, if s/he would like to join our SDK project as the maintainer-developer of the GLFW-fork.
The windowlib is not yet the topic but we should give this possibility a serious thought.
On Mon, Aug 25, 2008 at 6:29 PM, Henri Häkkinen <hen...@gm...> wrote:
GLFW/GLUT is the thing we should use if they can get a OpenGL3 support and our extlib can tap into it.
On Mon, Aug 25, 2008 at 11:32 AM, Stefanos A. <sta...@gm...> wrote:
On Sun, 2008-08-24 at 21:36 +0300, =?ISO-8859-1?Q? Henri_H=E4kkinen _
wrote:
> I think having a simple menu bar would also be beneficial for the
> demos, as you could change some of the demo parameters from that
> interface. Such as, back face culling, front face winding etc. This is
> open for a debate.
>
> On Sun, Aug 24, 2008 at 9:22 PM, Jason McKesson <ko...@gm...>
> wrote:
> Henri Häkkinen wrote:
> > - windowing system abstraction? Candidates; GLUT and GLFW.
> we could
> > also choose to implement our own windowlib that woudl
> integrate into
> > our GLE. This library would have features for opening
> windows,
> > creating simple menu bars, input processing etc.
>
> Creating a window with an OpenGL context is the limit of what
> we should
> provide.
>
> Now, that being said, there is something to be said for being
> able to
> handle input to some degree. This is mostly for examples and
> demos, so
> it can wait.
When you implement all this, you are basically left with a less portable, buggier(*) version of GLFW/GLUT. There's really no good reason to avoid GLFW - it follows the GL naming conventions, is lightweight, simple and to the point:
glfwInit();
/* w h r g b a d s GLFW_WINDOW */
glfwOpenWindow(640, 480, 8, 8, 8, 8, 16, 0, GLFW_FULLSCREEN);
while (glfwGetKey() != GLFW_KEY_ESC) /* Callbacks supported too */
glfwSleep(0.01);
glfwTerminate();
Which covers everything the sdk samples are going to need.
(*) Just look at the source code of GLFW. They work around several
win32/x11/osx bugs so that the library works the same everywhere.
Speaking from experience, this is no easy feat.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Glsdk-devel mailing list
Gls...@li...
https://lists.sourceforge.net/lists/listinfo/glsdk-devel
--
Henri 'henux' Häkkinen
--
Henri 'henux' Häkkinen
------------------------------------------------------------------------------
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
------------------------------------------------------------------------------
_______________________________________________
Glsdk-devel mailing list
Gls...@li...
https://lists.sourceforge.net/lists/listinfo/glsdk-devel
|
|
From: H. H. <hen...@gm...> - 2008-08-25 18:30:58
|
On Mon, Aug 25, 2008 at 9:10 PM, Mars_999 <ma...@si...> wrote: > I am going to throw this out there, since you are going to ask the author > to modify the GLFW api to work with glSDK, could we just roll the extension > loader into that version? I am assuming GLE is the extension loader? Instead > of having so many different sections to the SDK? Or are we trying to keep > the SDK more modular. > > It was just a thought. At the moment, we are not concerned with the windowlib yet (me and branan are the only active developers yet and we have our hands full, I think Korval may be working on GLE but we haven't heard from it in some days). I think it would be a better idea to separate the GLE (our proposed extlib) and GLW (our proposed windowlib), but the GLW may directly call GLE. This allows the possibility to use GLE as a separate library also. Things are open for debate... > ----- Original Message ----- > *From:* Henri Häkkinen <hen...@gm...> > *To:* gls...@li... > *Sent:* Monday, August 25, 2008 12:45 PM > *Subject:* Re: [Glsdk-devel] util. lib brainstorming > > I had an idea that we could fork from GLFW, strip it to the minium needs of > the SDK and maybe tweak the API a bit to make it more streamlined into our > style. This would have the following benefits: > > - we have our own windowing layer that we can control, yet don't need to > implement it from scratch > - we don't depend on external dependencies > > We could also ask from the author of GLFW, if s/he would like to join our > SDK project as the maintainer-developer of the GLFW-fork. > > The windowlib is not yet the topic but we should give this possibility a > serious thought. > > > On Mon, Aug 25, 2008 at 6:29 PM, Henri Häkkinen <hen...@gm...>wrote: > >> GLFW/GLUT is the thing we should use if they can get a OpenGL3 support and >> our extlib can tap into it. >> >> >> On Mon, Aug 25, 2008 at 11:32 AM, Stefanos A. <sta...@gm...>wrote: >> >>> On Sun, 2008-08-24 at 21:36 +0300, =?ISO-8859-1?Q? Henri_H=E4kkinen _ >>> wrote: >>> > I think having a simple menu bar would also be beneficial for the >>> > demos, as you could change some of the demo parameters from that >>> > interface. Such as, back face culling, front face winding etc. This is >>> > open for a debate. >>> > >>> > On Sun, Aug 24, 2008 at 9:22 PM, Jason McKesson <ko...@gm...> >>> > wrote: >>> > Henri Häkkinen wrote: >>> > > - windowing system abstraction? Candidates; GLUT and GLFW. >>> > we could >>> > > also choose to implement our own windowlib that woudl >>> > integrate into >>> > > our GLE. This library would have features for opening >>> > windows, >>> > > creating simple menu bars, input processing etc. >>> > >>> > Creating a window with an OpenGL context is the limit of what >>> > we should >>> > provide. >>> > >>> > Now, that being said, there is something to be said for being >>> > able to >>> > handle input to some degree. This is mostly for examples and >>> > demos, so >>> > it can wait. >>> >>> When you implement all this, you are basically left with a less portable, >>> buggier(*) version of GLFW/GLUT. There's really no good reason to avoid GLFW >>> - it follows the GL naming conventions, is lightweight, simple and to the >>> point: >>> >>> glfwInit(); >>> /* w h r g b a d s GLFW_WINDOW */ >>> glfwOpenWindow(640, 480, 8, 8, 8, 8, 16, 0, GLFW_FULLSCREEN); >>> >>> while (glfwGetKey() != GLFW_KEY_ESC) /* Callbacks supported too */ >>> glfwSleep(0.01); >>> >>> glfwTerminate(); >>> >>> Which covers everything the sdk samples are going to need. >>> >>> (*) Just look at the source code of GLFW. They work around several >>> win32/x11/osx bugs so that the library works the same everywhere. >>> Speaking from experience, this is no easy feat. >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>> challenge >>> Build the coolest Linux based applications with Moblin SDK & win great >>> prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the >>> world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> Glsdk-devel mailing list >>> Gls...@li... >>> https://lists.sourceforge.net/lists/listinfo/glsdk-devel >>> >> >> >> >> -- >> Henri 'henux' Häkkinen >> >> > > > -- > Henri 'henux' Häkkinen > > ------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > ------------------------------ > > _______________________________________________ > Glsdk-devel mailing list > Gls...@li... > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Glsdk-devel mailing list > Gls...@li... > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > > -- Henri 'henux' Häkkinen |
|
From: Jason M. <ko...@gm...> - 2008-08-25 18:55:04
|
I agree that extension loading should be a separate operation from window creation/management. And yes, I'm still working on it, but it'll take some time. I'll probably have something to check in by the end of this weekend. Granted, it won't be 3.0 compatible, but we'll get there once the new .spec files come online. On Mon, Aug 25, 2008 at 11:31 AM, Henri Häkkinen <hen...@gm...> wrote: > > > On Mon, Aug 25, 2008 at 9:10 PM, Mars_999 <ma...@si...> wrote: >> >> I am going to throw this out there, since you are going to ask the author >> to modify the GLFW api to work with glSDK, could we just roll the extension >> loader into that version? I am assuming GLE is the extension loader? Instead >> of having so many different sections to the SDK? Or are we trying to keep >> the SDK more modular. >> > > It was just a thought. > > At the moment, we are not concerned with the windowlib yet (me and branan > are the only active developers yet and we have our hands full, I think > Korval may be working on GLE but we haven't heard from it in some days). I > think it would be a better idea to separate the GLE (our proposed extlib) > and GLW (our proposed windowlib), but the GLW may directly call GLE. This > allows the possibility to use GLE as a separate library also. Things are > open for debate... > >> >> ----- Original Message ----- >> From: Henri Häkkinen >> To: gls...@li... >> Sent: Monday, August 25, 2008 12:45 PM >> Subject: Re: [Glsdk-devel] util. lib brainstorming >> I had an idea that we could fork from GLFW, strip it to the minium needs >> of the SDK and maybe tweak the API a bit to make it more streamlined into >> our style. This would have the following benefits: >> >> - we have our own windowing layer that we can control, yet don't need to >> implement it from scratch >> - we don't depend on external dependencies >> >> We could also ask from the author of GLFW, if s/he would like to join our >> SDK project as the maintainer-developer of the GLFW-fork. >> >> The windowlib is not yet the topic but we should give this possibility a >> serious thought. >> >> >> On Mon, Aug 25, 2008 at 6:29 PM, Henri Häkkinen <hen...@gm...> >> wrote: >>> >>> GLFW/GLUT is the thing we should use if they can get a OpenGL3 support >>> and our extlib can tap into it. >>> >>> On Mon, Aug 25, 2008 at 11:32 AM, Stefanos A. <sta...@gm...> >>> wrote: >>>> >>>> On Sun, 2008-08-24 at 21:36 +0300, =?ISO-8859-1?Q? Henri_H=E4kkinen _ >>>> wrote: >>>> > I think having a simple menu bar would also be beneficial for the >>>> > demos, as you could change some of the demo parameters from that >>>> > interface. Such as, back face culling, front face winding etc. This is >>>> > open for a debate. >>>> > >>>> > On Sun, Aug 24, 2008 at 9:22 PM, Jason McKesson <ko...@gm...> >>>> > wrote: >>>> > Henri Häkkinen wrote: >>>> > > - windowing system abstraction? Candidates; GLUT and GLFW. >>>> > we could >>>> > > also choose to implement our own windowlib that woudl >>>> > integrate into >>>> > > our GLE. This library would have features for opening >>>> > windows, >>>> > > creating simple menu bars, input processing etc. >>>> > >>>> > Creating a window with an OpenGL context is the limit of what >>>> > we should >>>> > provide. >>>> > >>>> > Now, that being said, there is something to be said for being >>>> > able to >>>> > handle input to some degree. This is mostly for examples and >>>> > demos, so >>>> > it can wait. >>>> >>>> When you implement all this, you are basically left with a less >>>> portable, buggier(*) version of GLFW/GLUT. There's really no good reason to >>>> avoid GLFW - it follows the GL naming conventions, is lightweight, simple >>>> and to the point: >>>> >>>> glfwInit(); >>>> /* w h r g b a d s GLFW_WINDOW */ >>>> glfwOpenWindow(640, 480, 8, 8, 8, 8, 16, 0, GLFW_FULLSCREEN); >>>> >>>> while (glfwGetKey() != GLFW_KEY_ESC) /* Callbacks supported too */ >>>> glfwSleep(0.01); >>>> >>>> glfwTerminate(); >>>> >>>> Which covers everything the sdk samples are going to need. >>>> >>>> (*) Just look at the source code of GLFW. They work around several >>>> win32/x11/osx bugs so that the library works the same everywhere. >>>> Speaking from experience, this is no easy feat. >>>> >>>> >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>>> challenge >>>> Build the coolest Linux based applications with Moblin SDK & win great >>>> prizes >>>> Grand prize is a trip for two to an Open Source event anywhere in the >>>> world >>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>> _______________________________________________ >>>> Glsdk-devel mailing list >>>> Gls...@li... >>>> https://lists.sourceforge.net/lists/listinfo/glsdk-devel >>> >>> >>> >>> -- >>> Henri 'henux' Häkkinen >>> >> >> >> >> -- >> Henri 'henux' Häkkinen >> >> ________________________________ >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> >> ________________________________ >> >> _______________________________________________ >> Glsdk-devel mailing list >> Gls...@li... >> https://lists.sourceforge.net/lists/listinfo/glsdk-devel >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Glsdk-devel mailing list >> Gls...@li... >> https://lists.sourceforge.net/lists/listinfo/glsdk-devel >> > > > > -- > Henri 'henux' Häkkinen > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Glsdk-devel mailing list > Gls...@li... > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > > |
|
From: H. H. <hen...@gm...> - 2008-08-25 19:05:19
|
Sounds good! On Mon, Aug 25, 2008 at 9:55 PM, Jason McKesson <ko...@gm...> wrote: > I agree that extension loading should be a separate operation from > window creation/management. > > And yes, I'm still working on it, but it'll take some time. I'll > probably have something to check in by the end of this weekend. > Granted, it won't be 3.0 compatible, but we'll get there once the new > .spec files come online. > > On Mon, Aug 25, 2008 at 11:31 AM, Henri Häkkinen <hen...@gm...> > wrote: > > > > > > On Mon, Aug 25, 2008 at 9:10 PM, Mars_999 <ma...@si...> wrote: > >> > >> I am going to throw this out there, since you are going to ask the > author > >> to modify the GLFW api to work with glSDK, could we just roll the > extension > >> loader into that version? I am assuming GLE is the extension loader? > Instead > >> of having so many different sections to the SDK? Or are we trying to > keep > >> the SDK more modular. > >> > > > > It was just a thought. > > > > At the moment, we are not concerned with the windowlib yet (me and branan > > are the only active developers yet and we have our hands full, I think > > Korval may be working on GLE but we haven't heard from it in some days). > I > > think it would be a better idea to separate the GLE (our proposed extlib) > > and GLW (our proposed windowlib), but the GLW may directly call GLE. This > > allows the possibility to use GLE as a separate library also. Things are > > open for debate... > > > >> > >> ----- Original Message ----- > >> From: Henri Häkkinen > >> To: gls...@li... > >> Sent: Monday, August 25, 2008 12:45 PM > >> Subject: Re: [Glsdk-devel] util. lib brainstorming > >> I had an idea that we could fork from GLFW, strip it to the minium needs > >> of the SDK and maybe tweak the API a bit to make it more streamlined > into > >> our style. This would have the following benefits: > >> > >> - we have our own windowing layer that we can control, yet don't need to > >> implement it from scratch > >> - we don't depend on external dependencies > >> > >> We could also ask from the author of GLFW, if s/he would like to join > our > >> SDK project as the maintainer-developer of the GLFW-fork. > >> > >> The windowlib is not yet the topic but we should give this possibility a > >> serious thought. > >> > >> > >> On Mon, Aug 25, 2008 at 6:29 PM, Henri Häkkinen <hen...@gm...> > >> wrote: > >>> > >>> GLFW/GLUT is the thing we should use if they can get a OpenGL3 support > >>> and our extlib can tap into it. > >>> > >>> On Mon, Aug 25, 2008 at 11:32 AM, Stefanos A. <sta...@gm...> > >>> wrote: > >>>> > >>>> On Sun, 2008-08-24 at 21:36 +0300, =?ISO-8859-1?Q? Henri_H=E4kkinen _ > >>>> wrote: > >>>> > I think having a simple menu bar would also be beneficial for the > >>>> > demos, as you could change some of the demo parameters from that > >>>> > interface. Such as, back face culling, front face winding etc. This > is > >>>> > open for a debate. > >>>> > > >>>> > On Sun, Aug 24, 2008 at 9:22 PM, Jason McKesson <ko...@gm...> > >>>> > wrote: > >>>> > Henri Häkkinen wrote: > >>>> > > - windowing system abstraction? Candidates; GLUT and GLFW. > >>>> > we could > >>>> > > also choose to implement our own windowlib that woudl > >>>> > integrate into > >>>> > > our GLE. This library would have features for opening > >>>> > windows, > >>>> > > creating simple menu bars, input processing etc. > >>>> > > >>>> > Creating a window with an OpenGL context is the limit of > what > >>>> > we should > >>>> > provide. > >>>> > > >>>> > Now, that being said, there is something to be said for > being > >>>> > able to > >>>> > handle input to some degree. This is mostly for examples and > >>>> > demos, so > >>>> > it can wait. > >>>> > >>>> When you implement all this, you are basically left with a less > >>>> portable, buggier(*) version of GLFW/GLUT. There's really no good > reason to > >>>> avoid GLFW - it follows the GL naming conventions, is lightweight, > simple > >>>> and to the point: > >>>> > >>>> glfwInit(); > >>>> /* w h r g b a d s GLFW_WINDOW */ > >>>> glfwOpenWindow(640, 480, 8, 8, 8, 8, 16, 0, GLFW_FULLSCREEN); > >>>> > >>>> while (glfwGetKey() != GLFW_KEY_ESC) /* Callbacks supported too */ > >>>> glfwSleep(0.01); > >>>> > >>>> glfwTerminate(); > >>>> > >>>> Which covers everything the sdk samples are going to need. > >>>> > >>>> (*) Just look at the source code of GLFW. They work around several > >>>> win32/x11/osx bugs so that the library works the same everywhere. > >>>> Speaking from experience, this is no easy feat. > >>>> > >>>> > >>>> > >>>> > ------------------------------------------------------------------------- > >>>> This SF.Net email is sponsored by the Moblin Your Move Developer's > >>>> challenge > >>>> Build the coolest Linux based applications with Moblin SDK & win great > >>>> prizes > >>>> Grand prize is a trip for two to an Open Source event anywhere in the > >>>> world > >>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >>>> _______________________________________________ > >>>> Glsdk-devel mailing list > >>>> Gls...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/glsdk-devel > >>> > >>> > >>> > >>> -- > >>> Henri 'henux' Häkkinen > >>> > >> > >> > >> > >> -- > >> Henri 'henux' Häkkinen > >> > >> ________________________________ > >> > >> > ------------------------------------------------------------------------- > >> This SF.Net email is sponsored by the Moblin Your Move Developer's > >> challenge > >> Build the coolest Linux based applications with Moblin SDK & win great > >> prizes > >> Grand prize is a trip for two to an Open Source event anywhere in the > >> world > >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >> > >> ________________________________ > >> > >> _______________________________________________ > >> Glsdk-devel mailing list > >> Gls...@li... > >> https://lists.sourceforge.net/lists/listinfo/glsdk-devel > >> > >> > ------------------------------------------------------------------------- > >> This SF.Net email is sponsored by the Moblin Your Move Developer's > >> challenge > >> Build the coolest Linux based applications with Moblin SDK & win great > >> prizes > >> Grand prize is a trip for two to an Open Source event anywhere in the > >> world > >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >> _______________________________________________ > >> Glsdk-devel mailing list > >> Gls...@li... > >> https://lists.sourceforge.net/lists/listinfo/glsdk-devel > >> > > > > > > > > -- > > Henri 'henux' Häkkinen > > > > > > ------------------------------------------------------------------------- > > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > > Build the coolest Linux based applications with Moblin SDK & win great > > prizes > > Grand prize is a trip for two to an Open Source event anywhere in the > world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > Glsdk-devel mailing list > > Gls...@li... > > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Glsdk-devel mailing list > Gls...@li... > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > -- Henri 'henux' Häkkinen |
|
From: Mars_999 <ma...@si...> - 2008-08-25 19:19:37
|
As for textures what about Nvidias texture library file they have? They have a texture pack on their developer site for use. It has normal maps and textures, ect... I am fine with GLFW it support all three platforms and that is the main goal for now, if some other platform needs it, they could port the tutorials(SDK) to their platform if they want to. I would venture to say someone will port this all to Java/JOGL someday if it gets finished... and we aren't coding Java for the SDK so I would expect it. ----- Original Message ----- From: <gl...@mo...> To: <gls...@li...> Sent: Monday, August 25, 2008 2:10 PM Subject: Re: [Glsdk-devel] util. lib brainstorming >> I had an idea that we could fork from GLFW, strip it to the minium needs >> of >> the SDK and maybe tweak the API a bit to make it more streamlined into >> our >> style. > > I'd vote against. Let's try not to start our work by just putting more and > more work on ourselves ;) > Having support from GLFW author(s) would be nice though. I'd keep the > library as it is and extend it to support OpenGL 3.0. That's it. > > > Going back to general discussion. > I'll focus on things that I believe haven't been decided yet. > > 1. Math > It's Henri's lib for most of tutorial/sample stuff and possibly my lib for > tech demos only (these meant to show capabilities of OpenGL). > > However if people will prefer to use other math lib, then mine should be > excluded from SDK. Three is a crowd. > > > > 2. Platform abstraction > I'm all for GLFW here. Anyway we have to make decision soon enough. > > > > 3. Texture library > I'm using FreeImage and I'm a happy man ;) Too bad it doesn't have it's > own namespace though. > >> // load image and return it as texture >> GLuint gltLoadTexture (const char *filename); >> >> // load image, convert it to the given format and return as texture >> GLuint gltLoadTexture2 (const char *filename, GLenum format); >> >> // load from a buffer >> GLuint gltLoadBuf (const GLvoid *buf, GLsizei size); > > I strongly object the idea of wrapping glTexImage. > Let's just provide a way to load/store/free image. Uploading to OpenGL > should be done without hepler functions. Don't forget that we're teaching > OpenGL here ;) > > This library should come with some basic texture package like brickwalls, > normalmaps, environment cubemaps (some in float format) and some textures > for teaching alpha blending and alpha testing. > > > > 4. Shader library > > I also suggest limiting this part to helper functions for loading shader > from file and a structure to store shader code. We should teach people to > create programs, shaders and bind them together. Otherwise we're not > teaching them how to use OpenGL but our helper functions. > > What shader library should really be is... shader library :) > But I guess that's obvious. > > > So, our TODO list extends by textures, shaders and some meshes later. > > > Since I can't find ehough time recently and things tend to get even worse > I'm not declaring to be of any help - I'll just focus on my math library > for now. > > Cheers. > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Glsdk-devel mailing list > Gls...@li... > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > |
|
From: Branan R. <br...@gm...> - 2008-08-25 19:26:26
|
If no one else has gotten in touch with the GLFW people yet, I'll get in touch with them, talk to them about our design goals for the SDK, and see if we can integrate them into our SVN (maybe using svn externals on a stable tagged version so we don't actually duplicate anything) On Mon, Aug 25, 2008 at 12:19 PM, Mars_999 <ma...@si...> wrote: > As for textures what about Nvidias texture library file they have? They have > a texture pack on their developer site for use. It has normal maps and > textures, ect... > > I am fine with GLFW it support all three platforms and that is the main goal > for now, if some other platform needs it, they could port the tutorials(SDK) > to their platform if they want to. I would venture to say someone will port > this all to Java/JOGL someday if it gets finished... and we aren't coding > Java for the SDK so I would expect it. > > > > ----- Original Message ----- > From: <gl...@mo...> > To: <gls...@li...> > Sent: Monday, August 25, 2008 2:10 PM > Subject: Re: [Glsdk-devel] util. lib brainstorming > > >>> I had an idea that we could fork from GLFW, strip it to the minium needs >>> of >>> the SDK and maybe tweak the API a bit to make it more streamlined into >>> our >>> style. >> >> I'd vote against. Let's try not to start our work by just putting more and >> more work on ourselves ;) >> Having support from GLFW author(s) would be nice though. I'd keep the >> library as it is and extend it to support OpenGL 3.0. That's it. >> >> >> Going back to general discussion. >> I'll focus on things that I believe haven't been decided yet. >> >> 1. Math >> It's Henri's lib for most of tutorial/sample stuff and possibly my lib for >> tech demos only (these meant to show capabilities of OpenGL). >> >> However if people will prefer to use other math lib, then mine should be >> excluded from SDK. Three is a crowd. >> >> >> >> 2. Platform abstraction >> I'm all for GLFW here. Anyway we have to make decision soon enough. >> >> >> >> 3. Texture library >> I'm using FreeImage and I'm a happy man ;) Too bad it doesn't have it's >> own namespace though. >> >>> // load image and return it as texture >>> GLuint gltLoadTexture (const char *filename); >>> >>> // load image, convert it to the given format and return as texture >>> GLuint gltLoadTexture2 (const char *filename, GLenum format); >>> >>> // load from a buffer >>> GLuint gltLoadBuf (const GLvoid *buf, GLsizei size); >> >> I strongly object the idea of wrapping glTexImage. >> Let's just provide a way to load/store/free image. Uploading to OpenGL >> should be done without hepler functions. Don't forget that we're teaching >> OpenGL here ;) >> >> This library should come with some basic texture package like brickwalls, >> normalmaps, environment cubemaps (some in float format) and some textures >> for teaching alpha blending and alpha testing. >> >> >> >> 4. Shader library >> >> I also suggest limiting this part to helper functions for loading shader >> from file and a structure to store shader code. We should teach people to >> create programs, shaders and bind them together. Otherwise we're not >> teaching them how to use OpenGL but our helper functions. >> >> What shader library should really be is... shader library :) >> But I guess that's obvious. >> >> >> So, our TODO list extends by textures, shaders and some meshes later. >> >> >> Since I can't find ehough time recently and things tend to get even worse >> I'm not declaring to be of any help - I'll just focus on my math library >> for now. >> >> Cheers. >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Glsdk-devel mailing list >> Gls...@li... >> https://lists.sourceforge.net/lists/listinfo/glsdk-devel >> > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Glsdk-devel mailing list > Gls...@li... > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > |
|
From: H. H. <hen...@gm...> - 2008-08-25 20:04:14
|
We may discuss and you may contact the GLFW folks but there is absolutely no kind of hurry. We might also want to discuss of using freeglut or a fork of it for our SDK. GLUT is simpler, but GLFW more advanced, which is better? For tutorials, GLUT-like system may be enought and more cohorent. About image library and wrapping glTexImage: An imagelib wrapping glTexImage may be a good idea. We will need tutorials on different levels: 1) Beginner level, which explains the basic usage of OpenGL3. At this level, we don't use other than the mathlib, extlib and windowlib (no shapelib or imagelib involved). We probably also want to create platform-specific tutorials, like how to create GL context with WGL, GLX, CGL, even EGL... 2) Intermadiate level, which explains stuff like shader programs and some tricks. At this level we don't want to involve low-level stuff like loading images and objects, so we can wrap them in libs. 3) Advanced level; shader effects... For initial SDK releases, we focus on beginner level, then move on to intermediate and finally into advanced... On Mon, Aug 25, 2008 at 10:26 PM, Branan Riley <br...@gm...> wrote: > If no one else has gotten in touch with the GLFW people yet, I'll get > in touch with them, talk to them about our design goals for the SDK, > and see if we can integrate them into our SVN (maybe using svn > externals on a stable tagged version so we don't actually duplicate > anything) > > On Mon, Aug 25, 2008 at 12:19 PM, Mars_999 <ma...@si...> wrote: > > As for textures what about Nvidias texture library file they have? They > have > > a texture pack on their developer site for use. It has normal maps and > > textures, ect... > > > > I am fine with GLFW it support all three platforms and that is the main > goal > > for now, if some other platform needs it, they could port the > tutorials(SDK) > > to their platform if they want to. I would venture to say someone will > port > > this all to Java/JOGL someday if it gets finished... and we aren't coding > > Java for the SDK so I would expect it. > > > > > > > > ----- Original Message ----- > > From: <gl...@mo...> > > To: <gls...@li...> > > Sent: Monday, August 25, 2008 2:10 PM > > Subject: Re: [Glsdk-devel] util. lib brainstorming > > > > > >>> I had an idea that we could fork from GLFW, strip it to the minium > needs > >>> of > >>> the SDK and maybe tweak the API a bit to make it more streamlined into > >>> our > >>> style. > >> > >> I'd vote against. Let's try not to start our work by just putting more > and > >> more work on ourselves ;) > >> Having support from GLFW author(s) would be nice though. I'd keep the > >> library as it is and extend it to support OpenGL 3.0. That's it. > >> > >> > >> Going back to general discussion. > >> I'll focus on things that I believe haven't been decided yet. > >> > >> 1. Math > >> It's Henri's lib for most of tutorial/sample stuff and possibly my lib > for > >> tech demos only (these meant to show capabilities of OpenGL). > >> > > >> However if people will prefer to use other math lib, then mine should be > >> excluded from SDK. Three is a crowd. > >> > > >> > >> > >> 2. Platform abstraction > >> I'm all for GLFW here. Anyway we have to make decision soon enough. > >> > >> > >> > >> 3. Texture library > >> I'm using FreeImage and I'm a happy man ;) Too bad it doesn't have it's > >> own namespace though. > >> > >>> // load image and return it as texture > >>> GLuint gltLoadTexture (const char *filename); > >>> > >>> // load image, convert it to the given format and return as texture > >>> GLuint gltLoadTexture2 (const char *filename, GLenum format); > >>> > >>> // load from a buffer > >>> GLuint gltLoadBuf (const GLvoid *buf, GLsizei size); > >> > >> I strongly object the idea of wrapping glTexImage. > >> Let's just provide a way to load/store/free image. Uploading to OpenGL > >> should be done without hepler functions. Don't forget that we're > teaching > >> OpenGL here ;) > >> > >> This library should come with some basic texture package like > brickwalls, > >> normalmaps, environment cubemaps (some in float format) and some > textures > >> for teaching alpha blending and alpha testing. > >> > >> > >> > >> 4. Shader library > >> > >> I also suggest limiting this part to helper functions for loading shader > >> from file and a structure to store shader code. We should teach people > to > >> create programs, shaders and bind them together. Otherwise we're not > >> teaching them how to use OpenGL but our helper functions. > >> > >> What shader library should really be is... shader library :) > >> But I guess that's obvious. > >> > >> > >> So, our TODO list extends by textures, shaders and some meshes later. > >> > >> > >> Since I can't find ehough time recently and things tend to get even > worse > >> I'm not declaring to be of any help - I'll just focus on my math library > >> for now. > >> > >> Cheers. > >> > >> > >> > ------------------------------------------------------------------------- > >> This SF.Net email is sponsored by the Moblin Your Move Developer's > >> challenge > >> Build the coolest Linux based applications with Moblin SDK & win great > >> prizes > >> Grand prize is a trip for two to an Open Source event anywhere in the > >> world > >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >> _______________________________________________ > >> Glsdk-devel mailing list > >> Gls...@li... > >> https://lists.sourceforge.net/lists/listinfo/glsdk-devel > >> > > > > > > ------------------------------------------------------------------------- > > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > > Build the coolest Linux based applications with Moblin SDK & win great > prizes > > Grand prize is a trip for two to an Open Source event anywhere in the > world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > Glsdk-devel mailing list > > Gls...@li... > > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Glsdk-devel mailing list > Gls...@li... > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > -- Henri 'henux' Häkkinen |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X