Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
On Saturday, 30 July 2005 23:57, Paul Surgeon wrote: There is still a problem. If I roll back extensions.hxx and RenderTexture.cpp then I can compile SimGear. I'll try figure out what's causing it but I'm not very strong at C or C++ Paul GLXPbufferSGIX and GLXPbuffer are not defined anywhere in my nVidia GL headers although they are used throughout the GL headers! I've checked Mesa - same thing. The following lines in extensions.hxx cause a problem because GLXPbufferSGIX is not defined. #ifndef GLXPbuffer #define GLXPbuffer GLXPbufferSGIX #endif That is why I get a : ../../simgear/screen/extensions.hxx:441: error: ISO C++ forbids declaration of `GLXPbufferSGIX' with no type This is confusing. Are GLXPbuffer and GLXPbufferSGIX both supposed to be programmer defined? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] xml panels (2d)
Torsten Dreyer wrote: directory. How common is the KRA10? Well - you usually don't find it in the small trainers like 150's or 172's, but in the upperclass like the mooney or beech or lite twins, it can be seen. So I declare this one as common and I put the files under Aircraft/Instruments and Aircraft/Instruments/Textures. I solved the problem with the lowpass filter by using the interpolation/ tag which is very easy to use. I put a downloadable version of my radar altimeter here: http://www.t3r.de/fg/ and whould be happy if anybody likes to integrate it to their panels. Ok, you've convinced me. I've added the current version of the KRA-10 to CVS. If you got any useful update, please report it to the list or to Curtis or me. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Terrain LOD clumping
I had this message still in my TODO box and looking a bit closer it looks to me like MIPMAPPING should take care of this, doesn't it? Does anybody think this might be useful to include? Erik Phil Cazzola wrote: I've been playing around with having different terrain textures at different distances. I know some people have been looking at exploring this so I thought I should post what I have. It probably isn't ready to check in, but some brave people might like to experiment with it. I have some shapshots to illustrate. BTW, this terrain is generated from Mars MOLA data using a single land use (material) type. They are high visibity w/ the fog and fog diming turned off. Click on the pics for larger versions: http://members.interfold.com/pcazzola/terrain/ The top left shows the problem with having a single texture. At a distance, the texture looks very tiled. The top right picture uses a much simpler texture. Now the problem isn't tiling, but that it is so boring up close. The middle left picture, is the current behavior if you set more than 1 texture in the same material. You get some of the area w/ one and the rest w/ the other. The one on the middle right has 2 textures based on distance. The final picture shows that there are still some issues. The range selector didn't change the texture directly ahead. There is also some definite poping that occurs. What I've implemented is reverse compatible. The scene graph will come out exactly like before if you leave the materials.xml file as is. I've added the ability to set ranges in the material file. If you do that, the new code will add a range selector branch between the local terrain and the vtxTable leaf. It will make N copies of the leaf, but it is using references. This should make it so the vertex (etc.) data will not have to be copied and the memory growth should just be due to the extra range selectors and extra leafs, but not the leaf's data. Each of the leaves is tied to the correct ssgSimpleState for the texture. To specify the new ranges add 1 to N range properties to the material. You will need to specify 1 more texture than range values. material nameDefault/name range5000/range range1/range textureTerrain/texture1_close.rgb/texture textureTerrain/texture1_med.rgb/texture textureTerrain/texture1_far.rgb/texture xsize1000/xsize ysize1000/ysize /material In the code I assumed that the user would always want the first texture to start at zero and the last texture should go to the horizon. If you don't like this, you can easily alter the code to have no texture up close or out far. I chose not to add a call sgApplyTextureRanges() in apt_signs.cxx, but it is only couple of new lines if you want the same functionality for the signs. Diff file and source code attached. Let me know if there are any blatant errors. Phil Cazzola ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
Paul Surgeon wrote: GLXPbufferSGIX and GLXPbuffer are not defined anywhere in my nVidia GL headers although they are used throughout the GL headers! I've checked Mesa - same thing. The following lines in extensions.hxx cause a problem because GLXPbufferSGIX is not defined. #ifndef GLXPbuffer #define GLXPbuffer GLXPbufferSGIX #endif Ok, this is be fixed in CVS now. This is confusing. Are GLXPbuffer and GLXPbufferSGIX both supposed to be programmer defined? PBuffers once was *the*way to get accelerated support for texture rendering. It has been superseded by a number of other extensions of which the official RenderTexture extension is the preferred way now. Unfortunately our implementation doesn't have support for that one (yet). Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
On Sun July 31 2005 01:13, Paul Surgeon wrote: On Saturday, 30 July 2005 23:57, Paul Surgeon wrote: There is still a problem. If I roll back extensions.hxx and RenderTexture.cpp then I can compile SimGear. I'll try figure out what's causing it but I'm not very strong at C or C++ Paul GLXPbufferSGIX and GLXPbuffer are not defined anywhere in my nVidia GL headers although they are used throughout the GL headers! I've checked Mesa - same thing. The following lines in extensions.hxx cause a problem because GLXPbufferSGIX is not defined. #ifndef GLXPbuffer #define GLXPbuffer GLXPbufferSGIX #endif That is why I get a : ../../simgear/screen/extensions.hxx:441: error: ISO C++ forbids declaration of `GLXPbufferSGIX' with no type This is confusing. Are GLXPbuffer and GLXPbufferSGIX both supposed to be programmer defined? On my system, I find that both are defined in GL/glxproto.h I have a Debian testing system and I run Nvidia. I don't think this file is from Nvidia, however, but I don't know the exact package. Apparently belongs to some part of glx Richard Harke ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Fwd: Re: [Flightgear-devel] Airport LFPO Paris Orly Update]
Message transféré De: Gerard Robin [EMAIL PROTECTED] Objet: Re: [Flightgear-devel] Airport LFPO Paris Orly Update Date: Sun, 31 Jul 2005 11:35:28 +0200 Le samedi 30 juillet 2005 à 17:58 +, Martin Spott a écrit : Gerard Robin wrote: That Airport in the existing Scenery is wrong regarding the apt.dat What exactly is incorrect !? Orly is a well-known airfield which means the location is vermy much expected to be correct in the airport database. If the airport layout is incorrect, then the best bet is to correct this with TaxiDraw and send the result to David Luff. Just changing parts of the binary scenery doesn't help that much because it will be overridden with the next scenery update. Cheers, Martin. Thanks for the answer. The scenery and the apt.dat content are not the same. If you try to take off on LFPO your aircraft is in the field outside of the runway. You cannot solve it with taxidraw, which do not operate on the runways. I did solve it, by rebuilding the tile including LFPO with Terragear. If you are interested on it that new version is available here You only have to replace the old files by these new ones. http://ghours.club.fr/LFPO-update.tar.gz -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
On Sunday, 31 July 2005 10:50, Erik Hofman wrote: Ok, this is be fixed in CVS now. Well almost fixed :-) Using a clean SG checkout (extensions.hxx version 1.24) : In file included from ../../simgear/scene/sky/bbcache.hxx:29, from ../../simgear/scene/sky/newcloud.hxx:31, from visual_enviro.cxx:35: ../../simgear/screen/extensions.hxx:449: error: `GLXPbufferSGIX' has not been declared ../../simgear/screen/extensions.hxx:449: error: ISO C++ forbids declaration of `parameter' with no type Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Fwd: Re: [Flightgear-devel] Airport LFPO Paris Orly Update]
Le dimanche 31 juillet 2005 à 11:36 +0200, Gerard Robin a écrit : Just changing parts of the binary scenery doesn't help that much because it will be overridden with the next scenery update. Cheers, Martin. Thanks for the answer. The scenery and the apt.dat content are not the same. If you try to take off on LFPO your aircraft is in the field outside of the runway. You cannot solve it with taxidraw, which do not operate on the runways. I did solve it, by rebuilding the tile including LFPO with Terragear. If you are interested on it that new version is available here You only have to replace the old files by these new ones. http://ghours.club.fr/LFPO-update.tar.gz In addition to: Yes... rebuilding the scenery solve it, because it has been done with the last apt.dat. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Terrain LOD clumping
Le dimanche 31 juillet 2005 à 10:39 +0200, Erik Hofman a écrit : I had this message still in my TODO box and looking a bit closer it looks to me like MIPMAPPING should take care of this, doesn't it? Does anybody think this might be useful to include? Erik I have some shapshots to illustrate. BTW, this terrain is generated from Mars MOLA data using a single land use (material) type. They are high visibity w/ the fog and fog diming turned off. Click on the pics for larger versions: http://members.interfold.com/pcazzola/terrain/ The top left shows the problem with having a single texture. At a distance, the texture looks very tiled. The top right picture uses a much simpler texture. Now the problem isn't tiling, but that it is so boring up close. The middle left picture, is the current behavior if you set more than 1 texture in the same material. You get some of the area w/ one and the rest w/ the other. The one on the middle right has 2 textures based on distance. The final picture shows that there are still some issues. The range selector didn't change the texture directly ahead. There is also some definite poping that occurs. To specify the new ranges add 1 to N range properties to the material. You will need to specify 1 more texture than range values. material nameDefault/name range5000/range range1/range textureTerrain/texture1_close.rgb/texture textureTerrain/texture1_med.rgb/texture textureTerrain/texture1_far.rgb/texture xsize1000/xsize ysize1000/ysize /material In the code I assumed that the user would always want the first texture to start at zero and the last texture should go to the horizon. If you don't like this, you can easily alter the code to have no texture up close or out far. I chose not to add a call sgApplyTextureRanges() in apt_signs.cxx, but it is only couple of new lines if you want the same functionality for the signs. Diff file and source code attached. Let me know if there are any blatant errors. Phil Cazzola That would be useful, if with it, we could reduce the cpu usage. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
On Sunday, 31 July 2005 11:19, Richard Harke wrote: On my system, I find that both are defined in GL/glxproto.h I have a Debian testing system and I run Nvidia. I don't think this file is from Nvidia, however, but I don't know the exact package. Apparently belongs to some part of glx Richard Harke If you scroll down to about line 1700 you'll find : #undef GLXPbuffer #undef GLXPbufferSGIX They are just temporarily defined as something and then undefined again. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
Problem fixed! SimGear WILL NOT compile with nVidia 6629 headers (like it used to). I updated to 7667 OpenGL headers and it compiles now. What I should do is do a diff between the 6629 and 7667 headers to find the problem but I'm too tired and lazy and am happy that things now work. ;) Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
Le dimanche 31 juillet 2005 à 12:12 +0200, Paul Surgeon a écrit : Problem fixed! SimGear WILL NOT compile with nVidia 6629 headers (like it used to). I updated to 7667 OpenGL headers and it compiles now. What I should do is do a diff between the 6629 and 7667 headers to find the problem but I'm too tired and lazy and am happy that things now work. ;) Paul Don't mind 7669 is better than 6629. It can be installed on the Linux kernel. 2.6.12.2 We only get difficulties with Ac3D 5.021 which randomly don't work. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Fwd: Re: [Flightgear-devel] Airport LFPO Paris Orly Update]
Gerard Robin wrote: The scenery and the apt.dat content are not the same. If you try to take off on LFPO your aircraft is in the field outside of the runway. You cannot solve it with taxidraw, which do not operate on the runways. I did solve it, by rebuilding the tile including LFPO with Terragear. Well, TaxiDraw actually _does_ operate on runways, you just have to unlock the runway by using Edit - Unlock Runways. But if I understand correctly In addition to: Yes... rebuilding the scenery solve it, because it has been done with the last apt.dat. it is not the airport database entry that you want to change. If the airport database entry actually differs from the Scenery you use then I suspect that someone checked an update to LFPO into the database in CVS _after_ Curt distributed the current Scenery set. You probably use the base package from CVS with the 0.9.8 Scenery. If you are interested on it that new version is available here Oh, my current trouble with FlightGear on my worklplace at home is much larger than just a small offset of one airport in the Scenery ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
Paul Surgeon wrote: Problem fixed! SimGear WILL NOT compile with nVidia 6629 headers (like it used to). I updated to 7667 OpenGL headers and it compiles now. What I should do is do a diff between the 6629 and 7667 headers to find the problem but I'm too tired and lazy and am happy that things now work. ;) That's great, thanks for the warning. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] feature request: MultiPlayer's
Andy Ross wrote: Paul Surgeon wrote: TeamSpeak doesn't have to be part of the FG package. It's a separate program that has an API you can interface to. Writing code that runs in the fgfs binary to interface to an API is generally considered to be making a derivative work, for fairly obvious reasons. I see additional trouble showing up at the horizon. When using an external program that the FG community has no control over we soon will get into the state where we face to interoperate with station A you have to use version B of TeamSpeak. If you still use FG version x.y.z then use version M of TeamSpeak. To interface station A _and_ B with FG version [...] then you need version C of TeamSpeak and . I once watched someone setting up MSFS for a multiuser environment and it took him, although he wasn't a newbie, about half an hour to connect the appropriate versions together. I strongly suggest that multiplayer components should be part of FG itself. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] feature request: MultiPlayer's Callsigns
Jon Stockill wrote: http://www.voip-info.org covers practically everything out there. Just an idea: In order to stick to 'standard' interfaces it might make sense to integrate a simple SIP or IAX (Inter Asterisk Exchange) client into FG with just enough features to connect to an Asterisk VoIP server, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Patch for fgjs.cxx and jsinput.[h,cxx]
Hi Ralf, This has been committed to CVS now. Thanks. Erik Ralf Gerlich wrote: Hello, find attached a patch for fgjs.cxx and jsinput.[h,cxx] (current CVS). The changes are: - automatic detection of axis directionality, so that axis inputs are appropriately inverted only when necessary - fixed trim axis names for better understandability - fixed signs for flaps up/down property increments - button 0 was previously used for skipping axes and buttons in both loops. Now button 0 can be assigned a binding (e.g., brakes). Instead, moving any axis during the button-assignment-loop indicates skipping. - The user is now told how to skip a control. I have tested it with a Logitech WingMan Force 3D, but I don't see any reason why it should not work for other sticks ;-) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Feature request: will sound options be saved?
Roberto Inzerillo wrote: Hi, current situation is: FGFS v.0.9.8 win32; shutting down FGFS the sound configuration (volume and mute) is not saved as other configurable options. At this time no option is saved from FlightGear itself. If you are using fgrun then the options specified in fgrun will be saved indeed. Will this be possible in future releases? This is not an easy change (for FlightGear) but you could specify it yourself by adding the following: --prop:/sim/sound/volume=0.8 Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] feature request: MultiPlayer's Callsigns
On Sunday 31 July 2005 14:34, Martin Spott wrote: Jon Stockill wrote: http://www.voip-info.org covers practically everything out there. Just an idea: In order to stick to 'standard' interfaces it might make sense to integrate a simple SIP or IAX (Inter Asterisk Exchange) client into FG with just enough features to connect to an Asterisk VoIP server, Martin. I noticed a while back that openh323.org had a tool called openmcu. openmcu is basically a conference server for h323/sip etc clients and it also supports 'rooms' which could be viewed as 'frequencies'. Most h323 clients support 'rooms' and switching with the notable exception of Netmeeting on Windows. IIRC openmcu can handle packets produced by speex etc. Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] feature request: MultiPlayer's Callsigns
Martin Spott wrote: Just an idea: In order to stick to 'standard' interfaces it might make sense to integrate a simple SIP or IAX (Inter Asterisk Exchange) client into FG [...] I someone is willing to investigate the feasibility of incorporating the IAXClient (http://iaxclient.sourceforge.net/) library into FG then I'd see how to set up an Asterisk server that fills the missing gap. From my past experience with Asterisk I'm confident that Asterisk does the job. From the IAXClient README: The library is designed to build for multiple platforms, and currently supports Linux, MacOSX, Solaris, and Win32 platforms. It is designed to handle the backend of IAX telephony operations, including call handling, network protocols, audio encoding/decoding, and audio capture/playback. [...] The iaxclient library itself, is provided under the terms of the LGPL Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] feature request: MultiPlayer's Callsigns
Dave Martin wrote: openmcu is basically a conference server for h323/sip etc clients and it also supports 'rooms' which could be viewed as 'frequencies'. This is almost how I'd implement the desired functionality with Asterisk (as we already have frequencies recorded as simple 6-digit numbers in the airport database) - with the slight difference that Asterisk enables me to use a modern and easily NAT-able protocol as well as a well-maintained implementation of it :-) Besides that we gain the opportunity to plug almost every audio feature into Asterisk that might evolve over the time. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Preferences.xml question
Hello group, I have modified the preferences file to start FGFS with the options I want, and everything is working great. One quick question though. I need to start the sim with the parking brake on, how would that line of code look in the preferences file? Also, I want to replace the splash screens, what are the formats? I see that the files are .rgb fileswhat are those? Neither photoshop or paint will open them? Thanks for all of the helpthis group is great. Craig___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Preferences.xml question
Craig Martin wrote: I want to replace the splash screens, what are the formats? Why would you want to do that? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Preferences.xml question
To put in pictures that I likeyou know, the whole customization thing. Is replacing the splash screens a problem in some way?Erik Hofman [EMAIL PROTECTED] wrote: Craig Martin wrote: I want to replace the splash screens, what are the formats? Why would you want to do that?Erik___Flightgear-devel mailing listFlightgear-devel@flightgear.orghttp://mail.flightgear.org/mailman/listinfo/flightgear-devel2f585eeea02e2c79d7b1d8c4963bae2d___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Preferences.xml question
Le dimanche 31 juillet 2005 à 11:30 -0700, Craig Martin a écrit : Hello group, I have modified the preferences file to start FGFS with the options I want, and everything is working great. One quick question though. I need to start the sim with the parking brake on, how would that line of code look in the preferences file? Also, I want to replace the splash screens, what are the formats? I see that the files are .rgb fileswhat are those? Neither photoshop or paint will open them? Thanks for all of the helpthis group is great. Craig I know how to customise a splash screen for a specific Aircraft You have to add in the file youraircraft-set.xml the following: startup splash-textureAircraft/harrier/harrier-splash.rgb/splash-texture /startup My exemple is harrier-set.xml and the splash name is harrier-splash.rgb Format is rgb 256x256 -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
On Sat, 30 Jul 2005 16:40:58 +0200, Oliver wrote in message [EMAIL PROTECTED]: On Saturday 30 July 2005 16:25, Dave Martin wrote: I don't know if anyone has brought this up yet but the 1.0-7667 driver from NVIDIA for linux breaks the drawn shadows as in they don't appear at all. This tested and confirmed on a FX5800U and 6600GT PCIE Dave Martin No, it works here. You just need to start flightgear in 24 bit mode. fgfs --bpp=24 ..does --bpp=32 work any better than 24bpp for you? (Assuming X run at 32 on Nvidia cards) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear mentioned at Clarin, the most printed newspaper in Spanish language
Hi everybody, I'm very pleased to let you know that FlightGear was mentioned (although consider as a game) in the Computers section of Clarin, the most important newspaper in Argentina, and the newspaper in Spanish language with the most printed copies every day. This is the link (although in Spanish...) http://www.clarin.com/suplementos/informatica/2005/07/27/f-00611.htm The printed version has also a screen capture of FlightGear. May be some of you is dissapointed that FG was mentioned along some other free games, but for me is really very important that the link to FG had appeared in such a publication in my country. May be in the future the author can be contacted to by us to write a dedicated article specially about FG Congratulations to all the ones who work in the project Pablo J. Rogina ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
