> > Windows 98 SE ... stock standard stuff.
> Tell me about the display car dyou have, how much memory there?
Must search for the 'book' that came with the machine for the actual
'card'
but i remember something like AGP <something>. The driver is the Intel
810e Chipset Graphics Driver PV 2.1 (as Alex mentioned) ... I guess the
on card mem. would be minimal, maybe 2 or 4 MB max. - Must find
that book! This 'french' Unika pc case is very difficult to open and look
...
I run at 1024x768 at 16-bit colour on my Hyundai P910 19 ins monitor.
Of course I only run FGFS in its 600x400 window. Expanding that
window to full screen really does SLOW things down, but I can get
quite reasonable 'flying' as set up ... I am modestly happy ... :-)(
> ... Really, the FDM takes a very small amount
> of computation time. Most of the time is spent in the display
> routines, IIRC.
That is agreed. But i was making a point about how 'rocking' the ac
when the engine/mags are off (and 0 wind) cause the 'display' to be
re-done - that is a small change issued by the FDM can drastically
increase the 'display' ... as it SHOULD. But when we are OFF, and
not 'paused' ... who/what is moving the ac???
As mentioned, and it happened again, after i enter a 'p' key, FGFS
does 'pause', BUT i can never seem to get it started again ... In fact
it seems to go somewhere 'very busy', and I have to use drastic
measures (like a Ctrl+C in the CONSOLE screen) to exit ... Must
try to investigate this more ...
> > ... avoid the 'slower micro-coded on chip' FPU
> > instructions as much as possible to ...
I loved the two approaches on this -
(a) a question posed -
> Do you have some particular examples?
Yes, any time you write double * double, or
(b) some type of agreement, at least in principal -
> The maths that are done for magic are *much* simpler and thus require
> much less CPU. So it's expected to have the best "performance".
ok. I am still of the opinion that floating point maths can take lots of
p-clocks
to complete, so we can see a 'good' example of what i mean in the
'magic' code = try to avoid minimal change
snippet
if ( speed > SG_EPSILON )
{
geo_direct_wgs_84 ( get_Altitude(),
get_Latitude() * SGD_RADIANS_TO_DEGREES,
get_Longitude() * SGD_RADIANS_TO_DEGREES,
get_Psi() * SGD_RADIANS_TO_DEGREES,
dist,
&lat2, &lon2, &az2 );
_set_Longitude( lon2 * SGD_DEGREES_TO_RADIANS );
_set_Latitude( lat2 * SGD_DEGREES_TO_RADIANS );
}
end snippet
SG_EPSILON is defined as -
D:\fg79\SimGear\simgear\constants.h(121):#define SG_EPSILON 0.0000001
Now maybe your FDM code is already liberally sprinkled with such checks,
and if the 'result' is not 'significant' then you do not continue
calculate more
and then change global things by less than 1 millionth of something ...
then
this is good.
And that is all i am talking about. FGFS is the co-operation of many
'components', and each should do its best to not hog the cpu resource, or
cpu(s) for that matter ...
Or in this case, cause another component to hog the resources by altering
the physical world location minimally ...
It is perhaps strange that I do *NOT* think the output of the diagnostic
file is part of the problem at all. Writing quick snippets of formatted
text
to disk can be quite fast, and it does not involve the 'read' cache which
I think is the important io bottleneck ...
One construction i do hate seeing in a routine that is called frequently -
at many times per second - is something like -
setRPM(node->getDoubleValue("rpm"));
or worse ... excuse me Curt for jumping on main.cxx here as an
example ...
for ( i = 0; i < multi_loop * fgGetInt("/sim/speed-up"); ++i ) {
// run something
foo->update( 1 );
}
FGSteam::update( multi_loop * fgGetInt("/sim/speed-up") );
If only the coder would 'trace' such action thru once or twice,
and see the 'massive' overheads involved ... That is using -
D:\fg79\FlightGear\src\Main\fg_props.hxx(151):inline int fgGetInt (const
string &name, int defaultValue = 0)
and the like ...
Each time such a text string is used to get a node value, there has
to be an allocation of string structure memory, and a copy of the
'static' data into a string structure, which involves a re-allocation
since the string structure memory was initiated with a buffer length
of 1, then off to fgGetInt( &_s_s ) with a string ref -
And after the multiply is completed the string tidier will release this
memory ... for EACH AND EVERY ONE of the for loops.
And then again, after the for, another string allocation will be done,
the 'database' searched with the string reference, and when the
multiply is completed, again this memory has to be released.
i. such strings, and there are 100's throughout FGFS, should be
one time allocated during an init()
foo::init( double dt )
sSimSpdUp = "/sim/speed-up";
Then at least, in the main loop -
multi_loop * fgGetInt( sSimSpdUp )
at least avoids a memory allocation, re-allocation and release
on each and every iteration ...
or even
ii. Do it once, then use the result in each place ...
int iloop = multi_loop * fgGetInt("/sim/speed-up");
for ( i = 0; i < iloop; ++i ) {
// run something
foo->update( 1 );
}
FGSteam::update( iloop );
Please remember here i am only refering to things like an
update() which can be called hundreds of times per second.
I can see the 'coder' in some way understood this and thus
has the copious comments - in fg_prop.hxx - of
* This method is convenient but inefficient. It should be used
* infrequently (i.e. for initializing, loading, saving, etc.),
* NOT IN THE MAIN LOOP. If you need to get a value frequently,
* it is better to look up the node itself using fgGetNode and then
* use the node's getIntValue() method, to avoid the lookup overhead.
note: my capitals!
Of course I 'personally' would really prefer to see something real simple
like -
int iloop = globals.fg_sim_speed_up;
where the intel 'code' generated to get the sim speed-up value is one
line -
mov dword ptr [ebp-16],
dword ptr [globals[fg_sim_speed_up]];
Fast, convenient, efficient, etc, etc, ...
But i can read there is 'real love' for the current string properties tree
tied to a value type look-up database rather than my quick simple
'memory address' idea. So forget it ...
Actually talking about this took me back to the days when you
could 'poke' a MS FS (DOS) memory address to cause change in
the simulator flight ... or 'peek' an address to add a new display
item ...
Of course it is all back to what i try to run. For example FGFS,
using JSBSim, flies much smoother if - after i set the mags and start
the engine - i remove the panel and only use the HUD. There is less
'update' on the HUD's few line of display compared to the 'painted'
panel ... so the fdm, scenery, moon, etc updates are done smoothly,
and they all combined leave a few cpu/memory cycles to spare ... and
i can see fps in the 20's + =
:-)) the simulator FLIES :-))
To repeat - FGFS is great. Each of the FDM's and other components
play a part to give me great pleasure in working/playing with it ...
Keep up the GREAT work ...
And i promise to keep pressuring my 'financial manager' - read wife -
into UPGRADING my antiquated pc ... to some 'hot' system where
i get to 'choose' the video system rather than getting just what is in the
box.
I must get around to trying each of the fdm's with each ac, etc, etc ...
lots more yet untried ... like my 'balloon' fdm still goes nowhere at
present? I can not seem to 'apply' power/throttle/lift ...
Back to 'coding' and 'flying', or 'flying' and 'coding' ... :-))
rgds,
Geoff.
PS: sprintf vs fprintf - IMHO it would always be better
complete the record, including any line terminator using
sprintf, like sprintf(cp, "val=%f\n", dblVal);
then printf(cp); or cout << cp;.
While it seems the cout stream has slightly more overhead, they are
essentially the same ... whether re-directed to a disk file or not ...
thus i also see the VERY CONVENIENT -
cout << "val=" << dblVa << endl;
as simply another way to write 'sprintf' with not very much more
overhead ...
PPS: FGFS does *not* use DirectX. It uses OpenGL.
hmm, agreed. sorry ...
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
