Here are the Boost-less FGEventMgr updates I promised.
Removed Boost dependencies from FGEventMgr.
Removed Boost configure check.
fgMethodCallback now handles const member functions.
I've successfully tested these changes with gcc and msvc.
Synced to CVS 19:36 EDT 2002-04-10 (after this evenings JSMsim and Base
package updates).
Description:
Added FGLocation class which is new home for calculating matrix rotations.
Viewer can now be configured to access rotations created by the model rather
than repeating the same calculations again.
Changed model initialization for the time being so that its location data is
available for the viewer (currently required by other subsystems). At some
point we can move this back to fg_init along with the viewer initialization.
Seperated the update from the draw function in the model code. The viewer
code needs the same matrix data, and moving the update portion at this time
does not increase the number of matrix math iterations.
Moved the model draw so that it always appears "in front" of lights and clouds.
Reogranized viewer update routine for using the FGLocation class and
simplified some more tasks. The routine is fairly easy to follow now, with
the steps ordered and spelled out in comments.
Viewmgr only updates the current (visible) view now, with the exception of an
old reference to "chase view" that will be corrected in forthcoming changes.
Also will be doing some work on the viewmgr outputs.
Model is now clears the z-buffer in all modes. This will be changed with the
next viewmgr update. The only side effect is that models always disappear
when over 5km distant from the eye point (can't really see them anyway:-)).
Other than a flag to indicate "internal" view I don't anticipate the
configuration interface for viewmgr/views will be changed a lot for now. It
is close to done. The next viewmgr update will however rework the outputs so
may change location.
This code will run with the previous version of preferences.xml, but will run
faster with the newer version. I am attaching a preferences.xml that should
not be commited before the code. All the changes are in the /sim/view section
and should show a simpler view configuration that references model locations.
Note that I've added a 2nd tower view in "lookfrom" mode for illustration
purposes. You can look around using the mouse. You may want to remove that or
comment it out.
Synced to CVS 19:36 EDT 2002-04-10 (after this evenings JSMsim and Base
package updates).
Description:
Added FGLocation class which is new home for calculating matrix rotations.
Viewer can now be configured to access rotations created by the model rather
than repeating the same calculations again.
Changed model initialization for the time being so that its location data is
available for the viewer (currently required by other subsystems). At some
point we can move this back to fg_init along with the viewer initialization.
Seperated the update from the draw function in the model code. The viewer
code needs the same matrix data, and moving the update portion at this time
does not increase the number of matrix math iterations.
Moved the model draw so that it always appears "in front" of lights and clouds.
Reogranized viewer update routine for using the FGLocation class and
simplified some more tasks. The routine is fairly easy to follow now, with
the steps ordered and spelled out in comments.
Viewmgr only updates the current (visible) view now, with the exception of an
old reference to "chase view" that will be corrected in forthcoming changes.
Also will be doing some work on the viewmgr outputs.
Model is now clears the z-buffer in all modes. This will be changed with the
next viewmgr update. The only side effect is that models always disappear
when over 5km distant from the eye point (can't really see them anyway:-)).
Other than a flag to indicate "internal" view I don't anticipate the
configuration interface for viewmgr/views will be changed a lot for now. It
is close to done. The next viewmgr update will however rework the outputs so
you can expect that the data that viewmgr is writing to the property tree
may change location.
This code will run with the previous version of preferences.xml, but will run
faster with the newer version. I am attaching a preferences.xml that should
not be commited before the code. All the changes are in the /sim/view section
and should show a simpler view configuration that references model locations.
Note that I've added a 2nd tower view in "lookfrom" mode for illustration
purposes. You can look around using the mouse. You may want to remove that or
comment it out.
- Throttle control position
- Mixture control position
- Magneto/starter control position
Added support for receiving:
- Engine state (off, cranking, running)
- RPM
- Fuel Flow
- EGT
- Oil Temp
- Oil Pressure
- Fuel tank quantity
- Weight on wheels
I made these modifications to correct the problem of getter functions
returning pointers to local variables. Those variables are no longer
locals and become static. One should be aware that it kills reentrancy
!
This patch moves built-in Class (for now only mag-ribbon) into special
directory as you have written it in TODO: in comments of this class in
panel_io.cxx. IMHO it is good idea. I want to play with built-in
classes and OpenGC and this will be useful.
Made a couple more adjustments, now the function builds the
transformation matrix (sans the translation) directly from the five
inputs. After realizing that it may be necessary for the new location
class to publish a world up vector, comments were added indicating
which values constitute world up.
Minor patches to initial tower view code. Added calculation for "tower" at
any airport, placed a couple fractions of a degree off the center. Moved the
farplane from 100m to 5km so that "lookfrom" mode can see the model. 5km is
still in a reasonable range for a depth buffer. Note that looking at a model
anything but a small distance will cause some problems on older cards.
Temporarily changed viewer to always report elevation/lon/lat of the aircraft
in order to avoid a problem with the ground trim getting recalculated when
tower and aircraft are on different tiles.
radiostack.cxx, fg_init.cxx and main.cxx. If these changes are accepted
then you can remove Time/event.[ch]xx and Include/fg_callback.hxx from
the repository.
Tower View and viewer config is in place. Note that the interface is
still in a state of flux. A couple of the config items (namely the
offsets) are still using the old settings. The tower is hard coded
into the base package for a position off the starting runway at KSFO
and is probably not in the right place for there even. Looks pretty
cool though! Tower View is the third view. If you aren't at KSFO
you'll just see blank space in view 3. It's looking through the earth or
something like that :-). Important note: zoom in with a few
hits of the "x" key to see the plane better in tower view.
This should fix it. The problem wasn't the rotations but a difference in
the translations. Note that this fix also puts the wheels back on top of the
pavement when in external view.
Changed the steering gain from +/-0.1 to +/-1.0, so that the steering
angle for the nosewheel (when present) is the same as the rudder
deflection angle. That's probably not exactly right, but it's much
better than we had before -- you can now steer the plane on the ground
reasonably during taxiing.
case logging is disabled). This way, when people specify a
non-existant aircraft or have an error in a custom XML file, they'll
get an error report, at least.
system. A chap from Germany called Alexander Kappes (cc'd) got
in touch with me a few weeks ago and has written the start of
Approach control. At the moment tuning in to a valid approach
frequency (Dortmund or East Midlands) should result in vectors to
a spot about 3 miles from the active runway, and a telling off if you
stray too far from the correct course, in the console window. He
seems to know what he's doing so expect this to improve rapidly!!
I've added a rudimentry AI manager and a hardwired Cessna at
KEMT on the runway - I'll remove it before the next release if I don't
have it flying by then. There seems to be an issue with framerate
which drops alarmingly when looking at it - I've a feeling that I've
possibly created several Cessnas on top of each other, but am not
sure.
ability to run a nonlinear model with flaps. The files ls_model.c and
uiuc_aero.c were changed since we had some functions with the same
name. The name changes doesn't affect the code, it just makes it a
little easier to read. There are changes in LaRCsim.cxx so UIUC
models have engine sound. Could you send me an email when you receive
this and/or when the changes make it to the CVS? Thanks.
Also I noticed you have some outdated files that are no longer used in
the UIUCModel directory. They are uiuc_initializemaps1.cpp,
uiuc_initializemaps2.cpp, uiuc_initializemaps3.cpp, and
uiuc_initializemaps4.cpp
Rob
and specific animation types are derived from it. This change makes
the code much easier to read, maintain, and extend.
Added a 'translate' animation type for a scaled, 3D linear translation
(such as a sliding throttle knob).
Renamed the 'offset' property to 'offset-m' or 'offset-deg' as
appropriate; ditto for 'min' and 'max' properties.
MSVC fix from Bernie Bright:
You can keep the enum private if you add the following declarations
immediately afterwards:
struct mouse;
friend struct mouse;
It seems that MSVC doesn't grant the nested mouse decl. any special
access privileges to its surrounding class.
Clear frame buffer and render model after rest of 3D scene. This has a
small frame rate cost (YMV). But who thought 3D cockpit would be cheap?
If anyone has a better idea, have at it!
Just did some more careful testing and I see little or no frame rate loss
with the depth buffer clear. Also you can change the near plane to 0.1
and get rid of the "sunroof" (so I don't have to make up another set of
patches.
My last patch fixed the initialization problem only for the main branch, but
ignored the _MWERKS_ branch.
- merged the branches, only the loop head needs different treatment;
- don't access n.type before it is initialized (valgrind complaint)
- created a constructor; the operator>> wouldn't have initialized all
variables in case of a broken default.nav.gz entry, so we would have
got a mixture of the broken one and the previous one; in case of
the first entry, that would have made nice random values ... ;-)
- move the automatic FGNav variable into the loop, so that the gets
cleanly constructed for every database entry.
- commented out the frequency min/max exploration, which isn't used at all
- updated the commented out debug output statements, which were simply
copied over from the nav* files, but never adapted (I needed them :-)
