Re: [Flightgear-devel] Rsync vulnerability
On Sat, Dec 06, 2003 at 06:18:01PM +, Martin Spott wrote: Curtis L. Olson [EMAIL PROTECTED] wrote: I'm running ext3 so normally rebooting, even after a crash would not be a problem, but in this case I exceeded the last check date threshold so it ran a full fsck on me. [...] bitchy Here you realize the difference between a wannabee enterprise filesystem and an enterprise filesystem that was designed as such from the very beginning /bitchy Actually, ext3 is a better choice than XFS if you really care about your data - it does full data journalling (at a performance cost), unlike XFS which only journals metadata. Since it halves your write performance people generally don't use it, but it's there in ext3 . . . In any case, filesystems that /aren't/ paranoid about your data aren't things to be trusted . . Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ pgp0.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rsync vulnerability
On Sun, Dec 07, 2003 at 06:35:57PM -0600, Curtis L. Olson wrote: Simon Fowler writes: Actually, ext3 is a better choice than XFS if you really care about your data - it does full data journalling (at a performance cost), unlike XFS which only journals metadata. Since it halves your write performance people generally don't use it, but it's there in ext3 . . . In any case, filesystems that /aren't/ paranoid about your data aren't things to be trusted . . There are a zillion trade offs between the different journaling file systems. I heard a talk at one of the LinuxWorld's that compared the various ones ... reiser, xfs, ext3, something from ibm I think, and there was one more if I recall. They all have strengths and weaknesses and perform better or worse under different circumstances. They also have different feature sets. I haven't seen any comparison of any of the Linux journaling file systems vs. the MS windows journeling file system(s?) though. Yeah, there are always trade offs and balances and so forth. Personally, I like filesystem people who are paranoid with my data ;-) Really, though, I'd be quite happy using any of the major Linux filesystems (I'm planning to build an XFS based samba server as soon as the hardware arrives). Each for their own strengths ;-) Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ pgp0.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] a FIXME in fg_props.cxx
On Wed, Nov 12, 2003 at 09:54:34PM -0800, Gene Buckle wrote:
On Wed, 12 Nov 2003, Cameron Moore wrote:
* [EMAIL PROTECTED] (Gene Buckle) [2003.11.12 10:35]:
code:
static const char *
getDateString ()
{
static char buf[64]; // FIXME
struct tm * t = globals-get_time_params()-getGmt();
sprintf(buf, %.4d-%.2d-%.2dT%.2d:%.2d:%.2d,
t-tm_year + 1900, t-tm_mon + 1, t-tm_mday,
t-tm_hour, t-tm_min, t-tm_sec);
return buf;
}
Why the FIXME in the declaration of buf? Is there a better way of doing
that? Is there a buffer overrun concern or something?
We should at least be using snprintf() here.
So what makes snprintf() a better choice than sprintf()?
snprintf(buf, buflen, format, ...) will not write more than buflen
characters (including the trailing '\0') - this protects you against
a possible buffer overflow . . .
It probably isn't necessary in this case, but it's a Good Habit To
Get Into(tm).
Simon
--
PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc
(crappy) Homepage: http://himi.org
doe #237 (see http://www.lemuria.org/DeCSS)
My DeCSS mirror: ftp://himi.org/pub/mirrors/css/
pgp0.pgp
Description: PGP signature
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Bug in the joystick properties code.
Since there's talk of a new release . . . I discovered (about a month ago - I was going to test more and give a full report, but my fiance has taken over the computer that's capable of running fgfs ;-) a bug in the handling of empty nodes in the properties tree (I think). While editing my joystick file I accidentally left an entry that was basically button . . . binding /binding /button When I actually hit that button on the joystick, FlightGear segfaulted, with the error being an attempt to access a NULL pointer in the properties tree (again, I think - I haven't been able to test this for a while, so I may be misremembering). A very simple test for this is to add a null binding to a button on a joystick and then hit the button . . . Hopefully this can be fixed before the release, if it's still a problem. Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ pgp0.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-users] Segmentation fault ?
On Tue, Dec 10, 2002 at 07:56:19AM -0500, Norman Vine wrote: Adam wrote: Is there an easy way to fix this then? I didn't turn on the clouds3d stuff at all - so it in my download it must be on by default - I will try with it turned off. Sorry for being a bit of a newb here, but can you offer more advice about how to implement Norman's new code? What I posted is a diff file % info diff % info patch Just one thing to note: you're /much/ better off posting a unified diff (what you get from diff -u) - it's a more robust format, and a /lot/ more readable for a normal human being. patch will be more likely to work if you feed it a unified diff. Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg10310/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] Blender Status
On Wed, Nov 13, 2002 at 01:01:39PM -0500, David Megginson wrote: Curtis L. Olson writes: One additional thing that would be very nice to support is the ability to have at least one additional directory level for grouping aircraft: Aircraft - Small-Single-Engine - WWII - WWI - Modern-Jet-Fighters - Commercial-Jets - Bi-Planes - Sea-Planes - R/C Planes - etc. And then have the individual aircraft directory inside of the group directory. Otherwise it's going to be a big mess (like it is now) when you start having more than 10-20 aircraft. This also makes finding a particular aircraft more convenient becuase you don't have to traverse obscenly large lists. I don't know. Most users won't install more than 20 or 30 aircraft (if my MSFS experience is anything to go by), and there are many different ways to classify aircraft. I prefer an info.xml file in each directory with all the classifications, so that we can eventually list all Cessna aircraft, all single-engine aircraft, all piston-engine aircraft, all aircraft with a gross weight under 12,500lb, and so on. Possibly if we divided the aircraft up by the class of license that would be needed to fly them? Given we're trying for a high degree of realism, that could easily be the most useful approach, and certainly it'd be one that people might want as an option . . . Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg09743/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] Panel font crash
On Fri, Oct 18, 2002 at 04:05:52PM -0400, David Megginson wrote: Andy Ross writes: The attached one-liner fixes the problem, but someone with more knowlege should probably think of a better solution. We shouldn't be initializing static state from within a member initializer. Maybe there's a need for a panel subsystem as separate from the individual FGPanel objects? It's a hard call. The J3Cub shows that it's possible to have a true 3D panel, using 3D models rather than a projected 2D panel. We'll still need the 2D panel for some applications, but I'd like to start deemphasizing it when we can. The 3D panel is almost unusable for me (with a K7 550 and an original Radeon) - the performance hit is just too great, and it still occasionally overloads my system and locks up (a driver problem, admittedly, but combined with the performance hit it's a serious problem). It'd be very nice if all the aircraft had a 2d panel that could be switched to without having to fiddle with properties, even if the panel was just the c172/310 default . . . Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg08975/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] breakage
On Fri, Oct 18, 2002 at 11:16:25PM -0400, John Check wrote: On Friday 18 October 2002 11:02 pm, John Check wrote: Latest cvs build falls down with: g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -g -O2 -D_REENTRANT -c -o pt_lights.o `test -f 'pt_lights.cxx' || echo './'`pt_lights.cxx pt_lights.cxx: In function `ssgTimedSelector* gen_rabbit_lights(const point_list, const point_list, const int_list, const int_list, const std::string, float*)': pt_lights.cxx:304: `cout' undeclared (first use this function) pt_lights.cxx:304: (Each undeclared identifier is reported only once for each function it appears in.) make[2]: *** [pt_lights.o] Error 1 commenting out the cout's in pt_lights.cxx gets me past it. Plib Simgear and FG from CVS Okay now it dies with: g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -D_REENTRANT -c -o main.o `test -f 'main.cxx' || echo './'`main.cxx main.cxx:152: `void (*glPointParameterfEXT)(unsigned int, float)' redeclared as different kind of symbol /usr/X11R6/include/GL/gl.h:2519: previous declaration of `void glPointParameterfEXT(unsigned int, float)' main.cxx:153: `void (*glPointParameterfvEXT)(unsigned int, const GLfloat*)' redeclared as different kind of symbol /usr/X11R6/include/GL/gl.h:2520: previous declaration of `void glPointParameterfvEXT(unsigned int, const GLfloat*)' Are you using Mesa 4, or Mesa 3? I've had some problems building Simgear and FlightGear recently, due to (apparently) some changes between Mesa 3.4 and Mesa 4.0 (which I'm using through the DRI cvs tree now). I'm not sure if this is a bug with Mesa 4.0 or with FlightGear - I'm investigating it at the moment . . . Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg08976/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] breakage
On Sat, Oct 19, 2002 at 08:53:54PM +1000, Simon Fowler wrote: On Fri, Oct 18, 2002 at 11:16:25PM -0400, John Check wrote: On Friday 18 October 2002 11:02 pm, John Check wrote: Latest cvs build falls down with: g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -g -O2 -D_REENTRANT -c -o pt_lights.o `test -f 'pt_lights.cxx' || echo './'`pt_lights.cxx pt_lights.cxx: In function `ssgTimedSelector* gen_rabbit_lights(const point_list, const point_list, const int_list, const int_list, const std::string, float*)': pt_lights.cxx:304: `cout' undeclared (first use this function) pt_lights.cxx:304: (Each undeclared identifier is reported only once for each function it appears in.) make[2]: *** [pt_lights.o] Error 1 commenting out the cout's in pt_lights.cxx gets me past it. Plib Simgear and FG from CVS Okay now it dies with: g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -D_REENTRANT -c -o main.o `test -f 'main.cxx' || echo './'`main.cxx main.cxx:152: `void (*glPointParameterfEXT)(unsigned int, float)' redeclared as different kind of symbol /usr/X11R6/include/GL/gl.h:2519: previous declaration of `void glPointParameterfEXT(unsigned int, float)' main.cxx:153: `void (*glPointParameterfvEXT)(unsigned int, const GLfloat*)' redeclared as different kind of symbol /usr/X11R6/include/GL/gl.h:2520: previous declaration of `void glPointParameterfvEXT(unsigned int, const GLfloat*)' Are you using Mesa 4, or Mesa 3? I've had some problems building Simgear and FlightGear recently, due to (apparently) some changes between Mesa 3.4 and Mesa 4.0 (which I'm using through the DRI cvs tree now). Actually, I just got the same error with (according to GL/gl.h) Mesa 3.4, so that's not it. Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg08977/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] breakage
On Sat, Oct 19, 2002 at 09:55:46PM +1000, Simon Fowler wrote: On Sat, Oct 19, 2002 at 08:53:54PM +1000, Simon Fowler wrote: On Fri, Oct 18, 2002 at 11:16:25PM -0400, John Check wrote: Okay now it dies with: g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -D_REENTRANT -c -o main.o `test -f 'main.cxx' || echo './'`main.cxx main.cxx:152: `void (*glPointParameterfEXT)(unsigned int, float)' redeclared as different kind of symbol /usr/X11R6/include/GL/gl.h:2519: previous declaration of `void glPointParameterfEXT(unsigned int, float)' main.cxx:153: `void (*glPointParameterfvEXT)(unsigned int, const GLfloat*)' redeclared as different kind of symbol /usr/X11R6/include/GL/gl.h:2520: previous declaration of `void glPointParameterfvEXT(unsigned int, const GLfloat*)' Are you using Mesa 4, or Mesa 3? I've had some problems building Simgear and FlightGear recently, due to (apparently) some changes between Mesa 3.4 and Mesa 4.0 (which I'm using through the DRI cvs tree now). Actually, I just got the same error with (according to GL/gl.h) Mesa 3.4, so that's not it. And it went away again, when I stopped defining GL_GLEXT_LEGACY . . . In Mesa 3.4's gl.h glPointParameterfvEXT is wrapped in a #ifdef GL_GLEXT_LEGACY (as is glActiveTextureARB in Mesa 4.0, which is why I was playing around with it). I got the error above when GL_GLEXT_LEGACY was defined, and it went away without it. Anyone with more knowledge of OpenGL got any clues? Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg08978/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] Airport Database Model
On Thu, Oct 10, 2002 at 01:10:55PM -0700, Andy Ross wrote: Curtis L. Olson wrote: Just a couple thoughts to consider. We are looking at 16-20,000 airports so we couldn't stuff them all in a single directory. Even splitting them into subdirectories by first letter probably isn't enough. There are 17073 airports in the current database. Splitting on first letter only, the largest is (no surprise) 'K', with 2161 airports. On a lark, I created such a directory containing all the US airports. The creation process was relatively slow -- 20 seconds or so. But once the files are there, access to them is very fast (a few tenths of a second). This was true even after I was careful to flush the buffer cache by cat'ing a different disk to /dev/null, if the stuff is in the cache, of course, access is milliseconds at most. If you think about it, 2000 is about the same number as the number of device files in /dev, and no is complaining about performance issues there. One thing to note here is that all this cache take up RAM, and will be dropped on the floor as soon as there's any memory pressure. As it stands, on a 128MB system FlightGear will probably push most of that data out with it's own memory use, let alone leaving space for any other apps . . . So you'd likely get large performance deltas for this system depending on many subtle issues in the VM and VFS. At least using our own code would allow us to make things consistent . . . Not that I think it's a bad idea at all, though, particularly for the future: under Linux at least there are a number of new developments in filesystem-land that will make using this kind of thing much easier. ReiserFS is specifically designed for that kind of thing, and ext3 with the directory index performs as well or better on large directories. XFS probably handles such things fairly well, too. Reiser has tail packing, though at a performance cost, and there's some talk of adding tail packing to ext3. The problem is, FlightGear is portable, and most of these new features are Linux-only, and linux-2.4.$BIGNUM or 2.5+ only . . . Performing well under Linux with ReiserFS is a good advertisement for Linux and ReiserFS, but not so good for FlightGear if that's /all/ we perform well under. snippage the size of the scenery. Remember that with a file per airport, there is no need to have the whole airport database in the base package. You can download the airports along with the scenery. Airports aren't very useful without scenery, anyway. I rather like the idea of the airport files being /part/ of the scenery. It certainly seems to be where they'd belong, logically speaking. It'd also mean that the airports in the scenery matched perfectly the airports that FlightGear sees when running (unless you've explicitly hacked things up) - there've been several reports of runways and their navaids being completely out of sync with the scenery, and this seems like a good way to fix them . . . Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg08800/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] Error compiling FG 0.80
On Sat, Sep 28, 2002 at 07:31:54AM -0500, Sydney Weidman wrote: Hi! I was just trying to compile the latest release of FG, but I got a bunch of errors. I notice the errors involve gcc 3.2 stdc++ headers, so maybe I have used an unsupported version of gcc. Some compiler error messages follow. Thanks for this entertaining and interesting software. Regards, Syd. Making all in Airports make[2]: Entering directory `/home/gnome2/working/FlightGear-0.8.0/src/Airports'g++ -g -O2 -L/usr/X11R6/lib -o gensimple gensimple.o libAirports.a -lsgdebug -lsgmisc -lsgxml -lmk4 -lz -lm libAirports.a(simple.o): In function `FGAirports::FGAirports[not-in-charge](std::basic_stringchar, std::char_traitschar, std::allocatorchar const)': /usr/include/c++/3.2/bits/basic_string.h:781: undefined reference to `c4_Storage::c4_Storage[in-charge](char const*, int)' libAirports.a(simple.o): In function `FGAirports::FGAirports[not-in-charge](std::basic_stringchar, std::char_traitschar, std::allocatorchar const)': /home/gnome2/working/FlightGear-0.8.0/src/Airports/simple.cxx:77: undefined reference to `c4_Storage::Strategy() const' /home/gnome2/working/FlightGear-0.8.0/src/Airports/simple.cxx:82: undefined reference to `c4_View::c4_View[in-charge](c4_Sequence*)' /home/gnome2/working/FlightGear-0.8.0/src/Airports/simple.cxx:83: undefined reference to `c4_Storage::GetAs(char const*)' so on and so forth... Make sure you've compiled all the libraries flightgear depends on with the same compiler you built flightgear with (that includes libmetakit, which is where I've seen problems). Not sure if you'd see this with standard libraries, but I've definitely seen this with metakit when using the Debian packages and building flightgear with gcc-3.2 . . . Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg08467/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] Compile error in src/Systems/electrical.cxx with g++-3.2
On Wed, Sep 25, 2002 at 07:37:55AM -0500, Curtis L. Olson wrote: I think MSVC reports the same errors. I really shouldn't be using cout here, it's just easier/quicker when hacking on the code. I'll fix that up. It builds now - thanks for the prompt fix ;-) Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg08384/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] Compile error with plib
On Wed, Jul 10, 2002 at 08:32:13AM -0400, William Earnest wrote: Alex Perry wrote: Try the attatched patch - it works for me(tm). If it works for you, I'll see about sending it to the plib list . . . It fixed it for me too. SimGear build is now in progress. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Hello, Working here now also, thanks. And it's been committed, so all is well. Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg07612/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] FDMs and external atmosphere
On Wed, May 15, 2002 at 06:24:55AM -0400, David Megginson wrote: Now that the environment subsystem can manage its own atmosphere model (at least up to 60,000 ft or so), I've added an option to use that model instead of the built-in model in each FDM (the default is still to let the FDM manage the atmosphere). If you run with fgfs --prop:/environment/params/control-fdm-atmosphere JSBSim and YASim will bypass their own atmosphere models use the values from the environment subsystem. Currently, YASim seems to be working fine with this after a few lines of code changes, but JSBSim is not. JSBSim has built-in support for an external atmosphere, and the values seem to be getting through OK (after removing some spurious set_* methods), but the trimming routine gets caught in a loop. I'd be very grateful if Tony and others could look at this and figure out what the problem might be. Why use an external atmosphere model at all? Of course we want to be able to control the atmosphere rather than always flying at the equivalent of 15 degC temperature, 28.5 inHG, and 0.00237 slugs/ft^3 density at sea level. We could do that by providing the sea-level defaults and letting the FDM's atmosphere models calculate the values at altitude (it would also require a few lines of code change), but unfortunately, the FDMs are not the only subsystems that need atmosphere information -- we also need it for the some of the instruments, for the engine model (which might not always be built-into the FDM), for cabin pressurisation, and for weather reports like the ATIS, for icing, and who knows what else. Are there any plans for adding support for the interesting bits of weather to this model? (ie, storms, realistic winds that actually relate to the rest of the weather model, etc) There seemed to be support for them in the CM weather stuff, and it seems a little redundant to be adding a new, less capable model when there's one already there . . . Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg06064/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] Linux IDE
On Sun, May 12, 2002 at 10:47:55AM -0400, David Megginson wrote: snip lots of good emacs p1mping ;-) On the down side, Emacs takes a while to learn; on the up side, once you've learned it, you can do anything you want extremely fast (I've amazed customers during onsite visits by making complex changes to large programs or document collections in less than a minute where they'd budgetted days for the work). One of the other good thigns about emacs is that it's well documented, and it really is largely /self/ documenting - even if you only ever use the M-x long command name stuff, it still gives you a very good idea of what a command does, and with tab completion you can browse through all the cvs-* or tags-* or whatever and get an overview of your options. emacs is a really remarkable piece of software, really . . . Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg06040/pgp0.pgp Description: PGP signature
[Flightgear-devel] Spinning propellers and framerates.
While playing around with different versions of the DRI Radeon drivers today, I noticed an odd thing: with the standard c172 model in the external view, if I look at the model from head on, I get 20-25 fps, whereas if I look from a perspective where part of the spinning propeller disk is obscured by the airframe, I get ~6 fps. I get the same 6 fps all the time when I run with the 3d model. I'm just curious whether this same effect is seen by anyone else, particularly people running NVidia hardware - if it's a driver issue, I'll take this to the DRI devel list. If it's something to do with FlightGear or plib, it'd be nice if there was some way to deal with this - being limited to around 6 fps makes the 3d models almost unusable by me, and I don't have the money to upgrade to faster hardware . . . For the record, I have a K7 550, a Radeon QD (32 MB), Linux 2.4.19-pre8, XFree86 4.2.0, and the latest DRI CVS tree, along with the latest CVS trees from FlightGear, SimGear and plib. Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg05962/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] Joydev interaction bug?
On Fri, Apr 26, 2002 at 09:33:23PM -0700, Alex Perry wrote: For example, say I'm a long-time X-Plane user and just can't live with the default FG key bindings. I could create my very own ~/.fgfs/keyboard.xml and completely override the master file. That's exactly why the keymappings are broken out of the preferences.xml You can have two keyfiles and switch between them by changing one line. You're assuming that the user has write access to the FGBASE dir -- I'm not. On a shared system, each user would have to have their own FGBASE in order to use a different keyboard.xml file. Right? Now I understand what you're asking. First, I think you can over-ride the preferences.xml on the command line, write and refer to your own custom one, and inside that selectively refer to the subfiles of the original. Second, a read-only site-wide preferences.xml should be very minimalist so that it isn't too difficult to use the .fgfsrc and command line settings. What about allowing the user to specify a .xml file to load instead of the defaults for each of the config files? ie fgfs --keyboard-prefs=~/.fgfs/my-keyboard.xml and the like? That'd make things /far/ more flexible, and it'd fit nicely with the current .fgfsrc system . . . I don't know how the preferences loading code works, but it shouldn't be hard to extend it to handle this . . . Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg05835/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] YASim C172 idle
On Sun, Apr 14, 2002 at 12:14:54PM -0700, Andy Ross wrote: David Megginson wrote: According to one of my flight-school texts, high-wing aircraft don't usually need much dihedral on the wings because of the keel effect -- most of the weight of the plane is below the wings and thus the plane will naturally tend towards level. Actually, this is a myth. :) The wrong assumption that causes it is that the lift force always points up, away from the ground. It doesn't, it always points up from the wings, through the c.g. of the aircraft. By definition, it can't possibly produce a torque. Here's a gedanken experiment to prove it wrong: draw an aircraft from the front, in level flight. Now draw the wing lift vector; it goes straight up through the c.g. Now draw a banked aircraft. Draw the aerodynamic force vector that causes the righting moment. If it doesn't pass through the c.g., you've drawn an air flow that somehow knows whether it is flowing around an aircraft in a bank or not. Air isn't that smart. :) I'm actually fuzzy on the real reason that high-wing aircraft have a built-in dihedral-like effect. It has something to do with the fact that while in yawed flight, high wing aircraft have a low-pressure region on the lower surface of their wings, producing a rolling moment away from the yaw (and thus away from the direction of an uncoordinated turn). Low-wing aircraft have the opposite effect. Like I said, though, I'm fuzzy on the details; so YASim models neither effect. Dihedral is much more susceptible to quantitative treatment. Take a look at http://www.monmouth.com/~jsd/how/htm/roll.html . . . And I have one question: isn't the point where the lift vector acts defined by the external shape of the aircraft, whereas the center of mass is defined by the mass distribution? In which case, what's to stop the two from being in different places? And if they are, and you roll the aircraft around it's c.g., wouldn't you get the components of the lift vector generating torque around the c.g.? In a high wing aircraft where the lift vector acts at a point above the c.g., the vertical component of the lift would tend to counter the bank, though I'm not sure if it'd be balanced by the equivalent effect from the horizontal component . . . And I imagine any forces due to this would be vastly overshadowed by the aerodynamic forces. Am I missing something here? Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg05423/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] YASim C172 idle
On Sun, Apr 14, 2002 at 09:23:32PM -0700, Andy Ross wrote: Simon Fowler wrote: Andy Ross wrote: I'm actually fuzzy on the real reason that high-wing aircraft have a built-in dihedral-like effect. Take a look at http://www.monmouth.com/~jsd/how/htm/roll.html . . . Right. That's basically what I meant by fuzzy -- I understand how the effect works in this kind of qualitative see how it flies sense, but am clueless as to how to model it as a number in a computer program. This is an excellent page, though. And I have one question: isn't the point where the lift vector acts defined by the external shape of the aircraft, whereas the center of mass is defined by the mass distribution? In which case, what's to stop the two from being in different places? Nothing. That's how you apply torques on the aircraft to turn it or whatnot. And if they are, and you roll the aircraft around it's c.g., wouldn't you get the components of the lift vector generating torque around the c.g.? No, because the lift (strictly, aerodynamic force) vector is rotating with the aircraft frame. You're making the bad assumption: that if you rotate the aircraft, the lift will still point up. Think of it from the point of view of the gravity force -- it *always* acts on the c.g., and thus cannot produce a torque by definition. If there is any torque at all, it must be solely due to the aerodynamic force. If the aerodynamic force changes with rotation, then the airflow must somehow know that it is in a bank. It can't. Yes, I realise that - I may not have been entirely clear in explaining it, but I /was/ talking about the lift vector rotating with the airframe, where the gravitational force vector didn't. You seemed to be saying that the lift vector /always/ acted through the c.g., and this isn't the case. Thinking about it, I think I misread what you said . . . It's been a long time since I did any physics, but I haven't forgotten it /all/ ;-) Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg05429/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] FrameRate !!
On Sat, Apr 06, 2002 at 12:25:29PM -0500, Norman Vine wrote: Anyone know how to count 'cache invalidations' ? Under Linux, you can get this kind of thing from oprofile (http://oprofile.sf.net), if you have a motherboard with an IO-APIC interrupt controller. It's a very powerful profiling tool . . . I have no idea about windows. Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg05082/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] UIUC compile problem
On Wed, Apr 03, 2002 at 11:15:55AM +0200, Erik Hofman wrote:
It would be nice to see if the attached test program produces the
following output on all supported platforms(This would allow us to
improve the speed of the code dramattically by using memcpy instead of
for-loops):
0 1 2 3 4 5 6 7 8 9
Erik
#include stdio.h
#include string.h
int main () {
int a[2][2][5];
int b[2][5];
int q;
for (q=0; q 10; q++) {
a[0][q/5][q%5] = q;
a[1][q/5][q%5] = q+100;
}
memcpy(b, a[0], sizeof(b));
for (q=0; q 10; q++)
printf(%i\t, b[q/5][q%5]);
return 0;
}
8---
#include stdio.h
#include stdlib.h
int main(void)
{
char a[2][2][5];
char b[2][5];
char *p;
int index, i, j, k;
index = 0;
for(i = 0; i 2; i++) {
for(j = 0; j 2; j++) {
for(k = 0; k 5; k++) {
a[i][j][k] = k+j;
}
}
}
for(i = 0; i 2; i++) {
for(j = 0; j 5; j++) {
b[i][j] = i+j;
}
}
p = a[0][0][0];
for(index = 0; index sizeof(a); index++) {
printf(index a: %2d; element: %2d\n, index, *(p + index));
}
p = b[0][0];
for(index = 0; index sizeof(b); index++) {
printf(index b: %2d; element: %2d\n, index, *(p + index));
}
return 0;
}
8---
Compiled with both gcc and g++, this shows a to be two copies of b
arranged contiguously in memory, which would suggest that you can
indeed use memcpy the way you outlined . . .
Looking at my copy of KR I think that's funamentally how C handles
multidimensional arrays: from the right, each successive subscript
declares an array of n times the size of the array declared so far,
and when accessing an element, each subscript is multiplied by the
size of the array to the right of it and then added to the index
into the area of memory . . . Which isn't very coherent. The perils
of posting well past one's bedtime ;-) Still, I think it's
definitely safe to use memcpy this way . . .
So, memcpy away ;-)
Simon
--
PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc
(crappy) Homepage: http://bg77.anu.edu.au
doe #237 (see http://www.lemuria.org/DeCSS)
My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/
msg04826/pgp0.pgp
Description: PGP signature
Re: [Flightgear-devel] Re: compiling under Linux RedHat 7.2 and Accelerated 3D Summit openGL
On Mon, Apr 01, 2002 at 01:21:15PM -0800, Andy Ross wrote: All that being said, I'd be curious as you how your experience is with the XiG drivers. These provide the only useful Radeon support for Linux, right now, and are rather reasonably priced. The DRI Radeon drivers aren't useful? They work nicely for me . . . Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg04773/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] Re: compiling under Linux RedHat 7.2 and Accelerated 3D Summit openGL
On Mon, Apr 01, 2002 at 02:43:00PM -0800, Andy Ross wrote: Simon Fowler wrote: Andy Ross wrote: All that being said, I'd be curious as you how your experience is with the XiG drivers. These provide the only useful Radeon support for Linux, right now, and are rather reasonably priced. The DRI Radeon drivers aren't useful? They work nicely for me . . . Correct me if I'm wrong, but the last time I checked the DRI driver lacked support for the (now almost a year old) 8500 cards, had no hardware geometry acceleration, nor multitexture support. These might work, in the sense of producing correct results, but they are only semi-complete at best. Performance-wise, ATIs windows drivers stomp all over them. Whether that consitutes useful or not depends on your perspective, I guess. I should have picked a better term. The 8500 support is currently non-existant, yes, but tcl support is available for the original Radeon chips, and I believe multitexture support is likewise available, at least in the DRI cvs tree (which is quite easy to install and use - certainly no harder than dealing with FlightGear/SimGear/plib cvs trees). There are also binary snapshots of the latest development code available. Support for the 8500 /is/ planned - the docs are available, and the reason there's no support yet is because the developers are working on getting tcl support for the original Radeon working properly. This includes developing the framework for hardware tcl support, so that supporting the full feature set of the 8500 (and in fact /any/ chip that supports hardware tcl and similar) should be much easier. rant As for a comparison with ATI's windows drivers . . . . . How many man-hours has gone into them? Over how many years? Compared to about three people working on the DRI code intermittently over the last couple of years . . . At least they have full documentation now. You might as well say that FlightGear isn't useful, because it doesn't have everything that Fly! does . . . /rant Yes, the DRI drivers are a work in progress, but at present they /do/ work, and they certainly work well enough that I'd choose to use them rather than fork out cash for binary drivers. The Xi Graphics folks at least claim to support the full feature set of the cards. I was curious as to how well it worked. They also ship with a broken gl.h, apparently . . . What that suggests about their quality control is left as an exercise for the reader. Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg04777/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] Re : Publicity
On Fri, Mar 29, 2002 at 07:56:10PM +0100, Arnt Karlsen wrote: On Fri, 29 Mar 2002 09:36:47 -0800 (PST), Alex Perry [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: I'm only familiar with the performance of old cards. The Matrox G400 is 'ok'. ...as in V fps at X x Y x Z bpp? With the DRI drivers on my Athlon 550 I could get 20+ fps at 800x600, 16bpp. This was with low poly-count scenery, though. Visual quality was /excellent/ - better than my current Radeon, and the DRI drivers were excellent, too. Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg04723/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] Re : Publicity
On Thu, Mar 28, 2002 at 10:29:13PM -0800, Alex Perry wrote: ATI Technologies Inc 3D Rage IIC AGP (rev 122), 8 MB vram. PCI id is 1002:4757 or 1002:475a according to http://pciids.sourceforge.net/iii/?s=1i=1002 According to the X headers (in the GLX source tree) that is a GW or GZ chip. The Utah-GLX project, from CVS, does not accelerate this under XFree86 3.3.x Currently, it is my understanding that the Mach64 is only accelerated for 2D under Xfree86 version 4.x using the DRI as part of released drivers. The mach64 DRI 3d driver is under active development at the moment - it's working, I believe, and actually working fairly well . . . See http://dri.sf.net - you may have to run the DRI cvs tree for this, and upgrade to XFree86 4.2, but it's not too hard . . . Not much harder than running plib/SimGear/FlightGear from cvs. Therefore, in conclusion, I suggest buying a new video card ... Considering how cheaply you can get modern, well supported cards, this might be the best option . . . Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg04699/pgp0.pgp Description: PGP signature
