Mail Archives: cygwin/2003/10/01/11:17:33
Andre Bleau wrote:
>Brian Ford wrote:
>
>>Andre Bleau wrote:
>>
>>>Brian Ford wrote:
>>>
>
>1.2 and 1.3 defines & prototypes are already there in
>/usr/include/w32api/GL/glext.h
>
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
>>mingw.
>>
>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.)
>>Earnie?
>>
>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: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -