Re: Future of OpenGL package (Earnie, please read this)

[Andre Bleau <bleau at igb dot umontreal dot ca>]

Brian Ford wrote:

> Andre Bleau wrote:
> ...
> >API to native Windows OpenGL implementation, accessible through M$'s
> >opengl32.dll could be in the w32api package, as it is now. The GL include
> >directory could be in /usr/include/w32api exclusively, without need for
> >another in /usr/include.
> >
> That sounds reasonable.  Would you make a sym link from /usr/include/GL to
> /usr/include/w32api/GL then?

No; if /usr/include/GL does not exist anymore, gcc will look in 
/usr/include/w32api/GL for #include <GL/gl.h> directives.


> >API to GLUT could be in a GLUT package, while the GLUT32.dll could be in
> >a GLUT-runtime package.
> >
> They are so small that it seems overkill to break them up.

I think you are right. Separating the lib (.a) and headers (.h) from the 
GLUT dll would only save a few Kbs for those who wants the dll.


> ...
>
> >>Are there any plans to update Cygwin's OpenGL headers to include 1.3 or
> >>1.4 support?  Be it via using the w32api Mesa ones, or by other means.
> >
> >Let that be clear: headers alone will not provide access to OpenGL 1.2+
> >functionnality. You will still have to program the loading of OpenGL
> >extensions, if they are available from the graphic card driver. Maybe
> >something like extgl 
> (<http://www.levp.de/3d/index.html>http://www.levp.de/3d/index.html) 
> could be packaged
> >for Cygwin to make that easier.
> >
> Sure, I know headers don't magically create functionality.  They just
> allow access to that which already exists.  But, most vendors these days
> (ATI & Nvidia) provide 1.3 or 1.4 functionality.  It would be nice to use
> it without jumping through hoops.

Even, with 1.4 headers, you would sill need to jump through hoops to use 
1.4 functionality. You will still need to load the functions dynamicaly 
before using them. You wouldn't be able to simply call the functions as 
when developing for UNIX.


> The way you added support for OpenGL 1.2 via a define would be fine.  BTW,
> what version does Microsoft ship with XP?  Is it still 1.1?  I don't have
> a "clean" XP install to check.

I do. It is still 1.1. I guess that M$ is so involved now with DirectX that 
they will never update the OpenGL dll.


> As for the extension loading library, it's a don't care for me.

Then, I guess you never had to work with extensions...


> >>Are there any plans to update Cygwin's glut to the current
> >>Nate Robins version?
> >
> >
> >Could be done; however, it is nearly 2 years old and provides no new
> >functionnality. It is sad, but GLUT is dead. There is a project in
> >sourceforge for a replacement: freeglut
> >(<http://freeglut.sourceforge.net/fg/>http://freeglut.sourceforge.net/fg/ 
> ), but is still IMO too buggy for
> >prime time. However, it is actively developped and debugged, and a stable
> >release is supposed to come "real soon".
> >
> Yeah, I know regular glut is dead.  I have looked at freeglut before
> and it looks interesting, but I will take your word for it that it is
> still too buggy.
>
> There have been significant changes since the glut version in Cygwin
> (3.7.3 Sept. 27, `00 now 3.7.6 Nov. 8, `01).  I'm not entirely sure if
> they are benneficial.  I've listed them below for anyone that's
> interested.  Maybe we should just wait for freeglut to stabilize, though.
> ...

I think we waited long enough for freeglut and some update of GLUT and GLUI 
is overdue.

So, I propose to make a quick update of the OpenGL package ASAP, while we 
wait for freeglut. To quick update would:

- Remove /usr/include/GL and rely on /usr/include/w32api/GL from the w32api 
package, that would be set as requesite
- Add glut.h to /usr/include/w32api/GL
- Update the GLUT dll to Nate Robin's 3.7.6
- Have GLUI and GLUIX libs compiled for gcc 3.3
- Move the doc to /usr/share/doc

What do you think?


André Bleau, Cygwin's OpenGL package maintainer.

Please address all questions and problem reports about Cygwin's OpenGL 
package to cygwin@cygwin.com . 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/