I have added a fledgling replay system that records flight data and control
positions during the flight.
I have added an internal command called "replay" which will trigger a replay
of the entire saved flight data set. This could be bound to a keyboard or
menu command, in fact this entire module is screaming for someone to build
a gui to control playback speed, amount of playback, etc.
This is the initial version so there are kinks that still need to be worked
out, please be patient.
scene management code and organizing it within simgear. My strategy is
to identify the code I want to move, and break it's direct flightgear
dependencies. Then it will be free to move over into the simgear package.
- Moved some property specific code into simgear/props/
- Split out the condition code from fgfs/src/Main/fg_props and put it
in it's own source file in simgear/props/
- Created a scene subdirectory for scenery, model, and material property
related code.
- Moved location.[ch]xx into simgear/scene/model/
- The location and condition code had dependencies on flightgear's global
state (all the globals-> stuff, the flightgear property tree, etc.) SimGear
code can't depend on it so that data has to be passed as parameters to the
functions/methods/constructors.
- This need to pass data as function parameters had a dramatic cascading
effect throughout the FlightGear code.
input bindings. They will work only with the latest CVS; otherwise,
./configure will disable them. There is a new command, 'script',
which takes a single argument, also called 'script', containing PSL
code (currently PSL requires a main() function).
Erik Hofman has written some more elaborate code for triggering PSL
code from drop-down menus and scheduling events; I will look at
integrating that next.
- Removed some old cruft.
- Removed some support for older versions of automake which technically was
correct, but caused the newer automakes to squawk warnings during an
initial sanity check (which isn't done very intelligently.)
NOTE: this fix is technically not correct for older version of automake.
These older version use the variable "INCLUDES" internally and could have
them already set to an important value. That is why we were appending
our values to them. However, newer versions of automake don't set this
value themselves so it is an error to append to a non-existant variable.
We seem to "get away" with overwriting the value on older versions of
automake, but if you have problems, consider upgrading to at least
automake-1.5.
Removed configuration option --with-new-environment and
FG_NEW_ENVIRONMENT macro.
Added configuration option --with-weathercm and FG_WEATHERCM macro.
FGEnvironment is now the default; use --with-weathercm to get the old
weather.
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.
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.
Description:
This update includes the new viewer interface as proposed by David M. and
a first pass at cleaning up the viewer/view manager code by Jim W.
Note that I have dropped Main/viewer_lookat.?xx and Main/viewer_rph.?xx and
modified the Makefile.am accordingly.
Detail of work:
Overall:
The code reads a little easier. There are still some unnecessary bits in
there and I'd like to supplement the comments in the viewer.hxx with a tiny
bit on each interface group and what the groupings mean (similar but briefer
than what you emailed me the other day). I tried not to mess up the style,
but there is an occasional inconsistency. In general I wouldn't call it done
(especially since there's no tower yet! :)), but I'd like to get this out
there so others can comment, and test.
In Viewer:
The interface as you suggested has been implemented. Basically everything
seems to work as it did visually. There is no difference that I can see in
performance, although some things might be a tiny bit faster.
I've merged the lookat and rph (pilot view) code into the recalc for the
viewer. There is still some redundancy between the two, but a lot has been
removed. In some cases I've taken some code that we'd likely want to inline
anyway and left it in there in duplicate. You'll see that the code for both
looks a little cleaner. I need to take a closer look at the rotations in
particular. I've cleaned up a little there, but I suspect more can be done
to streamline this.
The external declaration to the Quat_mat in mouse.cxx has been removed. IMHO
the quat doesn't serve any intrinsic purpose in mouse.cxx, but I'm not about
to rip it out. It would seem that there more conventional ways to get
spherical data that are just as fast. In any case all the viewer was pulling
from the quat matrix was the pitch value so I modified mouse.cxx to output to
our pitchOffset input and that works fine.
I've changed the native values to degrees from radians where appropriate.
This required a conversion from degrees to radians in a couple modules that
access the interface. Perhaps we should add interface calls that do the
conversion, e.g. a getHeadingOffset_rad() to go along with the
getHeadingOffset_deg().
On the view_offset (now headingOffset) thing there are two entry points
because of the ability to instantly switch views or to scroll to a new view
angle (by hitting the numeric keys for example). This leaves an anomaly in
the interface which should be resolved by adding "goal" settings to the
interface, e.g. a setGoalHeadingOffset_deg(), setGoalPitchOffset_deg(), etc.
Other than these two issues, the next step here will be to look at some
further optimizations, and to write support code for a tower view. That
should be fairly simple at this point. I was considering creating a
"simulated tower view" or "pedestrian view" that defaulted to a position off
to the right of whereever the plane is at the moment you switch to the tower
view. This could be a fall back when we don't have an actual tower location
at hand (as would be the case with rural airports).
ViewManager:
Basically all I did here was neaten things up by ripping out excess crap and
made it compatible as is with the new interface.
The result is that viewmanager is now ready to be developed. The two
preexisting views are still hardcoded into the view manager. The next step
would be to design configuration xml (eg /sim/view[x]/config/blahblah) that
could be used to set up as many views as we want. If we want to take the easy
way out, we might want to insist that view[0] be a pilot-view and have
viewmanager check for that.
- automake-1.4 sets default values for INCLUDES which we can't
overwrite.
- automake-1.5 renames this to DEFAULT_INCLUDES and leaves INCLUDES
open for the developer to use.
Thus for automake-1.4 we are forced to 'append' to INCLUDES and in
automake-1.5 we can just set the value to whatever we like.
Unfortunately, the behaviors of the two versions are mutually
incompatible.
The solution I am committing now works for both versions but
automake-1.5 generates a lot of spurious warning messages that are
annoying, but not fatal.
(src/Input). So far, FGInput replaces most of src/Main/keyboard.cxx
(I've left a tiny stub); in the very near future, it will also take
over control of the joystick, mouse (Norm permitting), and panel
instrument interactions, so that there is a single mechanism for
configuring all input devices.
The new format should be (close to) self-explanatory by looking at the
new base-package file keyboard.xml, which is now included by
preferences.xml (I'll do the same thing for the joystick when I have a
chance). I have not managed to move all keybindings into this file
yet, but I've made a good start. I'm including Tony in the recipient
list so that he can see how bindings can use an external XML file.
This patch also adds support for multiple bindings for a single key,
special keys (i.e. keypad and function keys), and key modifiers
(shift/alt/ctrl); special keys use the PUI convention of adding 256 to
the Glut key code.
Unfortunately, everything comes with a price; in this case, I have not
yet found a general mechanism for the old (hard-coded) modal bindings,
which behaved differently depending on the autopilot state (i.e. left
rudder or move AP heading left); with my patches, this functionality
disappears, but you can still adjust the autopilot using the panel or
the GUI input dialogs.
He writes:
Here are the final changes to add threads to the tile loading. All the
thread related code is in the new FGTileLoader class.
./configure.in
./acconfig.h
Added --with-threads option and corresponding ENABLE_THREADS
definition. The default is no threads.
./src/Scenery/tilemgr
Removed load_queue and associated references. This has been replaced by
a new class FGTileLoader in FGNewCache.
Made the global variable global_tile_cache a member.
schedule_needed(): removed global_tile_cache.exists() tests since
sched_tile() effectively repeats the test.
initialize_queue(): removed code that loads tiles since this is now
performed by FGTileLoader.
update(): ditto
./src/Scenery/newcache
Added new class FGTileLoader to manage tile queuing and loading.
tile_map typedefs are private.
exists() is a const member function.
fill_in(): deleted
load_tile(): added.
./src/Scenery/FGTileLoader
The new threaded tile loader. Maintains a queue of tiles waiting to be
loaded and an array of one or more threads to load the tiles. Currently
only a single thread is created. The queue is guarded by a mutex to
synchronize access. A condition variable signals the thread when the
queue is non-empty.
CLO: I made a few tweaks to address a couple issues, hopefully what we
have is solid, but now we kick it out to the general public to see. :-)
