Re: [Flightgear-devel] John's position on combat simulation;

2007-05-13 Thread Martin Spott
John Wojnaroski wrote:
 Martin Spott wrote:

 Sorry, John, this has nothing to do with selective morality - as you
 allege. After reading these lines I'd say you have severe difficulties
 telling the difference between flying and shooting/killing.
 
 Ooo,  I don't think so.
 
 To make understanding it easier: Many/most of the old but also the
 modern warbirds are fascinating aircraft from a technical as well as
 from an aviatic point of view - no doubt. Yet this is significantly
 different from actually performing the shooting at some other aircraft
 or dropping bombs.
   
 
 Ahhh, so the basis for acrobatic manuevering was...and the reason 
 you need to put 9G's on your body is.  Your first point is quite 
 correct, but again fly them to you heart's content and DON'T complain if 
 others wish to do the same and simulate combat. That is all I am saying,

Yes, I _do_ domplain !

Here's your missing link: The simple reason that an aircraft was
originally _built_ for shooting and dropping bombs doesn't justify to
really _perform_ this action in a simulation as well. You're taking a
way too simple route here,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-13 Thread Harald JOHNSEN
Bill Galbraith wrote:

 

  

-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On 
Behalf Of Stefan Seifert
Sent: Saturday, May 12, 2007 10:38 PM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] More ideas on dogfighting

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

James Palmer wrote:



In your experience, Harald, what has been the approximate 
  

ratio of FDM 


vs Graphics vs remainder code on CPU time?  Has anyone done work on 
clocking the various subroutines in FG to determine this?  
  

(Perhaps I 


underestimate the CPU time required of the FDM?)
  

You could simply run stand-alone JSBSim 
(http://www.jsbsim.org) to see, how much CPU a FDM needs. I'd 
guess that Yasim lies in the same range.

Nine




I think that was investigated a few months ago. JSBSim FDM took only a
couple percent of the CPU, or course depending on your hardware and what you
were drawing. I don't think it's anything that you need to worry about.

BIll

  

I don't have fresh number but the time of a standalone JSBSim takes has 
nothing to do with the time the FDM takes in FG. First it depends on how 
many times you run it per second (in FG the default is 120 Hz). Second 
in addition to the fdm itself we are computing some ground intersection. 
And since the world geometry is very badly organized in FG this can take 
some non negligeable time (but we should see a great improvment in the 
intersection code with the osg branch). Now if the server is doing the 
FDM computation it's obvious that there is no need to do that 120 times 
per second because the data can not be send at that rate.
How many loops does the mp server need to do per second ? 10 ? 20 ? At 
that frequency you could handle 100 clients with no problems.

Harald.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] [BUG] FG - CVS - HEAD

2007-05-13 Thread Vivian Meazza

Hi,

This morning's update of fg-cvs fails to compile under MSVC8 with the
following error:

error C2491: 'terminate' : definition of dllimport function not allowed
Flightgear-cvs\source\src\Main\bootstrap.cxx147

The attached patch fixes it (but it may not be the best way of doing it).

Vivian 


bootstrap.diff
Description: Binary data
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Latest OT/OSG/SG/FG unusable

2007-05-13 Thread Nick Warne
On Saturday 12 May 2007 22:01:42 Matthias Boerner wrote:
 Hallo Georg,

 I have done a fresh checkout of OSG, PLIB, SimGear and FlightGear
 today at 3 pm in the afternoon. Everything compiled without a problem.
 But I don't realize a drop in frame rates. But in contrast to my last
 checkout of 24th April I get about 10-20 frames more. So I think
 everything is fine with OSG.

 Regards

 Matthias

Well, on this evidence I just done a completed update on OSG/SG/FG... and back 
I go to 5 fps at KSFO.

Also now I do not see 'sea' outside the tile I have - here is the scene at 
FHAW (Ascention Is. right in the middle of the Atlantic).  You will also see 
I have 13 fps here in the PC - before I used to get upward of 43 FPS here.

http://www.nick.ukfsn.org/fg/issue.png

Something is wrong.

Nick


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] John's position on combat simulation;

2007-05-13 Thread Detlef Faber
Am Sonntag, den 13.05.2007, 07:02 + schrieb Martin Spott:
 John Wojnaroski wrote:
  Martin Spott wrote:
 
  Sorry, John, this has nothing to do with selective morality - as you
  allege. After reading these lines I'd say you have severe difficulties
  telling the difference between flying and shooting/killing.
  
  Ooo,  I don't think so.
  
  To make understanding it easier: Many/most of the old but also the
  modern warbirds are fascinating aircraft from a technical as well as
  from an aviatic point of view - no doubt. Yet this is significantly
  different from actually performing the shooting at some other aircraft
  or dropping bombs.

  
  Ahhh, so the basis for acrobatic manuevering was...and the reason 
  you need to put 9G's on your body is.  Your first point is quite 
  correct, but again fly them to you heart's content and DON'T complain if 
  others wish to do the same and simulate combat. That is all I am saying,
 
 Yes, I _do_ domplain !
 
 Here's your missing link: The simple reason that an aircraft was
 originally _built_ for shooting and dropping bombs doesn't justify to
 really _perform_ this action in a simulation as well. You're taking a
 way too simple route here,
 
sorry Martin, but you didn't give any argument other than you don't like
it. It is perfectly alright and a valuable input to express your
concerns and judging from the reactions I think everybody on this list
is ready to respect them.

Democracy allows each individual the right to pursue his/hers interests
as long as nobody is harmed. Same with the GPL. If James likes to
implment combat he does nothing wrong.

It is simply unfair and by no law, or terms of the GPL justified to
flame at him just because you don't like what he wants (or better:
thinks about) to do.

Regards

Detlef

   Martin.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-13 Thread Jon S. Berndt
 I think that was investigated a few months ago. JSBSim FDM took only a
 couple percent of the CPU, or course depending on your hardware
 and what you were drawing.

 BIll

I didn't see that one. In any case, I just made a 200 second scripted test
run, which took 42 seconds on my 2 GHz clunker. The execution time took
about 2% of the actual corresponding real time. Also, I ran JSBSim
standalone in realtime mode, and it took about 2% of the CPU. Or, so I
thought. I watched the CPU usage when I wasn't running JSBSim, and it was no
different: still 2% of the CPU was being used. :-)

Jon


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Latest OT/OSG/SG/FG unusable

2007-05-13 Thread gh.robin
On Sat 12 May 2007 23:01, Matthias Boerner wrote:
 Hallo Georg,

 I have done a fresh checkout of OSG, PLIB, SimGear and FlightGear
 today at 3 pm in the afternoon. Everything compiled without a problem.
 But I don't realize a drop in frame rates. But in contrast to my last
 checkout of 24th April I get about 10-20 frames more. So I think
 everything is fine with OSG.

 Regards

 Matthias



Hello Mathias,

Your 10-20 frames more, seems to me very poor regarding the comparison, 
i get from 10 to 15 fps with the recent one and a now with that old one i 
recover from 60 to 85, which is a huge difference.

BTW: with the same FG version built PRE_OSG_PLIB_20061029  
i get a lower frame rate 
from 55 to 75 with every options activated (3D clouds, Shadoww, .)
Theses differences indicate that FG OSG could be equivalent to FG PLIB, 
probably better.
That dramatic loss of performance with the lasts OSG version, is not normal.


Regards
-- 
Gérard


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] New Architecture for Flightgear

2007-05-13 Thread Jim Campbell
Hi,
Some discussions have already taken place on JSBsim devel mailing list 
regards communication between modules of flightgear.
My thoughts are that flightgear divides naturally into four major 
sub-system modules:
a) FDM (jsbsim is already standalone)
b) cockpit input and output (ie joysticks/pedals/throttles/switches etc 
and displays/lights etc)
c) external view (with all the graphics rendering for 
forward/back/sides etc)
d) motion system (probably not many users!)
The main issue is inter-processor communication between modules ie 
between modules multi-threaded on multi-processor computers,between 
modules in processes on same computer,between modules in processes on 
networked computers.
I have been looking at the idea of using some database containing the 
property lists which would be read and updated asynchronously by the 
various modules at whatever frame rate is suitable for the module (not 
necessarily its internal framerate)
My first thought was LDAP, although using a directory service as a 
database is often frowned upon!
I am familiar with OpenLDAP and it looks like an LDAP schema can be 
derived fairly easily from the property list or better still from the 
XML schema (maybe programs exist to do this already?).
There may be problems with data rates etc so maybe it will need MySQL 
or somesuch but that seems an overkill for the functionality needed.
The advantages of the database are that proprietry (ie FG/jsbsim) 
protocols are not needed as standards already exist and multi-process 
(many to one and one to many) synchronisation etc is already built in 
to the database API. Also there are the search facilities and other 
directory and database functions that can be made use of.
Also I have had a look at native XML databases and although it is nice 
to be able to write/read and search directly in XML, if they are based 
on JAVA (such as Opensource Xindice), they are pitifully slow compared 
with what is required (there is some interesting work published on the 
Web comparing native XML data base with MySQL with all its problems of 
representing the XML data).

We can experiment on various communication ideas without restructuring 
flightgear by simply running three instance (forget motion system for 
now!). One instance running FDM with no panel display and no outside 
view, second instance running no FDM or view and only panel, and third 
instance running no FDM or panel and only outside view.

An advantage of this modularisation and inter-process communication is 
that as flightgear is multi-platform we can select the optimum platform 
for each module even utilising RTOS where needed or maybe specialist 
graphics engines.

If anyone has any comments and other ideas etc I would be very 
interested.

cheers
Jim



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] New Architecture for Flightgear

2007-05-13 Thread Martin Spott
Hi Jim,

Jim Campbell wrote:

 Some discussions have already taken place on JSBsim devel mailing list 
 regards communication between modules of flightgear.

Indeed, the idea of cutting FlightGear into modules is not a new one
and has been floating around way before this nice new arcitecture
paper came up that everybody takes as a reference.

Using some sort of networked database is a nice start and definitely
honours the idea of portability - yet I don't see such thing that is
capable of handling data at a rate that meets the requirements of
FlightGear. OpenLDAP as well as MySQL are very bad at handling a high
rate of concurrent read/write requests - they miss the target by a huge
distance, they both are faaar to complex (even MySQL :-)  for such a
task.

Personally I think some thing like distributed shared memory might fill
the gap. I've been doing some literature research on this topic several
years ago, the idea looks pretty promising and different OpenSource
implementations already have been around by that time - but I would not
like to be the one to debug such a tricky beast   :-)

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] New Architecture for Flightgear

2007-05-13 Thread Harald JOHNSEN
Martin Spott wrote:

Hi Jim,

Jim Campbell wrote:

  

Some discussions have already taken place on JSBsim devel mailing list 
regards communication between modules of flightgear.



Indeed, the idea of cutting FlightGear into modules is not a new one
and has been floating around way before this nice new arcitecture
paper came up that everybody takes as a reference.

Using some sort of networked database is a nice start and definitely
honours the idea of portability - yet I don't see such thing that is
capable of handling data at a rate that meets the requirements of
FlightGear. OpenLDAP as well as MySQL are very bad at handling a high
rate of concurrent read/write requests - they miss the target by a huge
distance, they both are faaar to complex (even MySQL :-)  for such a
task.

Personally I think some thing like distributed shared memory might fill
the gap. I've been doing some literature research on this topic several
years ago, the idea looks pretty promising and different OpenSource
implementations already have been around by that time - but I would not
like to be the one to debug such a tricky beast   :-)

Cheers,
   Martin.
  

One should not forget that FG has allready some networking capacity. 
This alone has allready allowed ppl to split fdm and rendering on 
several machines. Perhaps there is something to reuse here.

Harald.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Latest OT/OSG/SG/FG unusable

2007-05-13 Thread Matthias Boerner
Hello Gerard,

 Hello Mathias,

 Your 10-20 frames more, seems to me very poor regarding the
 comparison, i get from 10 to 15 fps with the recent one and a now
 with that old one i recover from 60 to 85, which is a huge
 difference.

I get an performance increase from about 80/90 fps to 100/110 fps. My 
average frame rate is about 90/100.

So in my environment which is probably not that different to yours 
(except hardware) I do not have a performace decrease with OSG that 
some people and you described here.
I don't use any fancy optimization parameters: -march=k8 -O2 -pipe, 
that's all.

What is your environment, and what are your compile parameters?

Regards

Matthias





-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] John's position on combat simulation;

2007-05-13 Thread John Wojnaroski
Martin Spott wrote:

John Wojnaroski wrote:
  

Martin Spott wrote:



  

Sorry, John, this has nothing to do with selective morality - as you
allege. After reading these lines I'd say you have severe difficulties
telling the difference between flying and shooting/killing.

  

Ooo,  I don't think so.



To make understanding it easier: Many/most of the old but also the
modern warbirds are fascinating aircraft from a technical as well as
  

from an aviatic point of view - no doubt. Yet this is significantly


different from actually performing the shooting at some other aircraft
or dropping bombs.
 

  

Ahhh, so the basis for acrobatic manuevering was...and the reason 
you need to put 9G's on your body is.  Your first point is quite 
correct, but again fly them to you heart's content and DON'T complain if 
others wish to do the same and simulate combat. That is all I am saying,



Yes, I _do_ domplain !

Here's your missing link: The simple reason that an aircraft was
originally _built_ for shooting and dropping bombs doesn't justify to
really _perform_ this action in a simulation as well. You're taking a
way too simple route here,

  

I'm a simple guy...

Hmmm,  that seems a bit illogical.  Without the primary function or 
purpose for combat the aircraft would not have been built in the first 
place.  So if you feel that combat action, real or simulated, are not 
justified, don't build the vehicle or item that fulfills it's prime 
function in the first instance.  In other words, why build something if 
you don't intend to use it for the purpose it was built.

John W.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] New Architecture for Flightgear

2007-05-13 Thread Robin van Steenbergen
Harald JOHNSEN schreef:
 Martin Spott wrote:

   
 Hi Jim,

 Jim Campbell wrote:

  

 
 Some discussions have already taken place on JSBsim devel mailing list 
 regards communication between modules of flightgear.


   
 Indeed, the idea of cutting FlightGear into modules is not a new one
 and has been floating around way before this nice new arcitecture
 paper came up that everybody takes as a reference.

 Using some sort of networked database is a nice start and definitely
 honours the idea of portability - yet I don't see such thing that is
 capable of handling data at a rate that meets the requirements of
 FlightGear. OpenLDAP as well as MySQL are very bad at handling a high
 rate of concurrent read/write requests - they miss the target by a huge
 distance, they both are faaar to complex (even MySQL :-)  for such a
 task.

 Personally I think some thing like distributed shared memory might fill
 the gap. I've been doing some literature research on this topic several
 years ago, the idea looks pretty promising and different OpenSource
 implementations already have been around by that time - but I would not
 like to be the one to debug such a tricky beast   :-)

 Cheers,
  Martin.
  

 
 One should not forget that FG has allready some networking capacity. 
 This alone has allready allowed ppl to split fdm and rendering on 
 several machines. Perhaps there is something to reuse here.

 Harald.
   
Real-world flight simulation systems, as used in flight training 
devices, have been using this tactic for decades.

A flight simulator as supplied by a commercial producer of training 
devices, has been split into a set of large functional blocks, each of 
them consisting of different modules:

* Flight dynamics block -- consists of a set of systems that handle 
everything related to the aircraft's aerodynamic profile and the forces 
acting upon it. It does know nothing about scenery (aside from terrain 
elevation data, to detect ground movement), and knows nothing about the 
aircraft's systems. The only thing it knows about the aircraft is 
basically a 3D model with aerodynamic description, the position of the 
A/C's control surfaces and other extensions (landing gear, doors, 
spoilers), and the user-induced forces on the aircraft (engine thrust). 
It does a very good job at handling flight dynamics, and is fitted with 
a heavy CPU. Mathematical power is more important here than memory.

* Systems block -- keeps track of everything happening inside the 
aircraft. From the engines to the air conditioning, everything that 
can't be connected as real avionics is simulated inside this unit. Most 
of the aircraft-specific descriptions are found here.

* Visual system -- The visual system only needs to receive position and 
orientation data, and possibly the first and second derivative of it. 
 From that it renders the (usually multichannel) outside view for 
projection onto the simulator's front screen. All of the scenery data is 
stored here.

These three functional big blocks communicate over a high-speed network. 
Mostly, the units are built in dual-redundant sets to cope with eventual 
failure.

Most of the cockpit systems in a real simulator consist of real 
avionics. ARINC buses connect the real aircraft avionics (like the FMC, 
RMU's, and most of the display systems) to the simulator as if they 
connected to an actual aircraft. The simulator's systems block takes the 
place of the aircraft's IRS, GNS, ADC, VOR and other navigation systems.

Splitting up FlightGear into multiple functional units is something I'm 
really voting for. Especially, when you use a well-defined interface for 
every module. That way you can create a plugin-driven system that is 
easily extended upon, and could easily be split up physically using 
multiple machines across a network. I'm more into developing glass 
cockpits myself, but I'm also interested in creating a complete 
full-mission flight simulation suite. Especially since that would 
attract commercial funders (aviation industry companies like CAE, 
FlightSafety and Boeing) and possibly achieve FAA certification.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] New Architecture for Flightgear

2007-05-13 Thread Martin Spott
Harald JOHNSEN wrote:

 One should not forget that FG has allready some networking capacity. 
 This alone has allready allowed ppl to split fdm and rendering on 
 several machines. Perhaps there is something to reuse here.

Well, we've been driving two 'external' displays on last years LinuxTag
exhibition using the 'generic' protocol. We were surprised to encounter
a significant performance hit on the master machine serving two clients
at 20 Hz. Throttling the thing down to 10 Hz made the whole setup
flyable again.
Yet this might look different if such master does nothing but FDM
output via network,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Latest OT/OSG/SG/FG unusable

2007-05-13 Thread gh.robin
On Sun 13 May 2007 17:41, Matthias Boerner wrote:
 Hello Gerard,

  Hello Mathias,
 
  Your 10-20 frames more, seems to me very poor regarding the
  comparison, i get from 10 to 15 fps with the recent one and a now
  with that old one i recover from 60 to 85, which is a huge
  difference.

 I get an performance increase from about 80/90 fps to 100/110 fps. My
 average frame rate is about 90/100.

 So in my environment which is probably not that different to yours
 (except hardware) I do not have a performace decrease with OSG that
 some people and you described here.
 I don't use any fancy optimization parameters: -march=k8 -O2 -pipe,
 that's all.

 What is your environment, and what are your compile parameters?

 Regards

 Matthias

