This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Future of OpenGL package


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]