Future of OpenGL package
Tue Sep 30 23:34:00 GMT 2003
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
> >>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
> >- 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
Yup. The GLUT dll does not depend on Cygwin, so compiling with -mno-cygwin
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 email@example.com .
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin