Oliver C. wrote: > Does dumping plib mean that we can choose something like the SDL > library for the OpenGL initialization?
No, that means dumping glut. Earlier plib versions had a glut dependency, but I believe that has been removed from current versions. We can keep the plib parts that we use and still move to SDL. I promised Curt long ago that I'd look into that issue. But then I went AWOL for a while. Basically, we need to change the glut callbacks in the existing fgfs code into an SDL event loop. That part is easy. The harder bit is the mouse cursor: glut hooks the window system to give you an easy choice of multiple cursor types with a simple glutSetCursor() API. SDL does nothing of the sort -- you need to come up with your own cursor bitmaps for the SDL API, or actually draw your own cursor icon using OpenGL. Most games take the second route, since you can do nifty color and blending tricks which the underlying window system APIs don't support (in a portable way; I think most OS's have color cursors now...). Moving to SDL has a bunch of advantages though. It's more portable than glut, and unlike glut is under active development. Glut has bugs that won't ever be fixed, like the linkage problem with Red Hat 9 and the NVidia drivers. > [regarding work on a multitexturing terrain implementation:] > > We could create a second branch in the CVS and merge them back > together when the new one is working. It's not about development methodology. It's about someone sitting down, dissecting the existing code, coming up with a prototype for a new implementation and then working their butt off to make it happen. Buzzing on mailing lists just leads to flame wars, not code. Code is all that matters. I'll say it again: this is a *hard* problem. And I'm someone who really likes hard problems. :) Andy _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