Hello Mathias,

Right, your FPS has nothing to do with mine


The Computer which run FG is:

With LInux fedora core 5

Cpu AMD Athlon XP3200  (32 bit)
Memory 3 GB DDR  dual channel  3200

GPU NVIDIA 7800GS 500MZ Memory 512 Mo  DDR3  700MZ
AGP 8
driver 1.0-9755


SG built with
./configure --prefix=

FG built with
/configure --prefix= --with-simgear= --enable-sdl

FG-OSG run with 
--geometry=1800x1440
--bpp=32
--enable-real-weather-fetch
--timeofday=afternoon
--prop:/sim/startup/save-on-exit=false

Nothing else significant

BTW: no dual cpu, no PCI-e graphic card

Regards

-- 
Gérard


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] AN-225 3D-cockpit

2007-05-13 Thread adrian . sprick
Hi all!

Im currently working on a 3D-Cockpit for the Antonov AN-225;
if someone else does, please tell me for not having two people work on
the same thing!
I havent found much information about the AN-225 (or the 124),
except photos, so please let me know, when you have some knowledge
about this a/c (Electrics, Brakes, Hydraulics, speaking Russian,
whatever). My Russian got a little rusty (cough...), and so I cant
identify all instruments on the cockpit-photos. Would be nice if
someone could help, but theres no hurry

Ciao,

Adrian

Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  39,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-13 Thread Ampere K. Hardraade
On Sunday 13 May 2007 03:52, Harald JOHNSEN wrote:
 Now if the server is doing the
 FDM computation it's obvious that there is no need to do that 120 times
 per second because the data can not be send at that rate.
 How many loops does the mp server need to do per second ? 10 ? 20 ? At
 that frequency you could handle 100 clients with no problems.

 Harald.

As far as I know, the FDM frequency controls the fidelity of the simulation.  
It has no relationship with the I/O frequency.

Since the FDM takes so little CPU power, the amount clients that can be served 
should be dependent on the bandwidth.

Ampere

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] New Architecture for Flightgear

2007-05-13 Thread Robin
Martin Spott schreef:
 Well, we've been driving two 'external' displays on last years LinuxTag
 exhibition using the 'generic' protocol. We were surprised to encounter
 a significant performance hit on the master machine serving two clients
 at 20 Hz. Throttling the thing down to 10 Hz made the whole setup
 flyable again.
 Yet this might look different if such master does nothing but FDM
 output via network,

   Martin.
   
Keep in mind that the Generic protocol is one of the most inefficient 
for real-time data communication, as it communicates via plain text. If 
you want something that goes over 100Hz, you need to think of a binary 
system. For an FDM connecting to a visual system it's basically nothing 
more than 18 floating point values (x,y,z, rotation xyz and first and 
second order derivatives for smoothing) resulting in a 72-byte data 
packet, which is doable.

To put it into perspective, the same 18 values would take up at least 
200 bytes (characters), not counting newlines and frame separators, as 
each floating point would need at least 10 characters to be represented 
at least a bit accurately, and still you have to cope with international 
issues (comma vs. decimal point) when you're using the generic protocol. 
Plus a terrible loss in resolution as the max. resolution for a plain 
text channel can be at most to the 10th decimal place (at least, in 
standard format) where a double floating point can carry much more 
accurate data.

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] New Architecture for Flightgear

2007-05-13 Thread Stefan Seifert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martin Spott wrote:

 Personally I think some thing like distributed shared memory might fill
 the gap. I've been doing some literature research on this topic several
 years ago, the idea looks pretty promising and different OpenSource
 implementations already have been around by that time - but I would not
 like to be the one to debug such a tricky beast   :-)

A pretty easy and fast implementation could be based on one of the new
single threaded, event based HTTP servers like LigHTTPD. The property
tree would map nicely to URL space, the data could be stored in memory,
by a simple custom handler module.

This would take care of concurrency issues and be very fast as HTTP is a
simple protocol. Server push could take care of listeners, but obviously
tied properties would have to go. But the latter have been a source of
problems for modelers anyway, since one cannot attach listeners to them.
I wonder if their performance benefit is really worth the hassle.

And it would provide HTTP access to properties for free, allowing to
dump the correspondent code in FG :)

Nine
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGR0Od1QuEJQQMVrgRCBplAKCHzW5h+6LiVWcefbdSFp6YxeN+sACfbHsz
f3TynbUWntduxHFugDOwa4s=
=Xw/z
-END PGP SIGNATURE-

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Latest OT/OSG/SG/FG unusable

