Re: [Flightgear-devel] SDL early access implementation
Norman Vine wrote: FWIW I would be much more excited about this if we were switching to a library designed for highend simulations such as OpenProducer which by the way also has a portable threading library OpenThreads this aims at OpenSceneGraph - doesn't it ? ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SDL early access implementation
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Martin Spott Sent: Wednesday, April 14, 2004 8:11 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] SDL early access implementation Norman Vine wrote: FWIW I would be much more excited about this if we were switching to a library designed for highend simulations such as OpenProducer which by the way also has a portable threading library OpenThreads this aims at OpenSceneGraph - doesn't it ? ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SDL early access implementation
Martin Spott writes: Norman Vine wrote: FWIW I would be much more excited about this if we were switching to a library designed for highend simulations such as OpenProducer which by the way also has a portable threading library OpenThreads this aims at OpenSceneGraph - doesn't it ? ;-) OpenProducer was written to support OpenSceneGraph but, it doesn't need OpenSceneGraph and more importantly it was designed to be used in 'multi-pipe' OpenGL systems as well as more conventional OpenGL configurations from the ground up. OpenProducer also takes a minimalist approach which I find attractive compared to 'full featured' libraries. One can think of it has a Direct Layer for OpenGL only and it doesn't concern itself with anything else. One thing I would like todo is use DirectX rather then the normal WIN32 API for the event loop but what is there works well enough and was a lot less work when porting from the original 'X' based code. FYI I have been doing some work on a global LOD based scenery engine that happens to currently be based on OpenSceneGraph Lot of work todo yet and I want to move this into SSG, but, I finally have the basics working http://cooa.whoi.edu/~nhv/images/test1.jpg note the texture used in the above is elevation but orthophotos or satelite imagery works as well Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Norman Vine wrote: OpenProducer was written to support OpenSceneGraph but, it doesn't need OpenSceneGraph and more importantly it was designed to be used in 'multi-pipe' OpenGL systems as well as more conventional OpenGL configurations from the ground up. STLport, OpenThreads, OpenProducer, OpenSceneGraph, OpenAL they all convey the idea of a foresighted design concept and look like they they would be the first choice for FlightGear !? Is Norman the only advocate for this approach ? Just investigating, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
On Wed, 14 Apr 2004 09:11:08 -0400, Norman wrote in message [EMAIL PROTECTED]: One thing I would like todo is use DirectX ..this too is Microsoft's IP, no? rather then the normal WIN32 API for the event loop but what is there works well enough and was a lot less work when porting from the original 'X' based code. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Bernie Bright wrote: Just updated cvs. Your fix looks for GL/glut.h when --enable-sdl is specified. I thought it was supposed to be either or. Not at this time, there are too many side projects/utilities that depend on glut (for example the tests subdirectory which gets build by default). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Bernie Bright wrote: On Tue, 06 Apr 2004 13:52:28 -0700 Andy Ross wrote: Sure. This should work right now. The only bits missing are the autotools magic to do the detection and set up the makefiles appropriately. I fear autoconf, I really do... Does someone with a more solid handle on these things want to help out? :) For starters we could change the glut test in configure.ac to something like: Bernie, I added another patch to CVS to do this because it caused a number of problems for systems without SDL installed. This approach doesn't rely on SDL provided autoconf macros. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
On Wed, 07 Apr 2004 17:20:47 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Bernie Bright wrote: On Tue, 06 Apr 2004 13:52:28 -0700 Andy Ross wrote: Sure. This should work right now. The only bits missing are the autotools magic to do the detection and set up the makefiles appropriately. I fear autoconf, I really do... Does someone with a more solid handle on these things want to help out? :) For starters we could change the glut test in configure.ac to something like: Bernie, I added another patch to CVS to do this because it caused a number of problems for systems without SDL installed. This approach doesn't rely on SDL provided autoconf macros. We could add sdl.m4 to FlightGear. A lot of projects have an m4 directory to collect such things. We would then pass that directory to aclocal... aclocal -I./m4. Just updated cvs. Your fix looks for GL/glut.h when --enable-sdl is specified. I thought it was supposed to be either or. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SDL early access implementation
Andy Ross writes: Is SDL something we want to commit to? FWIW - I don't see what this gets us but . since we are now agnostic as pertains to the lowlevel OpenGL initialization routines I don't see why the choice of OpenGL toolkit used couldn't just be an option i.e. since all of the pertinent routines are supposedly hidden in the 'misnamed' fg_os.cxx file the underlying toolkit could be a compile time option. this module has *nothing* to do with the OS involved i.e there is no #include windows.h :-) IMHO It would be a mistake to get rid of one dependency by just replacing with another Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Norman Vine wrote: since we are now agnostic as pertains to the lowlevel OpenGL initialization routines I don't see why the choice of OpenGL toolkit used couldn't just be an option Uh, that's the whole point. What would you prefer, if not SDL? If you want to write a windows-only implementation, feel free. The problems with glut are well-documented. It is no longer developed, doesn't track changes in the underlying systems (mode switching has never worked under XFree86, for example), is not free software, is being dropped by most linux distributions, and is filled with cruft that we don't use. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SDL early access implementation
Andy Ross writes: Norman Vine wrote: since we are now agnostic as pertains to the lowlevel OpenGL initialization routines I don't see why the choice of OpenGL toolkit used couldn't just be an option Uh, that's the whole point. What would you prefer, if not SDL? If you want to write a windows-only implementation, feel free. The problems with glut are well-documented. It is no longer developed, doesn't track changes in the underlying systems (mode switching has never worked under XFree86, for example), is not free software, is being dropped by most linux distributions, and is filled with cruft that we don't use. Out of curiosity what can't you do today that would make FlightGear better because we are using GLUT that you would do differently today if we were using SDL and what exactly is it that would make FGFS better. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Norman Vine wrote: Out of curiosity what can't you do today that would make FlightGear better because we are using GLUT that you would do differently today if we were using SDL and what exactly is it that would make FGFS better. One big issue is that out of the box, glut is either broken, or non-existant now on many linux distributions. It just became broke for debian users that run nvidia drivers. (Along with all the other issues Andy mentioned.) This isn't so much an issue of functionality right now, but more of an issue of supporting what people are already likely to have installed on their machines (or can easily get installed on their machines.) As is well documented, the glut licensing makes it almost impossible to fix it's known issues, free glut has show stopping limitations or doesn't support all platforms we want to support. Perhaps we could say that what is better is that FlightGear might build more easily, or more cleanly, or with fewer issues on more people's boxes if we go with SDL (or at least allow a choice which is the current direction we are heading.) I understand that there are (or at least were) issues between SDL and cygwin, but perhaps it would be more productive to address that problem directly ... Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Norman wrote: Out of curiosity what can't you do today that would make FlightGear better because we are using GLUT that you would do differently today if we were using SDL and what exactly is it that would make FGFS better. Off the top of my head: + Build out of the box on Fedora, which no longer ships glut. Other linux distributions are likely to drop it in the future as well, I suspect. It has portability issues when built against current versions of the X libraries and has a license which disallows redistribution of modified versions. + Switch video modes on an XFree86/Xorg server, which has supported this capability for 4+ years but have never had a complete game mode glut port written. + Be able to handle stuff like Shift-3 instead of #, so the Europeans don't think our key mappings are on drugs. + Future features we might like to investigate: SDL has a portable threading API, so we could enable threads by default. SDL has an audio library which is more featureful and portable than SL (it speaks to APIs like ALSA, arts, ESD, and DirectSound; SL doesn't even work on my laptop) Seriously, glut has not been maintained for almost 6 (!) years. Almost no one else uses it. It was a nice demo library in its time, but it has long since faded. Everybody doing portable open source OpenGL development is using SDL. I don't like everything about the library, but I can feel where the wind is blowing. And I'm serious: if you want to write a Win32 implementation of the stuff in fg_os.hxx, feel free. The whole point of having an abstraction API under our own control is that it allows us to do things our way. I'm not wedded to SDL, by any means. Honestly, I thought you of all people would enjoy this change. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Norman Vine wrote: Out of curiosity what can't you do today that would make FlightGear better because we are using GLUT that you would do differently today if we were using SDL and what exactly is it that would make FGFS better. Under Linux, resolution switching (i.e. go fullscreen at 1024x768 when your desktop is 1600x1200, and so on). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Curtis L. Olson wrote: I understand that there are (or at least were) issues between SDL and cygwin, but perhaps it would be more productive to address that problem directly ... Ah. I honestly didn't know this. I just assumed that cygwin was one of their native platforms. I just checked, and it's true that cygwin doesn't ship an SDL library as part of the distribution. I did find the following README on the SDL website which seems to imply that the process is pretty straightforward: http://www.libsdl.org/extras/win32/cygwin/README.txt It basically sounds like configure make make install is all that is needed, with a few caveats about making sure to install extras packages containing OpenGL and DirectX headers. But remember: I think a native Win32 implementation would be pretty cool, too. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Andy Ross wrote: Ah. I honestly didn't know this. I just assumed that cygwin was one of their native platforms. I just checked, and it's true that cygwin doesn't ship an SDL library as part of the distribution. I did find the following README on the SDL website which seems to imply that the process is pretty straightforward: http://www.libsdl.org/extras/win32/cygwin/README.txt It basically sounds like configure make make install is all that is needed, with a few caveats about making sure to install extras packages containing OpenGL and DirectX headers. But remember: I think a native Win32 implementation would be pretty cool, too. :) Norman, please jump in if I get any of the details wrong here. Andy, as I understand it, the SDL Readme is slightly optimistic. The configure/make/make install process either breaks, or doesn't produce a usable result under Cygwin. The SDL people argue that it works for MSVC and MingWin so apparently no one is motivated to figure out why things don't work for Cygwin. That's my recollection of what Norman reported to me some months ago. Obviously the solution is to fix SDL under Cygwin, but I don't know who would do that. Probably the best short term solution is to make sure we can build with both SDL and glut and let the builder decide? If we can get SDL working well for all but cygwin people, it might make sense to make SDL be the default rather than glut, or default to SDL if it is detected and fall back to glut if there is no SDL? Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
On Tuesday 06 April 2004 20:16, Norman Vine wrote: Out of curiosity what can't you do today that would make FlightGear better because we are using GLUT that you would do differently today if we were using SDL and what exactly is it that would make FGFS better. Using SDL has many positive effects. 1. It is widely accepted, easy to use and even commerical companys do use it for their commercial games. This means also that there is a large user base that can jump in and improve flightgear. 2. (my favourite one) A very nice input and event handling system. It uses a virtual keysym to each key on the keyboard which map to some level to the operating systems's keyboard scancodes. So it is very easy to nicely support non US keyboard layouts plattform independet. You can also use the same input infrastructure to support joystick, mouse and other input devices the same easy way. 3. It can be easily used together with OpenAL as our default sound API and SDL sound as a backup system in the case OpenAL is not supported on other plattforms. IMHO OpenAL is a must, because it is crossplattform capable and allowes us to easily implement 3d sound in flightgear, doppler shift effects, attenuation and hardware sound accerlation (if the soundcard supports it). It is also very easy to use because it is rather similar to the way OpenGL works and is used. 4. SDL has its own portable threading API which is plattform independent. That feature could be very usefull. And much more. I think GLUT is dead, we should realize that and SDL seems to be the best solution today to replace GLUT. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Curtis L. Olson wrote: Probably the best short term solution is to make sure we can build with both SDL and glut and let the builder decide? Sure. This should work right now. The only bits missing are the autotools magic to do the detection and set up the makefiles appropriately. I fear autoconf, I really do... Does someone with a more solid handle on these things want to help out? :) If we can get SDL working well for all but cygwin people, it might make sense to make SDL be the default rather than glut, or default to SDL if it is detected and fall back to glut if there is no SDL? Another option might be for someone to fight through the SDL installation just once and provide a binary package for cygwin folks to install. Dumb question for windows folks: would it not work to simply use the mingw library? My understanding is that windows SDL is built entirely on the Win32 API, and won't conflict with cygwin.dll or the C library. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Andy Ross wrote: Sure. This should work right now. The only bits missing are the autotools magic to do the detection and set up the makefiles appropriately. I fear autoconf, I really do... Does someone with a more solid handle on these things want to help out? :) Be a man and dive in. I still don't understand automake either, but after a lot of trial and error, I managed to make a few configuration changes work. After all, we all managed to learn Perl, didn't we? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SDL early access implementation
Curtis L. Olson writes: I understand that there are (or at least were) issues between SDL and cygwin, but perhaps it would be more productive to address that problem directly ... I haven't heard of any one not being able to compile CVS FGFS because of GLUT but this is not the point I am trying to make which is since we are now agnostic as pertains to the lowlevel OpenGL initialization routines I don't see why the choice of OpenGL toolkit used couldn't just be an option This is easy todo as long as we only use those routines that are GFX agnostic i.e those defined in fg_os.hxx and pure OpenGL This way it is up to the user compiling the code which underlaying library is used Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SDL early access implementation
Andy Ross writes: Norman wrote: Out of curiosity what can't you do today that would make FlightGear better because we are using GLUT that you would do differently today if we were using SDL and what exactly is it that would make FGFS better. Off the top of my head: + Build out of the box on Fedora, which no longer ships glut. I wonder who sparked that :-) + Switch video modes on an XFree86/Xorg server, which has supported this capability for 4+ years but have never had a complete game mode glut port written. + Be able to handle stuff like Shift-3 instead of #, so the Europeans don't think our key mappings are on drugs. why not use freeglut ? FWIW I would be much more excited about this if we were switching to a library designed for highend simulations such as OpenProducer which by the way also has a portable threading library OpenThreads Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SDL early access implementation
Andy Ross writes: Curtis L. Olson wrote: I understand that there are (or at least were) issues between SDL and cygwin, but perhaps it would be more productive to address that problem directly ... Ah. I honestly didn't know this. short memory :-) http://baron.flightgear.org/pipermail/flightgear-devel/2003-April/017006.html But remember: I think a native Win32 implementation would be pretty cool, too. :) If we only use pure OpenGL calls outside of the fg_os functions liike I suggest this would still be possible Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Norman Vine wrote: FWIW I would be much more excited about this if we were switching to a library designed for highend simulations such as OpenProducer which by the way also has a portable threading library OpenThreads The argument is still open. Sell us on OpenProducer. I've never heard of it, but would be willing to investigate. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
On Tue, 06 Apr 2004 13:52:28 -0700 Andy Ross [EMAIL PROTECTED] wrote: Curtis L. Olson wrote: Probably the best short term solution is to make sure we can build with both SDL and glut and let the builder decide? Sure. This should work right now. The only bits missing are the autotools magic to do the detection and set up the makefiles appropriately. I fear autoconf, I really do... Does someone with a more solid handle on these things want to help out? :) For starters we could change the glut test in configure.ac to something like: --- dnl Check for SDL if enabled. AC_ARG_ENABLE(sdl, [ --enable-sdlConfigure to use SDL instead of GLUT], enable_sdl=yes, enable_sdl=) if test x$enable_sdl = xyes ; then sdl_version=1.2.0 AM_PATH_SDL($sdl_version, use_sdl=yes, use_sdl=) CPPFLAGS=$CPPFLAGS $SDL_CFLAGS LIBS=$LIBS $SDL_LIBS else dnl check for glut location AC_CHECK_HEADER(GL/glut.h) if test x$ac_cv_header_GL_glut_h = xyes; then AC_DEFINE([FG_GLUT_H], GL/glut.h, [Define as glut.h include location]) else AC_CHECK_HEADER(GLUT/glut.h) if test x$ac_cv_header_GLUT_glut_h = xyes; then AC_DEFINE([FG_GLUT_H], GLUT/glut.h, [Define as glut.h include location])else echo Neither GL/glut.h nor GLUT/glut.h found. Cannot continue exit fi fi fi --- Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
I wrote: The one thing that is missing is support for changing the mouse cursor image. Melchior pointed me at a font editor (http://fontforge.sf.net) that can read .pcf files, so I've thrown together a set of bitmaps based on the X11 cursor font and checked them in. This basically makes the SDL port complete, even if the cursors aren't as pretty as I was initially intending (they aren't any uglier than they are now, though). I'd appreciate it if folks, especially those on non-linux platforms, would give it a whirl and see what they think. Is SDL something we want to commit to? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
