Re: Future of OpenGL package

[Brian Ford <ford@vss.fsi.com>]

Andre Bleau wrote:

>Brian Ford wrote:
>
>>I am glad that the ambiguity in gcc include search paths has been
>>resolved.  However, the OpenGL includes in w32api/GL are from Mesa, and
>>are thus more complete and up-to-date.
>
>Well, I hope that Earnie Boyd, maintainer for the w32api package, will
>join this discussion.
>
I hope so too.

>>What are the long term plans, if any, for reconciling these two
>>implementations?  It seems silly to have two copies of esstially the
>>same thing.
>
>I agree. Maybe it's time to break-up the OpenGL package into several
>parts:
>
To be honest, I don't really care how it gets packaged.  But I will be
glad to help if it attains an end.

>API to native Windows OpenGL implementation, accessible through M$'s
>opengl32.dll could be in the w32api package, as it is now. The GL include
>directory could be in /usr/include/w32api exclusively, without need for
>another in /usr/include.
>
That sounds reasonable.  Would you make a sym link from /usr/include/GL to
/usr/include/w32api/GL then?

>API to GLUT could be in a GLUT package, while the GLUT32.dll could be in
>a GLUT-runtime package.
>
They are so small that it seems overkill to break them up.

>API to GLUI and GLUIX could be in a GLUI package. There is no dll for
>both of these. They are C++ static libraries that would need to be repackaged
>each time that the C++ interface changes, as has been the case between
>g++ 2.95, 3.2, and now 3.3. I hope that this interface will remain stable for
>a while now.
>
I have never used these.  I understand your pain with C++ ABIs, though.