2007-05-13 Thread Matthias Boerner
Hello Gerard,

 The Computer which run FG is:

 With LInux fedora core 5
ok, I have fedora core 6


 Cpu AMD Athlon XP3200  (32 bit)
 Memory 3 GB DDR  dual channel  3200
CPU AMD Athlon 64 4000+ (no dual core)
Memory 2 GB ECC DDR dual channel 3200


 GPU NVIDIA 7800GS 500MZ Memory 512 Mo  DDR3  700MZ
 AGP 8
 driver 1.0-9755
GPU NVIDIA 6600GT 500 MHz Memory 128 DDR3 1000MHz
PCI-E
driver 1.0-9755


 SG built with
 ./configure --prefix=
Same with me, except all FG stuff is in my home directory, so I have to 
use --with-plib, etc.


 FG built with
 /configure --prefix= --with-simgear= --enable-sdl

I do not use SDL because freeglut is fixed

 FG-OSG run with
 --geometry=1800x1440
--geometry=1280x1024

 --bpp=32
dito

 --enable-real-weather-fetch
 --timeofday=afternoon
 --prop:/sim/startup/save-on-exit=false
I don't use this ones...

But:
--enable-game-mode

and the already mentioned compiler flags.

Regards

Matthias

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-13 Thread Vivian Meazza
Harald

 Sent: 13 May 2007 18:19
 To: FlightGear developers discussions
 Subject: Re: [Flightgear-devel] More ideas on dogfighting
 
 
 Ampere K. Hardraade wrote:
 
 On Sunday 13 May 2007 03:52, Harald JOHNSEN wrote:
   
 
 Now if the server is doing the
 FDM computation it's obvious that there is no need to do that 120 
 times per second because the data can not be send at that rate. How 
 many loops does the mp server need to do per second ? 10 ? 20 ? At 
 that frequency you could handle 100 clients with no problems.
 
 Harald.
 
 
 
 As far as I know, the FDM frequency controls the fidelity of the 
 simulation.
 It has no relationship with the I/O frequency.
   
 
 If the server does the fdm 100 times per second and send the data 10 
 times per second it's like if the client was running the fdm 
 at 10 hz. 
 That's why I said it's not needed to run the fdm at more than 10 hz 
 (those numbers are just examples).
 
 Since the FDM takes so little CPU power, the amount clients 
 that can be 
 served
 should be dependent on the bandwidth.
 

I suppose that we run the fdm at 120Hz for a good reason: why could we
suddenly accept 10Hz?

Vivian


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FW: [vtp] Looking for partner in

2007-05-13 Thread Heiko Schulz
Reminds me of Terragen- they use the same heightmap
and he renderig looks the same!


--- Martin Spott [EMAIL PROTECTED] schrieb:

 Norman Vine wrote:
   -Original Message-
   From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On 
 
   http://www.howardzzh.com/research/terrain
 
 Hey, apparently these guys had quite some fun  :-)
 The results are impressive !
 
   Martin.
 -- 
  Unix _IS_ user friendly - it's just selective about
 who its friends are !

--
 

-
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2
 express and take
 control of your XML. No limits. Just data. Click to
 get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/flightgear-devel
 



  Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s 
mit dem neuen Yahoo! Mail. www.yahoo.de/mail

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Weekly CVS Changelog Summary: FlightGear data

2007-05-13 Thread Stefan Seifert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Curtis Olson wrote:
 
 Would you be willing to hack/fixup/modify the original script so that it
 produces correct results directly?  The issue is that it combines files
 with the same cvs log message and commit date, but sometimes a commit spans
 a couple seconds and so the files can get split up into subgroups.

Finally found the time to have a look at the script and hack it :)
New sort-cvs-logs.pl is attached and seems to work for me. I hope I
didn't overlook something.

If any problems occur or you'd like to have something changed, just ell
me :)

Nine
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGR1b71QuEJQQMVrgRCO12AJsHkwJCI5+Wv0fPsZPjUZPJMjbolACeI3B7
9Axl+kImVyLSwtNeTfw2NmM=
=hVkt
-END PGP SIGNATURE-


sort-cvs-logs.pl
Description: Perl program


sort-cvs-logs.pl.sig
Description: PGP signature
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-13 Thread Stefan Seifert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Harald JOHNSEN wrote:

 That was in the situation where the MP server does the fdm computation 
 for the client. The 10 hz comes from a ping of 100 ms between the client 
 and the server.

I think FDM caculations have to be at a certain rate, independent of how
fast the calculated values are consumed because each iteration is based
on it's predecessor and the Hz determines the minimum length of any event.

