Future of OpenGL package

[Andre Bleau]

Brian Ford wrote:
>...
> >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.
> >
>A lot of the functionallity I need is just the defines.  Ex:
>GL_MIRRORED_REPEAT_ARB  Here, I don't need to load any extensions.
>
>When I do need to load extensions, having the defines for the
>proper prototypes around would be nice.

1.2 and 1.3 defines & prototypes are already there in 
/usr/include/w32api/GL/glext.h

>...
> >>As for the extension loading library, it's a don't care for me.
> >
> >Then, I guess you never had to work with extensions...
> >
>No, I just don't think it is that hard to write code for it.

It's not hard to write new code that uses GL 1.2+ that targets only the 
Cygwin and Mingw platforms. What's hard is to port some code for UNIX that 
calls GL 1.2+ functions. You have to track each call and modify it to load 
the function first when compiled for Cygwin.

>...
> >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
> >
>Ok, but...
>
> >- Add glut.h to /usr/include/w32api/GL
> >
>That may not fly.  As I understand it, the w32api directories are only for
>headers/import libraries for DLLs that ship with MS, or at least mingw.

Old version sof the w32api package didn't provide any GL headers, so the 
OpenGL package was (and still is) creating a symlink from 
/usr/include/w32api/GL to /usr/include/GL. Then newer versions of the 
w32api package started to include GL headers in /usr/include/w32api/GL. As 
the last version of that package is newer than the last version of the 
OpenGL package, most people have the w32api headers instead of the symlink, 
but if you reinstall the OpenGL package, you will loose those headers and 
get the symlink.

So, there is a precedent for a glut.h in /usr/include/w32api/GL, in the 
form of a symlink.

>Is the glut DLL -mno-cygwin safe?  Then it might work if glut became part of
>mingw.

Yup. The GLUT dll does not depend on Cygwin, so compiling with -mno-cygwin 
works.


>Earnie?

Yeah, Earnie, where are you?

>...
>BTW, I guess you're probably not interested from your previous comments
>on the subject, but an Xfree based glut would be great to have.  I got a
>working imake compile once without too much trouble from the Nate Robins
>version.  If your still not interested in putting it in your glut package,
>maybe I'll propose to maintain one for Xfree.

The problem is that an XFree GLUT could only draw using an XFree GL. And 
XFree GL does not support hardware acceleration, so it is slower by a 
factor 10 to 100 when compared to Windows'GL. That's the main reason why I 
don't think an XFree GLUT is worth the trouble.



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/