From: Brian Ford <ford@vss.fsi.com>
To: cygwin@cygwin.com
Subject: Re: Future of OpenGL package
Date: Wed, 01 Oct 2003 15:36:00 -0000 [thread overview]
Message-ID: <Pine.GSO.4.56.0310010925100.12522@eos> (raw)
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/
next reply other threads:[~2003-10-01 15:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-01 15:36 Brian Ford [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-09-30 23:34 Andre Bleau
2003-09-26 0:22 Brian Ford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.GSO.4.56.0310010925100.12522@eos \
--to=ford@vss.fsi.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).