From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-09-12 20:37:50
|
For a very good start, look in the header file "freeglut_ext.h". John F. Fay joh...@eg... -----Original Message----- From: James Jones [mailto:jam...@be...] Sent: Friday, September 12, 2003 1:38 PM To: fre...@li... Subject: [Freeglut-developer] 2.0.0 Feature List Freeglutans, In anticipation of the 2.0.0 final release's rapid approach, I want to compile a list of new features in the 2.0.0 release, compared to the 1.x.x series of freeglut. We have the Changelog, yes, but that's too microscopic of a view to be really enticing to our OSS audience. Let's start a list here on the mailing list, please! -- James 'Pug' Jones ".. it is a daunting concept no matter how easy it is" - chill, Slashdot user 34294, 6 Sept 2003 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-09-22 13:40:33
|
If your questions haven't been answered yet ... - The Sierpinski Sponge is the tetrahedral variant. - The shapes, except for the sponge, are taken from GLUT. I added the sponge because I was bored one day. The cone and torus are fairly standard; the teapot is whimsical, I will admit, but was included in GLUT; the rhombic dodecahedron is not quite Platonic but is still very regular; and the other five are the Platonic solids. - I will give serious consideration to your suggestion for a "glutGrabInput" as soon as the formal release is out the door and we have settled a couple of other high-priority issues. I will need to reread your e-mail to figure out exactly what you are asking for. John F. Fay joh...@eg... |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-09-22 13:43:39
|
Also we have a couple of new font functions to allow the user to print strings instead of one character at a time. John F. Fay joh...@eg... -----Original Message----- From: James Jones [mailto:jc...@uf...] Sent: Saturday, September 13, 2003 1:33 PM To: fre...@li... Subject: RE: [Freeglut-developer] 2.0.0 Feature List Well, this is what I have so far... Please help! We want this to be as impressive as the work done on the library -- that way when I submit this to Freshmeat and Slashdot, we'll make headlines based on the programming genius that went into this release! :) <snip> |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-09-22 13:44:45
|
What I think we did was create an option to allow windows to share their rendering contexts instead of creating a new one for each window. John F. Fay joh...@eg... -----Original Message----- From: Aleksandar Donev [mailto:adonev@Math.Princeton.EDU] Sent: Saturday, September 13, 2003 2:20 PM To: fre...@li... Subject: Re: [Freeglut-developer] 2.0.0 Feature List James Jones wrote: > Option to create a new rendering context for each new window There was some discussion of allowing windows to *share* the rendering context--under X at least they automatically have a new rendering context. Maybe you guys did something in the Windows version, but this does not sound right... Best, Aleks ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-09-22 13:49:24
|
Two things here ... (1) I agree that the list of shapes seems baroque. In fact, I will go further and say that it IS baroque. If anybody has some ideas for making it systematic (without removing anything we have already implemented ...) I'm willing to listen. I'll even help generate some of the shapes the next time I get bored. (2) I am SURE there is a way for Windows to keep the mouse pointer inside an individual window. There is a messaging call of some sort that happens when the mouse leaves the window and we can use the call to put the mouse back into the window. I'll look into it ... but not right away. Somebody please add it to the list of issues/features. John F. Fay joh...@eg... -----Original Message----- From: Richard Rauch [mailto:sf...@ol...] Sent: Saturday, September 13, 2003 4:01 PM To: fre...@li... Subject: Re: [Freeglut-developer] 2.0.0 Feature List <snip> My point was that it seems baroque. I wasn't accusing the freeglut team of instigating the teapot, but there seemed to be a lack of rhyme and reason to the shapes provided. <snip> [...] > > A "game mode" isn't quite enough, IMHO. I'd like to continue to > > see other windows (say mutt with new email appearing), so taking > > over the display isn't enough. As I understand it, "game mode" > > forces a full-screen display. > > There isn't a portable way to do what you ask. Hm. That's too bad. I would have thought that MS-WINDOWS would provide a way for you to wedge the pointer into your window. > > Comments? I assume that something like this can be done under > > MS-WINDOWS. If not...nevermind I guess. (^& > > It's a design goal of freeglut that we only implement stuff that > works everywhere. Exactly. That's why I said "If not...nevermind I guess." -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Steve B. <sjb...@ai...> - 2003-09-22 16:04:01
|
Fay John F Contr AAC/WMG wrote: > Two things here ... > (1) I agree that the list of shapes seems baroque. In fact, I will go > further and say that it IS baroque. If anybody has some ideas for > making it systematic (without removing anything we have already > implemented ...) I'm willing to listen. I'll even help generate some of > the shapes the next time I get bored. You have to ask what the practical REASON for haveing shapes built into GLUT is. It's not that 'real' applications are going to use the GLUT functions for drawing 'real' scenes. The built-in shapes are far to nastily implemented for that. The reason is that GLUT was written to provide a simple framework for the example programs in the OpenGL Programming Guide (the 'Red Book'). They didn't want to have to write about how to import a 3D model from a modelling package - and they didn't want to have to provide pages of coordinate data in the book. Instead, they opted to have GLUT be able to render a few simple shapes so that the examples could be short and yet still render something that showed off whichever feature was being implemented. The teapot is a perfect example of that. It is also occasionally useful when (for example) reporting a bug to a driver writer to be able to make a tiny demonstration of the bug using an API like GLUT that we all understand and can reproduce. Again, the existing platonic solids (including the teapot of course) is adequate. I don't think it's worth while to implement any new ones - but I don't think we should get all outraged and rip out the ones that have already been added. I'd hate to see someone getting excited about adding greater stellated icosohedrons, klein bottles and the cups and saucers that go with the teapot. > (2) I am SURE there is a way for Windows to keep the mouse pointer > inside an individual window. There is a messaging call of some sort > that happens when the mouse leaves the window and we can use the call to > put the mouse back into the window. I'll look into it ... but not right > away. Somebody please add it to the list of issues/features. Grabbing the mouse when it leaves the window is a crappy solution. In the time between the mouse leaving and you grabbing it again, you can already have lost focus and assigned a key or mouse stroke to some other application. In games, that simply doesn't work. If *all* supported OS's had a 'stop the mouse from ever leaving this window' function - then I'd be in favor of exposing it because it would be useful. However, as far as I know, they do not all have this. The 'best' solution (which my games use) is to use the existing 'glutWarpPointer' function to reposition the cursor in the center of the window on every call to the mouse passive motion callback. This works - although in theory, you could still move the mouse from the center to the outside of the window all in one update cycle...but you'd find it VERY difficult to do that by accident unless the game's frame rate is already unbearably slow. This is tried and tested - used by many games - portable - and already works in both GLUT and freeglut. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
From: Richard R. <sf...@ol...> - 2003-09-24 00:43:47
|
On Mon, Sep 22, 2003 at 11:03:19AM -0500, Steve Baker wrote: > Fay John F Contr AAC/WMG wrote: > >(2) I am SURE there is a way for Windows to keep the mouse pointer > >inside an individual window. There is a messaging call of some sort > >that happens when the mouse leaves the window and we can use the call to > >put the mouse back into the window. I'll look into it ... but not right > >away. Somebody please add it to the list of issues/features. > > Grabbing the mouse when it leaves the window is a crappy solution. In the Agreed. > time between the mouse leaving and you grabbing it again, you can already > have lost focus and assigned a key or mouse stroke to some other > application. > In games, that simply doesn't work. > > If *all* supported OS's had a 'stop the mouse from ever leaving this window' > function - then I'd be in favor of exposing it because it would be useful. > However, as far as I know, they do not all have this. Do you really know of a counter-example where it is not possible? What about other things that can't be 100% guaranteed to always work? (E.g., what is the minimum screen resolution that can be guaranteed? What if the user doesn't have a joystick, or the joystick doesn't work due to an OS bug or due to missing support in freeglut?) It is already possible to write programs that are non-portable. Making assumptions about screen size (hence window size and position) can lead to non-portable programs. If run on an X server without a window manager, the result of bad assumptions about resolution could be disasterous. IMHO, freeglut should strive to make it possible to write portable programs, and should provide common features in a portable interface. (E.g., joysticks: Not universally available, but where they are available, the author should have some confidence that glutJoystickFunc() will give them access.) freeglut may also strive to emulate absent features (e.g., GLUT_SINGLE can promote to GLUT_DOUBLE). This emulation should probably only be done where it is faultless. I do not think that it's necessary to make it impossible to write non-portable programs. Not least because you CAN'T make it impossible, even if the program sticks to freeglut and OpenGL calls. ("Porable", here, I assume means that the program has the same features and works the same way on different systems, not just that it compiles and doesn't bail out with errors when you try to run it---or bails with the same errors. (^&) It seems possible to implement this glutGrabPointer() function so that it works nearly everywhere (all MS-WINDOWS and all X11 systems for starters). It could be documented as not guaranteed to be supported. Like other features already in freeglut, it is conceivable that there are systems where it won't work. A suggested workaround of using glutWarpPointer() to (try to) fix the pointer within the window bounds could be listed---or, as with things like joystick, freeglut could just be silent on what to do where freeglut doesn't support the feature on the given host system. Requesting a feature not supported by the host *could* just silently fail. (This raises a side-issue of how to handle extensions via runtime checking. This is especially an issue since freeglut may be used as a dynamic-linked library in place of GLUT, so applications don't know what features have been removed or added. Header files aren't an option in that case... It seems that GLUT didn't have the foresight to offer this feature, so the only way to do this might be create *two* libraries: glut for 100% (bug-for-bug) GLUT compatibility, and freeglut which has extensions, possibly changed behavior, the extension-query system, ... It's an idea, anyway.) -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-09-22 16:13:01
|
<joke> Ooh! Ahh! Klein bottles! I simply MUST ... </joke> John F. Fay joh...@eg... -----Original Message----- From: Steve Baker [mailto:sjb...@ai...] Sent: Monday, September 22, 2003 11:03 AM To: fre...@li... Subject: Re: [Freeglut-developer] 2.0.0 Feature List <snip> I don't think it's worth while to implement any new ones - but I don't think we should get all outraged and rip out the ones that have already been added. I'd hate to see someone getting excited about adding greater stellated icosohedrons, klein bottles and the cups and saucers that go with the teapot. <snip> |
From: Richard R. <sf...@ol...> - 2003-09-13 04:53:34
|
John: Hm. It looks as if my system may have received your email about the scroll-wheel and post-2.x, John, but my mailbox doesn't show it. I don't think that I could have deleted it by accident. Weird. Anyway, I did notice that you're working on an official 2.x release. I realize that it's too late to make the cut for extending the mouse button support for 2.0.0. But I'd like to see button handling improved in the near future, and (at least for XFree86) there's an easy step to doing this that is compatible with what old GLUT did. That, in fact, is the primary reason that I'm in touch with the project rather than just silently building/packaging it for NetBSD. (^& -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Richard R. <sf...@ol...> - 2003-09-13 14:22:13
|
On Fri, Sep 12, 2003 at 03:37:42PM -0500, Fay John F Contr AAC/WMG wrote: > For a very good start, look in the header file "freeglut_ext.h". [...] I have a couple of questions (still feeling my way around freeglut). Well, kind of questions, kind of suggestions. (^& * Is the SierpinskySponge the "cube" or the "tetrahedron" variant? The tetrahedron, I thought, was called "Sierpinski's Gasket". The built-in shapes provided seem a bit baroque. We have a teapot, a cube, sphere, Sierpinski's Sponge, ... Is there anything systematic about this, or do people just come up with these when they are bored? (^& There are, if memory serves, 5 platonic solids. Are all 5 represented by GLUT/GLU primitives? (4, 6, 8, 12, and 20 sided polyhedra, I think.) If not, it may be worthwhile fleshing that out, at least. * How about a "grab" feature to grab the "input focus"? See the early OpenGL game Battalion (keyboard 'g', I believe) for an example of this under X. A "game mode" isn't quite enough, IMHO. I'd like to continue to see other windows (say mutt with new email appearing), so taking over the display isn't enough. As I understand it, "game mode" forces a full-screen display. If you don't have this "grab" mode, you can click the mouse, drag around, get the mouse off of the window, then have to release the mouse for some reason and...certainly any immediate click outside of the window is disaster! And depending on your window manager, the program may have just lost the input focus as soon as you release the button (or perhaps if you press another button). Similarly if you just move the mouse off of the window, with some window managers. Of course, any program that "grabs" the input focus needs to provide an easy and quick release. This could be left to the responsibility of the freeglut programmer, but it could be enforced by requiring that you register an "ungrab" event (probably a keypress) with freeglut when you request to "grab" the input. glutGrabInput ('g'); /*** toggle grab mode via 'g' key ***/ ...that's perhaps not the best way to do it, but suggests a way to help assure that there's a way out of "grab" mode the instant that the user requires it. 'g' in the window would act as a toggle, then, letting the user turn grab-mode on/off in that window, whenever they desire. Comments? I assume that something like this can be done under MS-WINDOWS. If not...nevermind I guess. (^& -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Steve B. <sjb...@ai...> - 2003-09-13 16:07:28
|
Richard Rauch wrote: > On Fri, Sep 12, 2003 at 03:37:42PM -0500, Fay John F Contr AAC/WMG wrote: > >>For a very good start, look in the header file "freeglut_ext.h". > > [...] > > I have a couple of questions (still feeling my way around freeglut). > Well, kind of questions, kind of suggestions. (^& > > * Is the SierpinskySponge the "cube" or the "tetrahedron" variant? > The tetrahedron, I thought, was called "Sierpinski's Gasket". No - the term "Gasket" is used to refer to the 2D version. (Think of the head gasket on a car - it's a thin sheet with lots of holes in it). "Sponge" is for the 3D analog of a Gasket. > The built-in shapes provided seem a bit baroque. We have a teapot, > a cube, sphere, Sierpinski's Sponge, ... Is there anything > systematic about this, or do people just come up with these when > they are bored? (^& The reason for the teapot is entirely historical - it is the sixth platonic solid. I refer you to my FAQ: http://www.sjbaker.org/teapot/ GLUT has it - and so do we because we aim to be compatible. The Sierinski sponge is included because someone felt like writing it! However it does have a use - it's an established graphic performance benchmark. > There are, if memory serves, 5 platonic solids. No - there are 6 - you are forgetting the teapot :-) > Are all 5 > represented by GLUT/GLU primitives? (4, 6, 8, 12, and 20 sided > polyhedra, I think.) If not, it may be worthwhile fleshing that > out, at least. They are all supposed to be there. glutSolidTetrahedron - 4 glutSolidCube - 6 (You could argue for 'glutSolidHexahedron' here.) glutSolidOctahedron - 8 glutSolidDodecahedron - 12 glutSolidIcosahedron - 20 glutSolidTeapot - Infinite > * How about a "grab" feature to grab the "input focus"? That's called: "glutWarpPointer" - it moves the mouse to the specified coordinate. If you have the system set up to give focus to the window under the mouse then this will obviously give you input focus too. If you have 'click to focus' set up, then you won't have the problem if losing focus if the mouse never strays from the window - which it won't if you warp the mouse to the middle of the window every frame. Both of my games do this - and they work just fine. > A "game mode" isn't quite enough, IMHO. I'd like to continue to > see other windows (say mutt with new email appearing), so taking > over the display isn't enough. As I understand it, "game mode" > forces a full-screen display. There isn't a portable way to do what you ask. > Comments? I assume that something like this can be done under > MS-WINDOWS. If not...nevermind I guess. (^& It's a design goal of freeglut that we only implement stuff that works everywhere. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
From: Richard R. <sf...@ol...> - 2003-09-13 21:01:19
|
On Sat, Sep 13, 2003 at 11:06:04AM -0500, Steve Baker wrote: > Richard Rauch wrote: > >On Fri, Sep 12, 2003 at 03:37:42PM -0500, Fay John F Contr AAC/WMG wrote: > > > >>For a very good start, look in the header file "freeglut_ext.h". > > > > [...] > > > >I have a couple of questions (still feeling my way around freeglut). > >Well, kind of questions, kind of suggestions. (^& > > > > * Is the SierpinskySponge the "cube" or the "tetrahedron" variant? > > The tetrahedron, I thought, was called "Sierpinski's Gasket". > > No - the term "Gasket" is used to refer to the 2D version. (Think of > the head gasket on a car - it's a thin sheet with lots of holes in it). > "Sponge" is for the 3D analog of a Gasket. I thought that Sierpinski's Triangle was the 2D version, but I checked and you're right. I no longer am even sure that Sirpinski's Carpet is the square. (^& So, what's the name for the tetrahedron? Or the cube? > > The built-in shapes provided seem a bit baroque. We have a teapot, > > a cube, sphere, Sierpinski's Sponge, ... Is there anything > > systematic about this, or do people just come up with these when > > they are bored? (^& > > The reason for the teapot is entirely historical - it is the sixth > platonic solid. I refer you to my FAQ: I'm familiar with something of the history of the Utah Teapot (well, that's the name that I first heard of for it). (^& My point was that it seems baroque. I wasn't accusing the freeglut team of instigating the teapot, but there seemed to be a lack of rhyme and reason to the shapes provided. [...] > The Sierinski sponge is included because someone felt like writing > it! However it does have a use - it's an established graphic performance > benchmark. "Because someone felt like writing it" is about what I meant by "came up with when they were bored". (^& > > There are, if memory serves, 5 platonic solids. > > No - there are 6 - you are forgetting the teapot :-) Oh, right! Did Euclid know about this one? Or was this the Second Pythagorean Scandal, after irrational numbers? > > Are all 5 > > represented by GLUT/GLU primitives? (4, 6, 8, 12, and 20 sided > > polyhedra, I think.) If not, it may be worthwhile fleshing that > > out, at least. > > They are all supposed to be there. > > glutSolidTetrahedron - 4 > glutSolidCube - 6 (You could argue for 'glutSolidHexahedron' > here.) > glutSolidOctahedron - 8 > glutSolidDodecahedron - 12 > glutSolidIcosahedron - 20 > glutSolidTeapot - Infinite Cool. > > * How about a "grab" feature to grab the "input focus"? > > That's called: "glutWarpPointer" - it moves the mouse to the specified Not the same. Having a mouse-pointer "shiver" in the center isn't the same as having it fixed into the window's boundary. And at least in theory a scene could be so complicated (especially on a software rendering system this would not be hard to accomplish) that the mouse can move entirely OFF the window between frames. glutWarpPointer() may have uses, but applying it for this end is a hack, not a solution, IMHO. I'm sure it often works; hacks often do. I'd still rather have a solution. (^& Still, if it's the best that can be done with MS-WINDOWS, then it's the best that an MS-WINDOWS-supporting program can do. (sigh) I was hoping that something better was possible. [...] > > A "game mode" isn't quite enough, IMHO. I'd like to continue to > > see other windows (say mutt with new email appearing), so taking > > over the display isn't enough. As I understand it, "game mode" > > forces a full-screen display. > > There isn't a portable way to do what you ask. Hm. That's too bad. I would have thought that MS-WINDOWS would provide a way for you to wedge the pointer into your window. > > Comments? I assume that something like this can be done under > > MS-WINDOWS. If not...nevermind I guess. (^& > > It's a design goal of freeglut that we only implement stuff that > works everywhere. Exactly. That's why I said "If not...nevermind I guess." -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: James J. <jc...@uf...> - 2003-09-13 18:33:33
|
Well, this is what I have so far... Please help! We want this to be as impressive as the work done on the library -- that way when I submit this to Freshmeat and Slashdot, we'll make headlines based on the programming genius that went into this release! :) Freeglut Additions: New behaviors for when the user clicks on an "x" to close the window. (Immediate exit, glutMainLoop returns, Continue execution) Option to create a new rendering context for each new window Interruptable glutMainLoop (glutMainLoopEvent, glutLeaveMainLoop) Window-specific callback functions (Close, WindowManager Close, Menu destruction) User-specified data in Windows and Menus Additional font statistics (stroke and bitmap heights...) New primitives (RhombicDodecahedron, SierpinskiSponge) Good-looking menus -- James 'Pug' Jones ".. it is a daunting concept no matter how easy it is" - chill, Slashdot user 34294, 6 Sept 2003 -- James 'Pug' Jones ".. it is a daunting concept no matter how easy it is" - chill, Slashdot user 34294, 6 Sept 2003 |
From: Aleksandar D. <adonev@Math.Princeton.EDU> - 2003-09-13 19:20:28
|
James Jones wrote: > Option to create a new rendering context for each new window There was some discussion of allowing windows to *share* the rendering context--under X at least they automatically have a new rendering context. Maybe you guys did something in the Windows version, but this does not sound right... Best, Aleks |
From: Richard R. <sf...@ol...> - 2003-09-13 21:15:42
|
On Sat, Sep 13, 2003 at 02:33:29PM -0400, James Jones wrote: > Well, this is what I have so far... > > Please help! We want this to be as impressive as the work done on the > library -- that way when I submit this to Freshmeat and Slashdot, we'll > make headlines based on the programming genius that went into this > release! > > :) > > > Freeglut Additions: > > New behaviors for when the user clicks on an "x" to close the window. > (Immediate exit, glutMainLoop returns, Continue execution) Maybe better to call it the "close box", or even to leave off assuming that there is a window-manager-provided widget for this. E.g., under twm, you go to the root window and bring up a menu for "deleting" or "killing". Killing will presumably send a kill signal to the application. Deleting a window just deletes the one window. (I don't use these often, as 99% of the applications that I deal with have an explicitly provided "exit" function so I don't need to go to twm to tell the program to exit.) Most applications gracefully handle it when you delete (close) one of their windows. GLUT exits if you delete one of its windows, as if you had killed the whole application. I asssume that "close one of the windows" corresponds to "click on an ``x''" here. Alright, it's a nit-pick. (^& But I'm pretty sure that some more popular-than-twm window managers provide window-bound menues for killing and still lack an actual "x" widget for killing. (Okay, just about *anything* is more popular than twm. That's beside the point!) I am not familiar with exactly how the new behavior works, but I'd suggest dropping the wm-specific reference to an "x". Instead, maybe something like: You can now control program behavior when a GLUT window is closed by the user, rather than simply exiting. Options include: Immediate exit() (old GLUT behavior) glutMainLoop() returns to you continue execution ...about the rest, I have no comment. Just my 2.718281828459045 (and a bit) cents. -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Bernhard K. <ber...@gm...> - 2003-09-14 09:33:33
|
If you are not only interested in new features, but also in bugfixes: You can also look at the manually maintained ChangeLog file for some hints and at e.g. the "cvsps" output to see some automaticially generated changelog. From the glutGameMode view, I've composed this list of improvements: XFree86 GameMode improvements: - force re-establishment of the original video mode by the X server even if the applicatiton exits immediately after leaving game mode - make sure that the X server has finished game mode preparations before continuing; fixes window sliding(missed mouse grab) and application exits. - fix support for game mode resolution equal to maximum screen resolution - restore original view port and Pointer position when leaving game mode Win32 GameMode improvements: - if desired display frequency for entering game mode is not found, a display mode without matching display frequency is tried. Bernhard On Sat, 13 Sep 2003, James Jones wrote: > Well, this is what I have so far... > > Please help! We want this to be as impressive as the work done on the > library -- that way when I submit this to Freshmeat and Slashdot, we'll > make headlines based on the programming genius that went into this > release! > > :) > > > Freeglut Additions: > > New behaviors for when the user clicks on an "x" to close the window. > (Immediate exit, glutMainLoop returns, Continue execution) > > Option to create a new rendering context for each new window > > Interruptable glutMainLoop (glutMainLoopEvent, glutLeaveMainLoop) > > Window-specific callback functions (Close, WindowManager Close, Menu > destruction) > > User-specified data in Windows and Menus > > Additional font statistics (stroke and bitmap heights...) > > New primitives (RhombicDodecahedron, SierpinskiSponge) > > Good-looking menus > > > -- > James 'Pug' Jones > ".. it is a daunting concept no matter how easy it is" > - chill, Slashdot user 34294, 6 Sept 2003 > -- > James 'Pug' Jones > ".. it is a daunting concept no matter how easy it is" > - chill, Slashdot user 34294, 6 Sept 2003 > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > Bernhard -- "The exclusive right to invention [is] given not of natural right, but for the benefit of society." -- Thomas Jefferson Quote: "The civilisation advances not by thinking what we are doing, but by being able to do things whithout thinking about them" Free Software: The most effective way put the above into practice. Software patents: Owning ideas for 20 years helps lawers, not the society |