OK, I've just commited the hard part of deglutification. All glut dependencies in the source tree are now isolated in "Main/fg_os.cxx". This file (header attached) defines a really tiny wrapper API around the subset of glut we actually use. Think of it as yet another OS abstraction API, but one that we can control and mutate as our needs change.
Note that the current version is still using glut, so nothing should have changed in FlightGear's behavior. If it did, then I broke something. The changeset is big. Feel free to revert it if it doesn't work out of the box. The next step is to decide what toolkit(s) to support for future versions and write a fg_os implementation for them. Now, I suppose, is the time to have the flame war about toolkit choices. To seed the debate: SDL: Big and complicated. This is the current "gold standard" for portable game APIs, and tends to support new paltform features very quickly and completely. It has a lower-level "event loop" API which might be a little more flexible. It also includes a lot of auxilliary libraries (input devices, sound mixing) that we might want to make use of in lieu of the plib equivalents. It's standard on all (?) linux distributions, and can be shipped as a single DLL for Win32 binary distribution. I'm not sure how easy it is to get for Cygwin or Mac users. PW: Plib's new integrated toolkit. This is sort of a "glut light" (OpenGL window creation; no menus, no fonts, no joysticks, no spaceballs, no tablets, no game mode), and looks quite clean to me. It has the distinct advantage of adding no new dependencies, because it is shipped with Plib. It is also brand new, and probably still a little rough around the edges. Roll our own: Probably no one will be interested in this option, but I thought I'd throw it out there just in case. FlightGear is a big enough project now that maintaining our own OS integration layer wouldn't be a terribly large part of the development effort. This would get us maximum flexibility for nifty hacks. Think about platform-specific features like automatically popping the window to the foreground when the autopilot reaches the destination, "headless" operation, FlightGear on the desktop background, panel applet integration... While we could steal code from other sources to get started, this would obviously be lots more work. Andy _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