For example if an aircraft flies through an air hole for 1/100 of a
second, the impact is far less than when the smallest quantity of time
is 1/10 of a second.

But I don't really know anything about FDMs on the other hand :)

Nine
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGR1h+1QuEJQQMVrgRCOg3AJ0eFpfybrtgaJupCKmxl6mfT0GXuQCdE0th
7u0/8ZH/sp59MOHcBsROyJQ=
=BDaI
-END PGP SIGNATURE-

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FW: [vtp] Looking for partner in

2007-05-13 Thread Ampere K. Hardraade
On Sunday 13 May 2007 13:52, Martin Spott wrote:
 Norman Vine wrote:
   -Original Message-
   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
  
   http://www.howardzzh.com/research/terrain

 Hey, apparently these guys had quite some fun  :-)
 The results are impressive !

   Martin.

We could always simulate topographical features via spherical harmonics. :P

Ampere

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-13 Thread Ampere K. Hardraade
On Sunday 13 May 2007 15:05, Maik Justus wrote:
 Maybe it is easier, that the clients run their own fdm and the
 combat-server makes a test of the actual performance of the client
 against stored values, which could be generated by a script (maximum
 acceleration, turn rate, speed for several sets of orientation/speed).

 Maik

That wouldn't solve the problem of syncing clients' positions across the 
entire network.



Ampere

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-13 Thread Martin Spott
Maik Justus wrote:

 Does anyone know, which latency between control input and visible 
 reaction is acceptable (== unnoticeable)?

I'm unable to cite a qualified source from the top of my head. Yet I
remember different people talking and/or writing about not to exceed a
delay of approx. 50 ms. As a rough guess think of which FlightGear
frame rate you consider as 'flyable' - I'd say 20 fps is the absolute
minimum of what people call 'smooth',

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-13 Thread Maik Justus
Hi Ampere,

yes,

but solving this dogfight-only problem by bringing in a general problem 
for every flightgear user is much worse.

Maik


Ampere K. Hardraade schrieb am 13.05.2007 21:25:
 On Sunday 13 May 2007 15:05, Maik Justus wrote:
   
 Maybe it is easier, that the clients run their own fdm and the
 combat-server makes a test of the actual performance of the client
 against stored values, which could be generated by a script (maximum
 acceleration, turn rate, speed for several sets of orientation/speed).

 Maik
 

 That wouldn't solve the problem of syncing clients' positions across the 
 entire network.



 Ampere
   


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-13 Thread Bill Galbraith
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On 
 Behalf Of Martin Spott
 Sent: Sunday, May 13, 2007 4:17 PM
 To: flightgear-devel@lists.sourceforge.net
 Subject: Re: [Flightgear-devel] More ideas on dogfighting
 
 Maik Justus wrote:
 
  Does anyone know, which latency between control input and visible 
  reaction is acceptable (== unnoticeable)?
 
 I'm unable to cite a qualified source from the top of my 
 head. Yet I remember different people talking and/or writing 
 about not to exceed a delay of approx. 50 ms. As a rough 
 guess think of which FlightGear frame rate you consider as 
 'flyable' - I'd say 20 fps is the absolute minimum of what 
 people call 'smooth',
 

Measuring between a control input and the first response to instruments,
visual, or motion base.

FAA Advisory Circular AC 120-40B, for Aiplane Simulator Qualification says:

Relative responses of the motion system,
visual system, and cockpit instruments shall be
coupled closely to provide integrated sensory
cues 6 These systems shall respond to abrupt
pitch, roll and yaw inputs at the pilot's position
within 150/300 milliseconds of the time, but not
before the time, when the airplane would respond
under the same conditions. Visual scene changes
from steady state disturbance shall occur within
the system dynamic response limit of
150/300 milliseconds but not before the resultant
motion onset. 

[Note: 300 msec for Level A and B, 150 msec for level C and D]

FAA AC 120-45A, for Flight Training Devices, requires 150 msec for level 7,
and 300 for levels 1 through 6.

Military standards are usually 150 msec, sometimes lowered to 100 msec.

There is also a requirement that the three outputs be within 50 msecs of
each other, and visual can't respond before the motion. 

Bill


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] Soliciting newsletter ideas

2007-05-13 Thread Jon S. Berndt
Well, once again I am working on a new newsletter for JSBSim. I've taken a
sort of rest from that, as I am also producing another newsletter (see:
www.aiaa-houston.org/horizons). If anyone has any suggestions on topics I am
all ears. Better yet, if anyone can contribute, that's really very _much_
appreciated.

Best regards,

Jon


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-13 Thread Jonathan Wagner
Maik,

