This is the mail archive of the 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

Andre Bleau wrote:

>Brian Ford wrote:
>>Andre Bleau wrote:
>>>Brian Ford wrote:
>1.2 and 1.3 defines & prototypes are already there in
Yes, I know.  That statement started this thread.

They (1.3+) are not available in /usr/include/GL/gl.h which is now found
first by gcc 3.3.1.  Also. /usr/include/GL/gl.h and
/usr/include/w32api/glext.h are not compatible.

I think we are in agreement here.

>>>>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.
Now I understand your statement.  Igor's idea looks like a workable one
here too, and it would be more transparent.  Just my 2c.

>>>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
>Old versions of 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.
Most people have them there, true.  But with gcc 3.3.1, they don't get
them right now because of the include path precedence.

Just clarifying.

>So, there is a precedent for a glut.h in /usr/include/w32api/GL, in the
>form of a symlink.
There is a precedent to allow this symlink in Cygwin, yes.  There isn't a
precedent to put glut.h in w32api/GL.  But, I'll just shut up now and stop
speculating about what Earnie will allow in w32api.

>>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.
Great!  If glut becomes a mingw package too, then my point above is
probably moot.  Since I am not a mingw developer, my point above is
probably already moot. (I confess to not know anything about mingw
packages and distribution.)

>Yeah, Earnie, where are you?
I don't want to SPAM, but should we CC the mingw-users list now?

>>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 you're 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.
True, but XFree may eventually have a pass through mechanism like on MacOS
(I can hope, can't I?  If I ever get time, I might actually impliment it.
:-D)  And, there are a few weird people that actually want to do indirect
remote GLX with glut :).

Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

Unsubscribe info:
Problem reports:

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