From: Richard R. <sf...@ol...> - 2004-02-03 21:50:04
|
On Tue, Feb 03, 2004 at 03:41:18PM +0100, wave++ wrote: > On Tue, Feb 03, 2004 at 01:06:47AM -0600, Richard Rauch wrote: > > For gamemode...well...(shrug) I'm not sure what old GLUT's goals were > > with it. I am not sure that gamemode was ever actually part of a [...] > I suppose the only real goal was gaining more perfomance out of windows > (and probably still makes difference). Maybe. Or maybe it was just to make your system look and feel more like a game-console that was plugged into a TV set? Or maybe it was a response to programmer requests to gain more control over the display, without checking first to see if the user thought that it was a good idea. Or it might have been, "I want full screen size for my graphics, but can't get decent framerates with that many pixels, so le's just change the resolution to something that I can handle..." > > Second, my understanding of the freeglut goals are to be GLUT-compatible > > whereever GLUT's behavior is unambiguous. Where GLUT is ambiguous (e.g., > > the way that menus look and act), freeglut picks one of GLUT's old > > behaviors and makes that *the* way that GLUT acts everywhere, as best > > it can. This is what is happening with gamemode, and it is failing > > to fully support SGI/Sun's X server with the definition of "gamemode" > > that freeglut is aiming for. > > I can safely assume that gamemode was probably a windows hack that ended > necessary to support examples on other systems. If we take that > interpretation, yes, I agree that it should be removed. My problem with gamemode is simply that it has ambiguous semantics. [...] > > It is also a very clean API. For the most part, it doesn't have > > overlapping features, and most things are pretty well thought out > > for easy, yet powerful, expression. (Of course, it is also partly > > helped that GLUT has modest goals, so it doesn't have a lot > > of seldom-used cruft.) > > Freeglut is quite at a good point actually. Apart of some minor things > like these, and probably the menus. At least, I tested some GLUI > applications (from the examples) with no noticeable glitches. There is a bug report in the freeglut bug database covering example 5 from GLUI, I believe. I don't remember what was described as not working, but it was open when I last saw it. > > Sad, yes. But I'm already there. > > > > I have a "spare" PC running MS-WINDOWS '98, and a brother in Florida had > > a spare MSVC++ license/box that he sent to me. (I wouldn't have installed > > MSVC++, save that my brother wants to work with me on a joint project, and > > he's stuck on WIN32, despite my best efforts. (^&.) > > mingw is a great alternative, and much more reliable (I compiled > freeglut with it on windows without pain). The only problem is that you I've got CygWIN set up on it. It's sluggish (vfork()/exec() seems likely to be part of the problem; running scripts is slow, though most of the rest is okay). I set that up primarily for ssh. Last I tried, I couldn't build freeglut on CygWIN. But, that's okay; I don't run CygWIN for development. I wish that it did NFS, but I gave up on that, and just installed samba on the UNIXish side. > must still support MSVC++ bugs. And there are also a plenty of stuffed > and colured IDEs for windows compatible with it (like devc++) - I'm more > used to Makefiles, but I tried several of them. When I had to use it, I > installed a whole load of mingw/free software, and felt 'almost' like > home ;) (^& I know the feeling. > > > code works fine for it's job, and doing big things with GLUT seems a > > > mistake by-design. I understand this is the goal of freeglut, so, if a > > > fork is under the way, I would rather be happy to contribute. > > > > It's not under way in the sense of having copied files and started with > > a formal name, etc. I'm thinking about it, but I also am concerned > > about fixing bugs in freeglut. However, it is hard to stay enthused [...] > > "Is it worth fixing?"(tm) (^& Yes. -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |