Hi,

I'm back, actually already for a few weeks ...

Latest cvs plib, SimGear, FlightGear, fgfsbase ...

I now choose the debug default of plib, and
metakit, namely 'Debug Multithreaded', thus must
'remember' to check this setting is consistant for
each msvc build ...

1. JSBSim - Tie()
>> Microsoft Products."  My guess is that we have something related to the
>> "Function Template Parameter" problem.
> Although the errors I got correspond to "Confused by Template Forward
> Declaration".
> Bernie
... and lots more read ...

I can see nothing 'wrong' in the construct in
FGPropertyManager.h that should give 'pause'
to a compiler ... as other compilers have proved.

You will note msvc does NOT require any such
'agressively additional casting' when used in the
5 parameters case -

That is, from say FGAircraft.cpp -
This FAILS ????
  PropertyManager->Tie("metrics/eyepoint-z-ft", this,3,
                       &FGAircraft::GetXYZep);

While this WORKS ???? Why ???
  PropertyManager->Tie("metrics/alpha-max-deg", this,
                       &FGAircraft::GetAlphaCLMax,
                       &FGAircraft::SetAlphaCLMax,
                       true);

The difference is in the 'casting' of the (*getter).

In the second the getter is 'double get()' style, while
the 'other' getter is 'double get(index)' style, and the
compiler misses the connection ...

Off the topic ... IMHO some reduction would come
from not using 'string & name', rather using say -
    Tie (char * name, bool *pointer, bool useDefault = true)
as this avoids the allocation / de-allocation memory
functions, and thus can be 'inline' with pointers in hand :-)

Anyway, i hope we find an elegant solution to this soon ...
for all our 'cross compile' efforts ...

2. Hud.cxx

I 'always' drop this block of code into this module -
#ifndef  HUD_IN_XML
//#include <Include/general.hxx>
    {
       char buf[32];
       sprintf(buf, "%d", (int)general.get_frame_rate() );
       HUD_TextList.add( fgText(540, 10, buf, 0) );
    }
#endif   // #ifndef  HUD_IN_XML

You will notice that this is ONLY until such a
display is not in the 'default' HUD display ...

3. FlightGear.dsp

Had to delete a few, and add a few, as per usual
from a 'snapshot' cvs update ... And as mentioned
why not move to 'Debug multithreaded' in some
anticipation/hope this might help ...

but i have compiled and run it also as 'Debug
single-threaded', and it appears about the
same ... so ...

unfortunately at this time have only had a chance
to run 'magic' fdm - no panel - hud up - most
worked as 'expected' ... great viewing fun ...

I read somehwhere earlier some mention of
something like 'fgfs has lost altitude' ...
In my case the console tty output shows a
strange ELEVATION - or different anyway -
...
Panel visible = 0
Loading deferred texture
Updating light parameters.
  Sun angle = 38.1953
  ambient = 0.35  diffuse = 1  sky = 1
Finally initializing fdm
Start common FDM init
...initializing position...
...initializing ground elevation to -0.000311142ft...
...initializing sea-level radius...
 lat = 37.6135 alt = -0.000311142
...initializing velocities...
...initializing Euler angles...
End common FDM init
Starting audio playback for: wind
load() base = D:\FGFS\FlightGear\Scenery
... etc ...

This means half of the display is BELOW the
earth - real cool - except i expect to see
coloured layers of  'rock', or something ...
just kidding, i think :=))

but a 'white out' of the lower half of the
window threw me for a moment ... and if
you take on speed while in this condition -
talk about 'terra-forming' - flying thru rock!!!

Also have noted a few changes of, like -
  318  !>     if ( fgGetString("/sim/startup/units") == "meters") {
to
  318  <!     if ( !strcmp("/sim/startup/units", "meters")) {
but am i missing something here? To compare 2
different strings will always be non-zero ...

Shouldn't these be
  318  <!     if ( !strcmp( fgGetString("/sim/startup/units"), "meters"))
{

Hope this helps ...

Thanks again to all for a great sim ...

Rgds,
Geoff.



_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to