Erik Hofman wrote:
> Martin Spott wrote:
> > Absolutely the same revision and date here. I don't have any idea if
> > 'truncf' and 'floorf' belong together but I can state that the latter
> > is definitely present:
>
> Does ffloor exists for Solaris?
Why do we care? Just call floor(), which is in
Richard Harke wrote:
> I have found the bug leading to a seg fault that I reported
> previously (on the flightgear-users list). Though this is on
> an ia64, the bug is not completely architecture dependant.
> [...]
> For several architectures, reftag does not overlay num and needs
> to be explicitl
Seamus Thomas Carroll wrote:
> I just added #include source/src/Cockpit/panel.cxx
> recompiled and still the same error.
Then something is bad wrong. Your configure script is detected the
truncf function when it ran, but it isn't there for you at compile
time. Both of those conditions can't be
Seamus Thomas Carroll wrote:
> I have read the discussion about the truncf problem and with the
> latest cvs checkout i still recieve the error. The messages subject
> is: Re: [Flightgear-devel] Re: Fix for compilation error in panel.cxx:
> `truncf' undeclared
>
> I did not notice any real solutio
[Bouncing to flightgear-devel, since this is so very much not a user
question. :)]
Richard Harke wrote:
> For example, back trace shows naHash_set called from hashcolumn which
> is not so. This may be related to architecture, I'm on ia64.
>
> Any case if I knew what nasal is supposed to do, it wo
David Megginson wrote:
> I'm not sure about using an index="" attribute, since it isn't fully
> transparent. Perhaps you could allow a way to attach internal
> identifiers to spot weights:
>
>
>
> As a matter of fact, an "id" or "name" attribute generally might
> improve debugging.
OK, this feat
I wrote:
> It wouldn't be hard to get the solver to handle both situations. You
> could have a fuel-fraction="..." attribute in the and
> blocks, and a sub-tag
> where you set the weights. Does that sound acceptable?
OK, the fuel bit is done. You can now specify fuel="1.0" in the cruise
tag
David Megginson wrote:
> I've noticed that the performance of the PA-28-161 is slightly
> sluggish in the climb, and I'm wondering if it has to do with weight.
> The published performance numbers for this plane (and most others) in
> the POH assume maximum gross weight. Does the solver assume that
Vivian Meazza wrote:
> I think it should work, and it _looks_ as if it does: certainly when
> you browse internal properties it looks right, but I can't set the
> second [1] tank to zero.
I'm still fuzzy. Do you mean that you can't set the property to zero
at all, or that the property goes to zer
Vivian Meazza wrote:
> Yes, this problem was interesting. I set up 2 weights thus:
>
> /yasim/weights/tank-100gal-lbs[0]
> /yasim/weights/tank-100gal-lbs[1]
Are you sure you got the definition right in the YASim
configuration file? The property definitions look fine, but they're
only half the pr
Innis Cunningham wrote:
> Unfortunately the spoiler/speedbrake system/s seem to be much more
> complicated than something that can be controlled by one key. The
> Boeing 7 series A/C,not including the badge engineered 717, use the
> same panels as speedbrakes and spoilers.They act as spoilers in
>
Vivian Meazza wrote:
> I've just done some proof-of-principle work on drop tanks with
> YASim. I set up some weight elements for the pylons and for the dry
> weight of the tanks, and some fuel tanks to match.
> [...]
> However, the bad news is that I can't set _one_ of the drop tank
> weights to ze
Lee Elliott wrote:
> I think drop tanks would be feasible but it would need some thinking
> about:)
>
> The fun bit will be counteracting the a/c manuevours after the tank
> has dropped so it falls straight even though the a/c may be climbing
> and banking.
This is more of a code architecture issu
Norman Vine wrote:
> Why this position is expressed as [lat, lon, alt] instead of [X,Y,Z]
> ( or perhaps both shold be passed ) is a relavant question but
The lat/lon/alt stuff is a sane convention, and especially easy for
simple code (Nasal scripts, for instance) to parse and use.
I agree t
Jon S. Berndt wrote:
> IIRC, YASim provides for the origin at the nose tip too (or something
> close to that).
YASim doesn't care, actually. It reports the output lat/lon/alt value
as the location of the coordinate origin of the airframe (that is, the
0,0,0 referenced by all the coordinates it fi
David Megginson wrote:
> I just took a glance at the stations in the service and maintenance
> manual for the PA-28-151/161, and the technical drawings have
> measurements positive towards the tail in the longitudinal (x) axis
> and positive upwards in the vertical (Z) axis. In the lateral (y)
> a
I wrote:
> The wing twist bugfix went in, presumably that's the issue. I
> checked the first version I checked in (no sqrt(frac) term) against
> the DC-3, but not the second. I'll take a look.
Yeah, that was it. I've backed it out to the interrim version (with
the symettry fix, but without the
Dave Perry wrote:
> I updated from cvs last night and noticed that both the j3cub and the
> dc3 no longer converge in yasim. I checked several other yasim
> aircraft, and their models all converged. (an225, a10, p51d, and
> c172). Has anything changed in yasim?
The wing twist bugfix went in, pr
Jon S. Berndt wrote:
> Can the view offset or rendering code (whatever it is that draws the
> 3D aircraft models) move the origin of the set of vertices that
> defines the model per-frame so that the CG aligns with that reported
> by the FDM?
Well, yes, because they're just properties. But unless
Russell Sutter wrote:
> David Megginson wrote:
> > Andy Ross wrote:
> > > I'm not sure exactly what this is for. I can (and probably
> > > should) export the C.G. position for the view code to use
> > > appropriately. But the VRP stuff seems like
David Megginson wrote:
> Thanks -- your explanation and Jon's has made it all clear, and the
> discussion has been useful. So, as far as I understand, JSBSim
> supports this in JSBSim CVS but not yet in FlightGear. Does YASim
> support setting the reference point yet?
I'm not sure exactly what t
Martin Spott wrote:
> On the other hand it might be easier to 'preload' the data into
> memory and prevent this memory area to being swapped out (there
> should be some operating system call),
There certainly is. It's called "read()". :)
Andy
___
Flig
Martin Spott wrote:
> Jim Wilson wrote:
> > If the camera is tracking the nose, then it moves up and down as
> > well with the nose. This creates the _illusion_ that the rest of
> > the aircraft (and of the scene for that matter) is moving, and the
> > nose is remaining stationary when in fact it
Norman Vine wrote:
> Jon S. Berndt wrote:
> > It is thought that the use of a RAM disk might help.
>
> On Windows I have found that increading disk cache size and / or
> using memory mapped files is more productive then a DAM disk
My interpretation was that their problem was latency, not I/O
throu
Jon S. Berndt wrote:
> Is anyone aware of a RAM disk utility or feature under Unix
> (specifically, IRIX)? When running a simulation on IRIX we are
> finding that the disk access is taking too much time at various
> phase boundaries. It is thought that the use of a RAM disk might
> help.
RAM dis
Some quick suggestions:
You wrote:
> interpolate("/controls/gear/brake-left",
> props.globals.getNode("/controls/gear/brake-left").getValue(),
> 0, 1, 0.1)
Actually, the implementation of interpolate() always starts from the
current value of a property, so in fact there's
Josh Babcock wrote:
> I tried propertySlew() but it seems that the value wasn't going to
> the numbers I supplied, but only slewing for a very short period of
> time taht wasn't even consistant.
You need to mark the bindings repeatable. See the trim bindings for
examples.
The propertySlew() func
David Megginson wrote:
> It looks like I screwed it up between versions 1.3 and 1.4; in 1.3, I had
>
> s->setTwist(_twist * Math::sqrt(1-frac))
> s->setTwist(_twist * Math::sqrt(frac))
>
> I don't know exactly what I was trying to accomplish with this,
> except perhaps to make sure that the twist
Vivian Meazza wrote:
> Whilst working on the DC3 model, trying to help a little with this
> problem, I noted that the model flies left-wing low. This seems to
> be related to the twist element set on the wing. The DC3 has -3 deg
> set. Reverse this and the model flies wings right wing low. It seems
David Megginson wrote:
> When you shut down the engine in YASim, the propeller does not
> windmill -- it just slowly spins down and stops.
Probably because of the internal engine friction, I was looking at the
propeller only. What's the right windmilling RPM? I can tune, but
need numbers. :)
An
David Megginson wrote:
> I tried to fix this problem in JSBSim a year or two ago, and I seem to
> recall that no one on the flight model list could quite figure out how
> to code it back then. I also took a stab at YSBSim, and failed just
> as miserably. Neither model is set up to have the propel
Curtis L. Olson wrote:
> The real fun comes from practicing with only one engine running
> [...] There are some real world effects that are important for
> training which I don't think we model well on existing twins.
>
> The main one that comes to mind is that with an engine out there is
> a mini
Roy Vegard Ovesen wrote:
> David Megginson wrote:
> > Originally, the TC responded instantly -- I had to do a fair bit of
> > work adding the slight lag to make it work like a real TC. The lag
> > smooths out the indication a bit.
>
> So I shouldn't touch the responsiveness then?!. But rather add
Matthew Law wrote:
> I was planning on doing a basic collision detection between the AI
> aircraft and the user aircraft. Initially not between AI planes until
> you were finished working on them, hopefully to prevent it causing you
> problems :-)
> [...]
> What are people's thoughts on this? Do
David Luff wrote:
> cvs update: failed to create lock directory for
> /var/cvs/SimGear-0.3/SimGear/simgear/environment
This is a new directory, apparently is isn't owned by the appropriate
group.
Curt: the best way to handle this is to make sure that all the
directories in the repository have t
Norman Vine wrote:
> There is a conflict between and some of the libstdc++ STL
> headers unless all of the STL includes are included before
> or visa versa
>
> otherwise some versions of the GNU compilers need NOMINMAX defined
>
> I *really* don't understand why this isn't done in the configure
Jim Brennan wrote:
> [UAL 747-400 flaps settings]
Great stuff, thanks. It's in CVS. The only problems are that the
current control system doesn't support the joint slats/flaps deployment
(it can only drive one property from the stuff, I'll have
to think on how to fix that) and there is no model
Jon Wojnaroski wrote:
> Finally got around to moving up to 0.9.3. Now the 737 comes up on
> the runway with dead engines. Prop models seem to work and the
> YASIM-747 comes up running.
To be fair: YAsim jets can't be shut off. :)
Andy
___
Flightgear-de
Jon wrote:
> Christian wrote:
> > If we'd use SI units everywhere we wouldn't have that prolem...
>
> Well, yes we would have.
Jon's right, you can't win. Using SI pervasively sounds like a great
idea, but it doesn't win you much. Even outside the USA, you don't
see engines rated in watts or new
Jon S. Berndt wrote:
> Do we need a standard Interface Control Document that formalizes the
> FlightGear/FDM interface?
Sounds like a good idea to me. I'd propose the following two
requirements:
1.) It should be specified via property names, rather than as a C++
interface. This is much easi
Curt wrote:
> I wrote:
> > We have to kill him now.
>
> Is that Oregon's answer to affordable universal health coverage? :-)
Don't joke like that, you'll give them ideas. I just mailed off my
ballot voting for a tax increase to keep the government running.
I guess the joke was a wee bit obscure.
[EMAIL PROTECTED] wrote:
> Mail transaction failed. Partial message is available.
Oh no! Curt's infected. We have to kill him now.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Cameron Moore wrote:
> I'm wanting an auto-zooming tower view.
Sounds good. My first thought would be to set an updater function to
run at something sane (maybe 5Hz). This would calculate the target
zoom level, and use an interpolator to slew it to the right value over
the next fraction of a sec
Roy Vegard Ovesen wrote:
> I just started looking at Nasal, and I think that could be used for
> summing, gaining, if...then, etc.
It certainly could. In the past I've warned (for performance reasons)
about getting into situations where a zillion Nasal scripts expect to
run every frame, but for t
Lee Elliott wrote:
> I think I've heard of some of the stuff Curt's referring to - the next
> gen US fighters are planned to be thrust vectoring only. Taking the
> control surface stuff out of the wing removes channeling, making it
> more simple but also stronger and more resiliant to damage - you
Cameron Moore wrote:
> Is it possible to use nasal scripting in preferences.xml? I'm
> specifically interested in using it in a definition.
You can have Nasal blocks under /nasal/ in the property
tree like this:
Where/Ever/my-module.nas
Or you can put the source code inline inside a
David Culp wrote:
> Thanks Andy and Roy. The binding worked, but unfortunately the property I
> need doesn't exist :(
>
> Looks like I finally have to learn nasal.
Without having done any testing, testing, this would seem to do what
you want. Basically, it's just a property-assign with a units
David Culp wrote:
> For Innis' new 737 panel we could use a "set" action, that will set
> a property to the value of another property.
Use a nasal script. :)
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/l
David Culp wrote:
> Unless you fly into someplace below sea level, where the floor of
> -0.01 is -1.
And that's wrong? Why?
Mild flame time: truncate-toward-zero is one of those things like
acos/asin/atan that you want to avoid like the plague. It has almost
no mathematical meaning (its output
Bernie Bright wrote:
> this should really be tested for by the configure script -
> AC_CHECK_FUNCS(truncf) and panel.cxx should then contain:
>
> #ifndef HAVE_TRUNCF
> inline float truncf (float d) { ...
> #endif
Um, or you could just use floor() instead, which does the same thing
and works everyw
Jim Wilson wrote:
> That has nothing at all to do with what I said. We are controlling
> individual control surfaces. Period. I don't think we should have
> subclasses for each desired action/process. Only each control
> surface type. Roll control ends up being intrinsically part of
> aileron
Richard Hornby wrote:
> Any chanceof doing a look-ahead on the scenery polygons to get an
> altitude eg 2mi in front (for TSR2?)
Yes, so long as the tile is loaded. But that's not the way that real
autopilots work. The real world doesn't have a scenery elevation
API. :)
Doing this right would p
David Culp wrote:
> This thread is scaring me. I hope we aren't deciding to hard-wire
> the autoflight inputs from panel instrument output?
Why hardwire anything? Why not write it to take property nodes as the
input and output entities, and let the glue layers (XML, Nasal,
etc...) handle the con
Adam D. Snyder wrote:
> After reading through "fg_props.hxx", I found that the most efficient
> was to get a property value is to use fgGetNode instead of the "fgGet"
> functions. Is there a more efficient way to set properties, or is
> that best way to use the "fgSet" functions
The node obje
Erik Hofman wrote:
> Adam Boggs wrote:
> > WARNING: PUI: Trying to remove invalid puGroup from puGroup stack!
>
> This is one we have to look after, but so far no one seems brave
> enough to tackle this problem.
This was actually a plib bug. It got fixed about a month or so ago.
I think it was h
Innis Cunningham wrote:
> I downloaded a program call Audacity which allows
> me to change the Khz but it does not tell me if it is
> 8bit or not.
Take a look at "sox" (should be installed by default). It's a command
line tool for audio format translation.
Andy
Innis Cunningham wrote:
> So if you are not into 3D modeling the 2D panel might be the best
> place to start.
You can map a 2D panel into a 3D cockpit; see the c172 model files.
Basically, you define corners for the quad you want the panel to
appear in, and FlightGear draws it appropriately.
Opin
David Megginson wrote:
> First, the intensity is far too low. At 0.5, I wasn't sure if
> turbulence was working, and at 1.0 (maximum), I was still able to
> control the aircraft easily.
Hrm, so it is. :)
I must have changed something right at checkin. My memory of the
final code is that the Cub
Lee Elliott wrote:
> The tip of the nose is fine with me but we need to clarify whether
> the tip includes any nose-mounted pitots or probes.
Sure. Obviously it doesn't *really* matter. But picking some
unambiguous, obvious point on the fuselage just seems much more sane
to me than trying to exp
Alan King wrote:
> The 'nose' is a bad choice for either the viewing center or the FDM
> center.
Except for the obvious fact that it's 100% unambiguous. It's not
uncommon for the FDM definition and 3D model to be done by different
authors. Take 21 people and ask them to identify the "POS" (or
qu
Jon S. Berndt wrote:
> The rigid body response to a force and torque can be in roll, pitch,
> yaw, and/or X, Y, Z translation. That's six DoF. How does the
> seventh degree come into play?
I wasn't clear: the rigid body response function takes a 6DOF space
(force + torque) to another 6DOF space
Erik Hofman wrote:
> Paul Surgeon wrote:
> > Aha!
> > So AC_AERORP = (0,0,0) in FlightGear's 3D aircraft model space?
>
> No, sorry. AC_EARORP is the published offset from CG to where the
> forces act. For the F-16 that would be 35% chord (and CG is 25%
> chord).
Surely that's an approximation, no
I just commited a turbulence model that I wrote over the vacation. It
seems to work pretty well, but I'd be curious to see what other people
think. Tuning it is more subjective than I had expected.
Basically, this is a a Perlin noise based scale-invariant vector field
that gets added to the loca
John Wojnaroski wrote:
> Andy Ross wrote:
> > with an aircraft. An aircraft held in a level sideslip will turn, for
> > example, due to the side forces caused by the slip, no wing lift need
> > be involved.
>
> Define 'level', if the wings are level, REAL
Hof Markus wrote:
> I'll think about this on weekend, but anyway, wheter to use rudder
> or not. Take the A320 (on FG) and watch the ball. All I want to
> know, which property to use for trigger function to keep the ball
> centered. since you discussed this topic so deeply, I'm sure
> someone can
David Megginson wrote:
> In the planes I've flown -- admittedly not a wide range of types --
> holding rudder generally induces a bank before there's a significant
> change in flight direction (as opposed to just heading).
Right, you need to hold it in the slip with opposing ailerons
(aerodynamica
John Wojnaroski wrote:
> Believe it or not, what makes an airplane turn is LIFT... think
> about it.
Well, OK. But let's not get too pedantic about things. What makes
any object change velocity is force. The best and most efficient way
to generate force with an airplane is with the wings (that
Jon S. Berndt wrote:
> Dell doesn't seem to market machines with Linux installed anymore,
> do they?
>
> Can anyone point me to a major manufacturer that does?
You can get servers from IBM and HP (and maybe others) preinstalled
with Red Hat or SuSE's enterprise offerings, but I'm not aware of
anyo
Jim Wilson wrote:
> Same as solution for dutch roll effect. No?
Not exactly. An autocoordinator moves the rudder to counteract slip
angle. A yaw damper moves the rudder to counteract yaw rate, which is
the time derivative of slip angle. An aircraft can be held in a slip
and a yaw damper won't
Jim Wilson wrote:
> Note, I'm suggesting adding Andy's work to plib as an alternative
> optimizer function, not a replacement for the current code.
No need for this. They produce identical results if you set the sharp
angle to 180 degrees. All someone needs to do is export the value via
the load
Josh Babcock wrote:
> OK, the snapshot file solves that problem, but I think that main.o >
> is failing to link. See here:
You swapped plib versions, but still have some SimGear and/or
FlightGear files compiled against the old one. In general, C++
libraries aren't binary compatible across versio
Jon S. Berndt wrote:
> FCS->SetLBrake(FMAX(globals->get_controls()->get_brake(0), parking_brake));
> FCS->SetRBrake(FMAX(globals->get_controls()->get_brake(1), parking_brake));
> FCS->SetCBrake( globals->get_controls()->get_brake(2) );
That convention only works for tricycle gear airplanes with th
Josh Babcock wrote:
> What would those config changes tor YASim be? That sounds like
> something that I could do.
In the YASim aircraft descriptions, you would modify the
tags for the gear to point to something like
"/control/gear/{left|right|parking}" depending on the location of the
gear.
The
Josh Babcock wrote:
> Well, this download is working better, but it is complaining:
> Makefile:315: *** missing separator. Stop.
Which Makefile?
> I also had to move Makefile.am back into the base directory.
Had to or... what? As always, bug reports with complete symptom
descriptions are easie
Josh Babcock wrote:
> I didn't see anything in the archives about this, so I'll ask here.
> Is there any good way to address the wheels on the left or the
> wheels on the right?
No. This is pretty much a bug with the current brake control system.
It confuses the notion "wheel" with "brake pedal/l
Josh Babcock wrote:
> is this one differnt than the one at:
> http://www.plausible.org/vertsplit/vertsplit2.tar.gz?
> That's the one that I'm trying to apply now, without luck.
It's essentially identical. It should just work to drop the files
into your src/ssg directory and do a rebuild. What pr
Josh Babcock wrote:
> I'm playing with this because I am designing an ac3d model in
> Blender, and am having a great deal of trouble getting the edges and
> shading to look right. [...] I don't want to go and add a bunch
> more polys around the sharp edges [...] Looks great in Blender
> though.
Matevz Jekovec wrote:
> Last times (might be nasal's fault maybe?) when editing the
> $fgfs/data/Input/Joysticks/Default/joystick.xml and setting the View
> elevation property to 7.0 (in order to
> increase the hat speed), there is no difference. The hat doesn't
> behave different anymore.
The "st
Curtis L. Olson wrote:
> It appears (to me) to be a property setting problem. Andy, does
> nasal have the ability to dump console output for temporary
> debugging?
Sure, there's a print() function which uses SG_LOG; for exactly this
purpose. There's even a fancy dump() method on a property node
Curt wrote:
> select = sel.getChild("engine", i);
> Could there be a bug in this form of getChild()?
Heh, bingo. That was exactly it. See the other post for notes.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightge
Curtis L. Olson wrote:
> David, (Andy?)
>
> It appears that in the latest cvs, we have lost the ability to control
> the engines independently.
This one is mine. The recent Nasal stuff contains a rework of the
engine handling to allow for arbitrary numbers of engines, and avoid
the "why are there
Paul Surgeon wrote:
> Why are we using wave files in the first place?
>
> Yes I know that they don't require decompression which saves CPU
> cycles but Ogg Vorbis compression is excellent and it's GPL.
No reason. Someone needs to do the work to integrate plib (which
provides our sound loader) wit
Paul Surgeon wrote:
> Regarding the mouse pointer :
> Is there a way of disabling the cross hair (control input) so that it just
> toggles between normal and pan view and skips the control input
> mode?
Just remove or comment out the declaration for mode 1 in mice.xml. You will
need to rename the
Lee Elliot wrote:
> The stuff I did to enforce a single flap setting on the b-52, and to allow
> four flap postions on other aircraft no longer works - all of the
> aircraft now seem to have three position flaps (this seems to be
> hard-coded into the controls.nas script)
>From a few days back:
+
Dave Perry wrote:
> I noticed that the ADF frequencies displayed no longer agree with the
> Equipment>Radios pull-down menues. [...]
>
> Is this just a temporary artifact of the binding change over to Nasal?
I don't think so. I've only modified the keyboard and joystick
bindings so far; the radi
David Culp wrote:
> You can practice refueling to some extent in FlightGear using the AI
> tanker. There is an annoying problem though, in that as you get close
> to the tanker it appears to jump in 30-foot leaps (so you can't
> *really* practice refueling).
That sounds like a bug. My reading of
Nick wrote:
> If the simulation is accurate the delays are due to the aircraft
> inertia and not control system delays. Hydraulic controls don't have
> a humanly discernable amount of delay. Simulators have their own
> delays too, the time it takes a signal to get through the circuit from
> the c
I just commited Nasal bindings for my Saitek X45. I'll get to the rest
soon, but this one is there as a working example if anyone wants to try
porting the bindings for their own stick. It should be mostly
self-explanatory.
Andy
___
Flightgear-devel
Erik Hofman wrote:
> I tried this with a linear interpolation table but I think a problem
> right now is the fact that the timer is frame rate dependent. And
> since I'm running at a frame rate of about 5 frames per second this
> can be a problem.
The interpolator is realtime (er, simtime) based;
Erik Hofman wrote:
> What method would you recommend for a script that basically has to run
> forever.
>
> What I'm trying to do is add continuous motion to the sailship by
> interpolating between +10 and -10 degrees pitch, but I haven't found a
> clue on how to do this with Nasal.
Probably the be
I finally found the Nasal memory corruption bug this morning. I was
right that it was triggered by garbage collection, but it wasn't in
the Nasal code. The FGBinding implementation was holding a
SGPropertyNode* and assuming that its callees would never try to use
the SGPropertyNode_ptr interface
Alan King wrote:
> Anyone up for making a serial device? I only do a little programming
> on the PC side of things, so am not currently up to the task I
> think. Needs sync bytes, something like this is common:
>
> FF FF 0 axis1 0 axis2 0 axis3 etc.
RS232 is an async protocol, there's no need for
Martin Spott wrote:
> a) Unload the kernel's GART module during the autodetection and load
>NVidia's special kernel module,
> b) replace the OpenGL libraries,
> c) run a special X Server.
Martin, just stop this flaming; "b" is true. "a" and "c" are not, and
have never been.
NVidia's drivers
As promised, here is the performance test of the geocentric->geodetic
implementations. As before, it's a stand-alone C program that should
compile independantly and be easy to inspect and modify. Just run it
with a single argument of either "andy" or "toms" to select the
algorithm.
On my laptop
My requirement isn't accuracy, it's precision. The difference is
subtle: I don't care about whether or not the terrain is placed
correctly to within a micrometer. As you point out, the local geoid
("sea level", basically) errors are often off by tens of meters from
the WGS84 ellipsoid.
But I *do
Norman Vine wrote:
> Curtis L. Olson writes:
> > Why don't we go ahead and commit one of these since both sound a lot
> > better than what we have now. Then we could do some timing tests and
> > see if we need to consider trading precision for faster performance.
>
> Note this will cause a 'shift'
Gerhard Wesp wrote:
> - the use of static is deprecated for module-local objects, anonymous
> namespaces should be used instead.
Oh dear. Mild flame time. (Entirely irrelevant to the algorithms in
the new code, so uninterested folks can stop reading now. :)
I'm not big on C++ pedantry, obvious
Norman Vine wrote:
> Yes, this was written before the 'standard' was adopted and we just
> adopted it.
>
> I suggest that we use the attached geoc <-> geod transforms or a
> massaged version of them to reflect what we want for an interface
>
> Note these are arguably 'the current standard' slightl
While away from a joystick-enabled system over the weekend, I decided
to start hacking at the Nasal/AI integration. What I *really* wanted
to make work was carrier landings, which required getting velocity
information from the AI models. But this required work on the YASim
gear model to understan
Alan King wrote:
> A keyboard can be interrogated. A mouse outputs constant data
> and/or can be interrogated. A standard joystick does.. nothing.
Good grief. You appear to have completely missed the point (or have
an ancient concept of how joysticks work), and you're being a jerk
about it to
601 - 700 of 1471 matches
Mail list logo