>>Are there any plans to update Cygwin's OpenGL headers to include 1.3 or
>>1.4 support?  Be it via using the w32api Mesa ones, or by other means.
>
>Let that be clear: headers alone will not provide access to OpenGL 1.2+
>functionnality. You will still have to program the loading of OpenGL
>extensions, if they are available from the graphic card driver. Maybe
>something like extgl (http://www.levp.de/3d/index.html) could be packaged
>for Cygwin to make that easier.
>
Sure, I know headers don't magically create functionality.  They just
allow access to that which already exists.  But, most vendors these days
(ATI & Nvidia) provide 1.3 or 1.4 functionality.  It would be nice to use
it without jumping through hoops.

The way you added support for OpenGL 1.2 via a define would be fine.  BTW,
what version does Microsoft ship with XP?  Is it still 1.1?  I don't have
a "clean" XP install to check.

As for the extension loading library, it's a don't care for me.

>>Are there any plans to update Cygwin's glut to the current
>>Nate Robins version?
>
>
>Could be done; however, it is nearly 2 years old and provides no new
>functionnality. It is sad, but GLUT is dead. There is a project in
>sourceforge for a replacement: freeglut
>(http://freeglut.sourceforge.net/fg/), but is still IMO too buggy for
>prime time. However, it is actively developped and debugged, and a stable
>release is supposed to come "real soon".
>
Yeah, I know regular glut is dead.  I have looked at freeglut before
and it looks interesting, but I will take your word for it that it is
still too buggy.

There have been significant changes since the glut version in Cygwin
(3.7.3 Sept. 27, `00 now 3.7.6 Nov. 8, `01).  I'm not entirely sure if
they are benneficial.  I've listed them below for anyone that's
interested.  Maybe we should just wait for freeglut to stabilize, though.

    (Nov 8, '01)
    x  Changed fullscreen mode from TOPMOST back to simply TOP, since
       (it turns out) many people use windows atop a GLUT window.

    (Nov 8, '01)
    x  Added code to prevent CPU spiking when no idle function is
       registered.  Otherwise, if an idle function is registered, spike
       CPU so that the idle function gets all the attention it needs and
       if this is a problem on the program side, the user can stick a
       sleep() in their idle function.  I believe that this strikes the
       best balance betweeen GLUT being fast, and also being "nice" to
       other processes.  Thanks to James Wright for reporting this bug.

    (Nov 8, '01)
    x  Fixed bug in motion callback handler which wasn't setting the
       current window, so multiple window apps (e.g., any GLUI app)
       wouldn't get the callback correctly.

    (Oct 4, '01)
    x  Fixed bug in glutEnterGameMode() that caused new windows to not
       be in "fullscreen" mode, so they got window decorations.

    (Oct 3, '01)
    x  Fixed bug in getVisualInfoFromString(): visuals not reloaded on
       display mode change.  Reload visuals each time they are queried.
       This fixes a problem with Win32 because the list of availabe Visuals
       (Pixelformats) changes after a change in displaymode. The problem
       occurs when switching to gamemode and back.  Thanks to Michael
       Wimmer for pointing this out & providing the fix.

    (Oct 3, '01)
    x  Fixed bug in XGetVisualInfo(): pixelformats enumerated incorrectly.
       Passing 0 as a pixelformat index to DescribePixelFormat gives
       unpredictible results (e.g., this fails on the Voodoo opengl32.dll
       and always reports 0 as the last available pixelformat index).
       Thanks to Michael Wimmer for pointing this out & providing the fix.

    (Oct 3, '01)
    x  Fixed bug in glXGetConfig(): pixelformats enumerated incorrectly.
       The test was OpenGL support OR draw to window, but should be AND.
       Thanks to Michael Wimmer for pointing this out & providing the fix.

    (Sep 28, '01)
    x  Fixed glutChangeToSubMenu()/glutChangeToMenuEntry() bug where if you
       went back and forth between a submenu and a plain entry, the submenu
       wouldn't be updated properly.

   (Sep 28, '01)
    x  glutSetIconTitle() is now a nop.

    (Sep 28, '01)
    x  glutFullScreen() now sets the window as TOPMOST, therefore, the
    window will always be on top (this essentially disables alt-tabbing).

    (Sep 28, '01)
    x  The key repeat ignore flag is now honored correctly.

    (Sep 28, '01)
    x  Key presses are now reported more accurately and fully, in
       particular, modified up events (i.e., SHIFT-2) are now reported
       correctly.

    (Sep 28, '01)
    x  Subwindows nested arbitrarily deep get their keyboard callbacks
       correctly now.

    (Sep 28, '01)
    x  Major rewrite of the window procedure code to clean it up and make
       way for other bug fixes.

    (Sep 23, '01)
    x  Fixed noof example program to use RAND_MAX instead of assumed
       max of 2147483647.0.  (Now it looks _much_ better!)

    (Sep 22, '01)
    x  Fixed sunlight example program.  globe.raw data file was corrupt,
       added a new one.

    (Sep 22, '01)
    x  Fixed zcomposite example program to print message if overlay
       support is not found (instead of crashing).

    (Jan 22, '01)
    x  Fixed malloc(0) bug in Win32 version of XGetVisualInfo.  Thanks
       to Kekoa Proudfoot for bringing this to my attention.

    (Dec 12, '00)
    x  Added data files for the advanced & advanced97 programs.

    (Dec 12, '00)
    x  Added Developer Studio 6 project and workspace files for pretty
       much everything (the stuff left out was usually unix specific).

    (Dec 7, '00)
    x  Fixed several compilation problems & corrupt files.  Thanks to
       Alexander Stohr for bringing these to my attention and providing
       detailed fixes.

    (Dec 6, '00)
    x  Fixed compiler support for lcc.  Thanks to Gordon for bringing
       this to my attention and debugging fixes.

    (Nov 8, '00)
    x  Fixed submenu problem (sometimes the menu callback was not
       called for valid items).  Thanks to Michael Keeley.

    (Oct 16, '00)
    x  Corrected corrupt duck.iv file.  Thanks to Jon Willeke for finding
       this problem.

-- 
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/