From: Andre Bleau <bleau@igb.umontreal.ca>
To: cygwin@cygwin.com
Subject: Re: Future of OpenGL package
Date: Tue, 30 Sep 2003 23:34:00 -0000 [thread overview]
Message-ID: <5.2.0.9.0.20030930183554.028cc478@irispavp.igb.umontreal.ca> (raw)
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/
next reply other threads:[~2003-09-30 23:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-30 23:34 Andre Bleau [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-10-01 15:36 Brian Ford
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=5.2.0.9.0.20030930183554.028cc478@irispavp.igb.umontreal.ca \
--to=bleau@igb.umontreal.ca \
--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).