These are not dogfight-only problems.  These are multiplayer problems 
which currently are not addressed well in the current multiplayer 
implementation.  On the public servers with high latency, multiplayer 
flight can be choppy as a plane in your view magically disappears from 
your right view and reappears in your left view.  Also, syncing 
positions across the entire network allows proper collision detection.  
I know it is fun to fly the Rascal or some small plane inside another 
player's Boeing 737, but it is not realistic which seems to be the focus 
of zeal in this project. 

Having proper collision detection would allow realistic damage and 
system failures.  In the example above, if the Rascal were to fly into 
an aileron on the left wing it is likely that the Rascal would be 
destroyed, but the 737 would only lose operation of the left aileron.  
The 737 would not be in a desirable situation, but with sufficient 
piloting skills would be able to land safely anyway.

Just some thoughts,

Jonathan Wagner


Maik Justus wrote:
 Hi Ampere,

 yes,

 but solving this dogfight-only problem by bringing in a general problem 
 for every flightgear user is much worse.

 Maik


 Ampere K. Hardraade schrieb am 13.05.2007 21:25:
   
 On Sunday 13 May 2007 15:05, Maik Justus wrote:
   
 
 Maybe it is easier, that the clients run their own fdm and the
 combat-server makes a test of the actual performance of the client
 against stored values, which could be generated by a script (maximum
 acceleration, turn rate, speed for several sets of orientation/speed).

 Maik
 
   
 That wouldn't solve the problem of syncing clients' positions across the 
 entire network.



 Ampere
   
 


 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel

   


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-13 Thread Bill Galbraith
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On 
 Behalf Of Martin Spott
 Sent: Sunday, May 13, 2007 5:01 PM
 To: flightgear-devel@lists.sourceforge.net
 Subject: Re: [Flightgear-devel] More ideas on dogfighting
 
 Hi Bill,
 
 Bill Galbraith wrote:
 
  Relative responses of the motion system, visual system, 
 and cockpit 
  instruments shall be coupled closely to provide integrated sensory 
  cues 6 These systems shall respond to abrupt pitch, roll and yaw 
  inputs at the pilot's position within 150/300 milliseconds of the 
  time, but not before the time, when the airplane would 
 respond under 
  the same conditions. [...]
 
 Uh, 300 ms response time looks pretty bad to me at a first 
 glance. They already include the time which the 'real' 
 aircraft would need to respond aerodynamically - right ?
 
 Personally I'd go crazy in the real Cessna if it would take 
 me one third of a second until the beast starts !! responding 
 to a control movement - this would turn almost every landing 
 at gusty crosswind into a really difficult situation 
 

Sorry. I wasn't specific enough (and figured SOMEONE would question what I
wrote). That delay is not counting the aircraft aerodynamic delay. In the
simulation world, we set up special code for this testing, so that it takes
the same path through normal code, it just bypasses the aerodynamic effects
and recognizes the step control input, and generates a step output on the
three output systems (instruments, visual, motion).

Typically, one would also do a throughput analysis, if you have separate
computers for various functions (you do on real sims). You look at the
control input happened at t=0, but ooo, it just missed a data transfer from
the control loading computer to the host, so you have to wait for the next
one to come along. The host recognizes the input and generates the output,
and sends the signal out to the I/O, visual, and motion computers. Those
transfers are usually initiated by the host at the end of a frame, but if
they aren't you have to play the game of ooo, I just missed that data
transfer, I have to wait for the next one to happen, all the time adding up
the delays. If the theorical delay is too great, you don't have a good
architecure for something (data transfer, host execution, whatever) and may
have to make some changes. Your theorical value should be less than the 150
or 300 msec, since this is the worst that it's allowed to be. You won't
always hit the theorical number that you calculate, but hopefully you are
less some of the time.

Bill


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] More ideas on dogfighting

2007-05-13 Thread Gene Buckle
  coupled closely to provide integrated sensory
  cues 6 These systems shall respond to abrupt
  pitch, roll and yaw inputs at the pilot's position
  within 150/300 milliseconds of the time, but not
  before the time, when the airplane would respond
  under the same conditions. [...]

 Uh, 300 ms response time looks pretty bad to me at a first glance. They
 already include the time which the 'real' aircraft would need to
 respond aerodynamically - right ?

 Personally I'd go crazy in the real Cessna if it would take me one
 third of a second until the beast starts !! responding to a control
 movement - this would turn almost every landing at gusty crosswind into
 a really difficult situation 


Martin, the 300ms figure is really only applicable to a Level A simulator
which is basically equivalent to a cockpit procedures trainer with no
visuals.

BTW, sorry for being such a jerk.  You were able to (likely
unintentionally) wind me up like a clock-spring connected to a gas
turbine. :)

g.
 -- I'm not crazy, I'm plausibly off-nominal!

Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel