2000-02-15 03:30:01 +00:00
|
|
|
|
// panel.cxx - default, 2D single-engine prop instrument panel
|
1998-11-11 00:19:27 +00:00
|
|
|
|
//
|
2000-02-15 03:30:01 +00:00
|
|
|
|
// Written by David Megginson, started January 2000.
|
1998-11-11 00:19:27 +00:00
|
|
|
|
//
|
2000-02-15 03:30:01 +00:00
|
|
|
|
// This program is free software; you can redistribute it and/or
|
|
|
|
|
// modify it under the terms of the GNU General Public License as
|
|
|
|
|
// published by the Free Software Foundation; either version 2 of the
|
|
|
|
|
// License, or (at your option) any later version.
|
1999-12-23 17:37:18 +00:00
|
|
|
|
//
|
2000-02-15 03:30:01 +00:00
|
|
|
|
// This program is distributed in the hope that it will be useful, but
|
|
|
|
|
// WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
|
// General Public License for more details.
|
|
|
|
|
//
|
|
|
|
|
// You should have received a copy of the GNU General Public License
|
|
|
|
|
// along with this program; if not, write to the Free Software
|
|
|
|
|
// Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
1998-11-11 00:19:27 +00:00
|
|
|
|
//
|
2000-02-15 03:30:01 +00:00
|
|
|
|
// $Id$
|
1998-06-27 16:47:53 +00:00
|
|
|
|
|
|
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
|
# include <config.h>
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef HAVE_WINDOWS_H
|
|
|
|
|
# include <windows.h>
|
|
|
|
|
#endif
|
|
|
|
|
|
2002-02-05 15:57:46 +00:00
|
|
|
|
#include <stdio.h> // sprintf
|
2000-02-15 03:30:01 +00:00
|
|
|
|
#include <string.h>
|
1999-03-08 21:56:08 +00:00
|
|
|
|
|
2000-02-15 03:30:01 +00:00
|
|
|
|
#include <plib/ssg.h>
|
2000-02-21 22:00:24 +00:00
|
|
|
|
#include <plib/fnt.h>
|
1998-06-27 16:47:53 +00:00
|
|
|
|
|
2000-02-16 23:01:03 +00:00
|
|
|
|
#include <simgear/debug/logstream.hxx>
|
2001-03-25 14:20:12 +00:00
|
|
|
|
#include <simgear/misc/sg_path.hxx>
|
2001-01-11 22:44:18 +00:00
|
|
|
|
|
The following changes were made to flightgear-0.7.5 code to implement the follow
ing features:
a) ADA Flight model - ADA.cxx, ADA.hxx, flight.hxx
b) Fighter a/c HUD - flight.hxx, hud.hxx, hud.cxx, cockpit.cxx, hud_ladr.c
xx, hud_card.cxx
c) 3-window display - options.hxx, options.cxx, viewer.cxx
d) Moving objects (ship) - main.cxx
e) Patches - main.cxx
ADA.cxx, ADA.hxx
--------------------------
Interface to the external ADA flight dynamics package.
flight.hxx
----------
Included prototypes for accepting additional data fron the External flight
model for fighter aircraft HUD
Hud.hxx
-------
Included prototypes for accepting additional data for fighter HUD from Exernal F
light model.
Defined FIGHTER_HUD pre-processor directive to enable compilation of fighter hud
code.
hud.cxx, cockpit.cxx, hud_ladr.cxx, hud_card.cxx
---------------------------------------
Included code to initialise additional reticles/text for fighter HUD which is co
nditionally
compiled if FIGHTER_HUD is defined.
options.hxx
-----------
Added window_offset, and function to retrieve its value for 3 windows
options.cxx
-----------
Changed few options to suit ADA/CEF projection system/screens and checks for win
dow offset.
views.cxx
---------
Added code to retrieve view offset for window.
Main.cxx
--------
Added code to load and move an aircraft carrier.
Patch to enable clouds from command line until Curtis fixes it. By default cloud
s are disabled.
2000-10-19 19:46:13 +00:00
|
|
|
|
#include <Main/globals.hxx>
|
2001-01-11 22:44:18 +00:00
|
|
|
|
#include <Main/fg_props.hxx>
|
2001-07-22 19:51:16 +00:00
|
|
|
|
#include <Main/viewmgr.hxx>
|
1999-05-13 02:10:52 +00:00
|
|
|
|
#include <Objects/texload.h>
|
2000-10-25 22:59:02 +00:00
|
|
|
|
#include <Time/light.hxx>
|
1998-06-27 16:47:53 +00:00
|
|
|
|
|
2000-02-21 22:00:24 +00:00
|
|
|
|
#include "hud.hxx"
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
#include "panel.hxx"
|
2000-02-21 22:00:24 +00:00
|
|
|
|
|
2001-06-20 20:50:49 +00:00
|
|
|
|
#define WIN_X 0
|
|
|
|
|
#define WIN_Y 0
|
|
|
|
|
#define WIN_W 1024
|
|
|
|
|
#define WIN_H 768
|
|
|
|
|
|
2001-10-26 22:58:28 +00:00
|
|
|
|
#if defined( NONE ) && defined( _MSC_VER )
|
2001-10-24 21:25:11 +00:00
|
|
|
|
# pragma message( "A sloppy coder has defined NONE as a macro!!!" )
|
|
|
|
|
# undef NONE
|
|
|
|
|
#elif defined( NONE )
|
|
|
|
|
# pragma warn A sloppy coder has defined NONE as a macro!!!
|
|
|
|
|
# undef NONE
|
2001-08-03 00:17:58 +00:00
|
|
|
|
#endif
|
|
|
|
|
|
2001-06-20 20:50:49 +00:00
|
|
|
|
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
// Local functions.
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Calculate the aspect adjustment for the panel.
|
|
|
|
|
*/
|
2001-06-26 18:23:07 +00:00
|
|
|
|
static float
|
2001-06-20 20:50:49 +00:00
|
|
|
|
get_aspect_adjust (int xsize, int ysize)
|
|
|
|
|
{
|
|
|
|
|
float ideal_aspect = float(WIN_W) / float(WIN_H);
|
|
|
|
|
float real_aspect = float(xsize) / float(ysize);
|
|
|
|
|
return (real_aspect / ideal_aspect);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
// Global functions.
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
2000-02-21 22:00:24 +00:00
|
|
|
|
|
2000-10-18 21:19:30 +00:00
|
|
|
|
bool
|
|
|
|
|
fgPanelVisible ()
|
|
|
|
|
{
|
2002-03-06 13:51:05 +00:00
|
|
|
|
if(current_panel == 0)
|
2002-03-04 19:59:22 +00:00
|
|
|
|
return false;
|
2002-03-06 13:51:05 +00:00
|
|
|
|
if(current_panel->getVisibility() == 0)
|
2002-03-04 19:59:22 +00:00
|
|
|
|
return false;
|
2002-03-06 13:51:05 +00:00
|
|
|
|
if(globals->get_viewmgr()->get_current() != 0)
|
2002-03-04 19:59:22 +00:00
|
|
|
|
return false;
|
Major viewer-code overhaul from Jim Wilson:
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.
2002-03-20 17:43:28 +00:00
|
|
|
|
if(globals->get_current_view()->getHeadingOffset_deg() * SGD_DEGREES_TO_RADIANS != 0 &&
|
2002-03-06 13:51:05 +00:00
|
|
|
|
!fgGetBool("/sim/virtual-cockpit"))
|
2002-03-04 19:59:22 +00:00
|
|
|
|
return false;
|
2002-03-06 13:51:05 +00:00
|
|
|
|
return true;
|
2000-10-18 21:19:30 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2000-04-27 22:45:48 +00:00
|
|
|
|
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
// Implementation of FGTextureManager.
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
|
2000-09-06 00:07:48 +00:00
|
|
|
|
map<string,ssgTexture *> FGTextureManager::_textureMap;
|
2000-04-27 22:45:48 +00:00
|
|
|
|
|
|
|
|
|
ssgTexture *
|
2000-09-06 00:07:48 +00:00
|
|
|
|
FGTextureManager::createTexture (const string &relativePath)
|
2000-04-27 22:45:48 +00:00
|
|
|
|
{
|
2000-09-06 00:07:48 +00:00
|
|
|
|
ssgTexture * texture = _textureMap[relativePath];
|
2000-04-27 22:45:48 +00:00
|
|
|
|
if (texture == 0) {
|
2001-06-01 17:55:49 +00:00
|
|
|
|
SG_LOG( SG_COCKPIT, SG_DEBUG,
|
|
|
|
|
"Texture " << relativePath << " does not yet exist" );
|
2001-03-25 14:20:12 +00:00
|
|
|
|
SGPath tpath(globals->get_fg_root());
|
2000-04-27 22:45:48 +00:00
|
|
|
|
tpath.append(relativePath);
|
|
|
|
|
texture = new ssgTexture((char *)tpath.c_str(), false, false);
|
|
|
|
|
_textureMap[relativePath] = texture;
|
2000-09-06 00:07:48 +00:00
|
|
|
|
if (_textureMap[relativePath] == 0)
|
2001-06-01 17:55:49 +00:00
|
|
|
|
SG_LOG( SG_COCKPIT, SG_ALERT, "Texture *still* doesn't exist" );
|
|
|
|
|
SG_LOG( SG_COCKPIT, SG_DEBUG, "Created texture " << relativePath
|
|
|
|
|
<< " handle=" << texture->getHandle() );
|
2000-04-27 22:45:48 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return texture;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2000-09-22 17:20:56 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
// Implementation of FGCropped Texture.
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FGCroppedTexture::FGCroppedTexture ()
|
|
|
|
|
: _path(""), _texture(0),
|
|
|
|
|
_minX(0.0), _minY(0.0), _maxX(1.0), _maxY(1.0)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FGCroppedTexture::FGCroppedTexture (const string &path,
|
|
|
|
|
float minX, float minY,
|
|
|
|
|
float maxX, float maxY)
|
|
|
|
|
: _path(path), _texture(0),
|
|
|
|
|
_minX(minX), _minY(minY), _maxX(maxX), _maxY(maxY)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FGCroppedTexture::~FGCroppedTexture ()
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ssgTexture *
|
|
|
|
|
FGCroppedTexture::getTexture ()
|
|
|
|
|
{
|
|
|
|
|
if (_texture == 0) {
|
|
|
|
|
_texture = FGTextureManager::createTexture(_path);
|
|
|
|
|
}
|
|
|
|
|
return _texture;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
1999-12-23 17:37:18 +00:00
|
|
|
|
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
// Implementation of FGPanel.
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
FGPanel * current_panel = NULL;
|
2000-09-30 03:35:38 +00:00
|
|
|
|
static fntRenderer text_renderer;
|
2002-02-19 23:54:17 +00:00
|
|
|
|
static fntTexFont *default_font;
|
|
|
|
|
static fntTexFont *led_font;
|
1999-12-23 17:37:18 +00:00
|
|
|
|
|
David Megginson writes:
I have a scrollable panel working (it didn't take long in the end). A
panel can now be much wider or higher than the available area, and the
user can scroll around using [Shift]F5, [Shift]F6, [Shift]F7, and
[Shift]F8. The user can also scroll the panel down to get a bigger
external view. Mouse clicks seem still to be working correctly.
To set the panel's (virtual) height and width, use the panel file's /w
and /h properties in a panel XML file; to set the initial x- and y-
offsets (untested), use the panel file's /x-offset and /y-offset
properties; to set the initial height of the external view (untested
and optional), use the panel file's /view-height property. Note that
none of these show up in the regular FGFS property manager.
Unfortunately, these patches will not affect your initialization
problems with the property manager -- I'm having a hard time tracking
them down because I cannot reproduce them.
I have also made some patches to main.cxx and views.cxx to do two
things:
1. Expand or shrink the external view as the panel moves up and down.
2. Set the window ratio correctly, so that we don't get an oval sun
and flat clouds when the panel is visible (the problem before was
integer division, so I added casts).
Unfortunately, the window ratio is not set properly at start-up --
there are too many dependencies, and I haven't figured that part out
yet. As soon as you hide and redisplay the panel or move it
vertically (i.e. force fgReshape to be called), you'll see the correct
ratio.
2000-10-06 21:16:01 +00:00
|
|
|
|
/**
|
|
|
|
|
* Constructor.
|
|
|
|
|
*/
|
2001-06-20 20:50:49 +00:00
|
|
|
|
FGPanel::FGPanel ()
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
: _mouseDown(false),
|
|
|
|
|
_mouseInstrument(0),
|
2001-06-20 20:50:49 +00:00
|
|
|
|
_width(WIN_W), _height(int(WIN_H * 0.5768 + 1)),
|
|
|
|
|
_x_offset(0), _y_offset(0), _view_height(int(WIN_H * 0.4232)),
|
2001-10-05 20:26:21 +00:00
|
|
|
|
_jitter(0.0),
|
2001-06-20 20:50:49 +00:00
|
|
|
|
_xsize_node(fgGetNode("/sim/startup/xsize", true)),
|
|
|
|
|
_ysize_node(fgGetNode("/sim/startup/ysize", true))
|
2000-02-15 03:30:01 +00:00
|
|
|
|
{
|
2000-10-18 21:19:30 +00:00
|
|
|
|
setVisibility(fgPanelVisible());
|
2000-04-27 22:45:48 +00:00
|
|
|
|
}
|
|
|
|
|
|
David Megginson writes:
I have a scrollable panel working (it didn't take long in the end). A
panel can now be much wider or higher than the available area, and the
user can scroll around using [Shift]F5, [Shift]F6, [Shift]F7, and
[Shift]F8. The user can also scroll the panel down to get a bigger
external view. Mouse clicks seem still to be working correctly.
To set the panel's (virtual) height and width, use the panel file's /w
and /h properties in a panel XML file; to set the initial x- and y-
offsets (untested), use the panel file's /x-offset and /y-offset
properties; to set the initial height of the external view (untested
and optional), use the panel file's /view-height property. Note that
none of these show up in the regular FGFS property manager.
Unfortunately, these patches will not affect your initialization
problems with the property manager -- I'm having a hard time tracking
them down because I cannot reproduce them.
I have also made some patches to main.cxx and views.cxx to do two
things:
1. Expand or shrink the external view as the panel moves up and down.
2. Set the window ratio correctly, so that we don't get an oval sun
and flat clouds when the panel is visible (the problem before was
integer division, so I added casts).
Unfortunately, the window ratio is not set properly at start-up --
there are too many dependencies, and I haven't figured that part out
yet. As soon as you hide and redisplay the panel or move it
vertically (i.e. force fgReshape to be called), you'll see the correct
ratio.
2000-10-06 21:16:01 +00:00
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Destructor.
|
|
|
|
|
*/
|
2000-04-27 22:45:48 +00:00
|
|
|
|
FGPanel::~FGPanel ()
|
|
|
|
|
{
|
2000-09-08 20:47:18 +00:00
|
|
|
|
for (instrument_list_type::iterator it = _instruments.begin();
|
|
|
|
|
it != _instruments.end();
|
|
|
|
|
it++) {
|
|
|
|
|
delete *it;
|
|
|
|
|
*it = 0;
|
2000-02-15 03:30:01 +00:00
|
|
|
|
}
|
2000-04-27 22:45:48 +00:00
|
|
|
|
}
|
|
|
|
|
|
David Megginson writes:
I have a scrollable panel working (it didn't take long in the end). A
panel can now be much wider or higher than the available area, and the
user can scroll around using [Shift]F5, [Shift]F6, [Shift]F7, and
[Shift]F8. The user can also scroll the panel down to get a bigger
external view. Mouse clicks seem still to be working correctly.
To set the panel's (virtual) height and width, use the panel file's /w
and /h properties in a panel XML file; to set the initial x- and y-
offsets (untested), use the panel file's /x-offset and /y-offset
properties; to set the initial height of the external view (untested
and optional), use the panel file's /view-height property. Note that
none of these show up in the regular FGFS property manager.
Unfortunately, these patches will not affect your initialization
problems with the property manager -- I'm having a hard time tracking
them down because I cannot reproduce them.
I have also made some patches to main.cxx and views.cxx to do two
things:
1. Expand or shrink the external view as the panel moves up and down.
2. Set the window ratio correctly, so that we don't get an oval sun
and flat clouds when the panel is visible (the problem before was
integer division, so I added casts).
Unfortunately, the window ratio is not set properly at start-up --
there are too many dependencies, and I haven't figured that part out
yet. As soon as you hide and redisplay the panel or move it
vertically (i.e. force fgReshape to be called), you'll see the correct
ratio.
2000-10-06 21:16:01 +00:00
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Add an instrument to the panel.
|
|
|
|
|
*/
|
2000-04-27 22:45:48 +00:00
|
|
|
|
void
|
|
|
|
|
FGPanel::addInstrument (FGPanelInstrument * instrument)
|
|
|
|
|
{
|
|
|
|
|
_instruments.push_back(instrument);
|
|
|
|
|
}
|
|
|
|
|
|
David Megginson writes:
I have a scrollable panel working (it didn't take long in the end). A
panel can now be much wider or higher than the available area, and the
user can scroll around using [Shift]F5, [Shift]F6, [Shift]F7, and
[Shift]F8. The user can also scroll the panel down to get a bigger
external view. Mouse clicks seem still to be working correctly.
To set the panel's (virtual) height and width, use the panel file's /w
and /h properties in a panel XML file; to set the initial x- and y-
offsets (untested), use the panel file's /x-offset and /y-offset
properties; to set the initial height of the external view (untested
and optional), use the panel file's /view-height property. Note that
none of these show up in the regular FGFS property manager.
Unfortunately, these patches will not affect your initialization
problems with the property manager -- I'm having a hard time tracking
them down because I cannot reproduce them.
I have also made some patches to main.cxx and views.cxx to do two
things:
1. Expand or shrink the external view as the panel moves up and down.
2. Set the window ratio correctly, so that we don't get an oval sun
and flat clouds when the panel is visible (the problem before was
integer division, so I added casts).
Unfortunately, the window ratio is not set properly at start-up --
there are too many dependencies, and I haven't figured that part out
yet. As soon as you hide and redisplay the panel or move it
vertically (i.e. force fgReshape to be called), you'll see the correct
ratio.
2000-10-06 21:16:01 +00:00
|
|
|
|
|
2001-01-11 22:44:18 +00:00
|
|
|
|
/**
|
|
|
|
|
* Initialize the panel.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
FGPanel::init ()
|
|
|
|
|
{
|
2002-02-19 23:54:17 +00:00
|
|
|
|
SGPath base_path;
|
|
|
|
|
char* envp = ::getenv( "FG_FONTS" );
|
|
|
|
|
if ( envp != NULL ) {
|
|
|
|
|
base_path.set( envp );
|
|
|
|
|
} else {
|
|
|
|
|
base_path.set( globals->get_fg_root() );
|
|
|
|
|
base_path.append( "Fonts" );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SGPath fntpath;
|
|
|
|
|
|
|
|
|
|
// Install the default font
|
|
|
|
|
fntpath = base_path;
|
|
|
|
|
fntpath.append( "typewriter.txf" );
|
|
|
|
|
default_font = new fntTexFont ;
|
|
|
|
|
default_font -> load ( (char *)fntpath.c_str() ) ;
|
|
|
|
|
|
|
|
|
|
// Install the LED font
|
|
|
|
|
fntpath = base_path;
|
|
|
|
|
fntpath.append( "led.txf" );
|
|
|
|
|
led_font = new fntTexFont ;
|
|
|
|
|
led_font -> load ( (char *)fntpath.c_str() ) ;
|
2001-01-11 22:44:18 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Bind panel properties.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
FGPanel::bind ()
|
|
|
|
|
{
|
2001-07-12 23:34:16 +00:00
|
|
|
|
fgSetArchivable("/sim/panel/visibility");
|
|
|
|
|
fgSetArchivable("/sim/panel/x-offset");
|
|
|
|
|
fgSetArchivable("/sim/panel/y-offset");
|
2001-10-05 20:26:21 +00:00
|
|
|
|
fgSetArchivable("/sim/panel/jitter");
|
2001-01-11 22:44:18 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Unbind panel properties.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
FGPanel::unbind ()
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
David Megginson writes:
I have a scrollable panel working (it didn't take long in the end). A
panel can now be much wider or higher than the available area, and the
user can scroll around using [Shift]F5, [Shift]F6, [Shift]F7, and
[Shift]F8. The user can also scroll the panel down to get a bigger
external view. Mouse clicks seem still to be working correctly.
To set the panel's (virtual) height and width, use the panel file's /w
and /h properties in a panel XML file; to set the initial x- and y-
offsets (untested), use the panel file's /x-offset and /y-offset
properties; to set the initial height of the external view (untested
and optional), use the panel file's /view-height property. Note that
none of these show up in the regular FGFS property manager.
Unfortunately, these patches will not affect your initialization
problems with the property manager -- I'm having a hard time tracking
them down because I cannot reproduce them.
I have also made some patches to main.cxx and views.cxx to do two
things:
1. Expand or shrink the external view as the panel moves up and down.
2. Set the window ratio correctly, so that we don't get an oval sun
and flat clouds when the panel is visible (the problem before was
integer division, so I added casts).
Unfortunately, the window ratio is not set properly at start-up --
there are too many dependencies, and I haven't figured that part out
yet. As soon as you hide and redisplay the panel or move it
vertically (i.e. force fgReshape to be called), you'll see the correct
ratio.
2000-10-06 21:16:01 +00:00
|
|
|
|
/**
|
|
|
|
|
* Update the panel.
|
|
|
|
|
*/
|
2000-02-15 03:30:01 +00:00
|
|
|
|
void
|
2001-12-22 17:33:27 +00:00
|
|
|
|
FGPanel::update (int dt)
|
2000-02-15 03:30:01 +00:00
|
|
|
|
{
|
2002-03-13 15:16:24 +00:00
|
|
|
|
// TODO: cache the nodes
|
|
|
|
|
_visibility = fgGetBool("/sim/panel/visibility");
|
|
|
|
|
_x_offset = fgGetInt("/sim/panel/x-offset");
|
|
|
|
|
_y_offset = fgGetInt("/sim/panel/y-offset");
|
|
|
|
|
_jitter = fgGetFloat("/sim/panel/jitter");
|
|
|
|
|
|
2000-04-27 22:45:48 +00:00
|
|
|
|
// Do nothing if the panel isn't visible.
|
2001-10-29 04:37:24 +00:00
|
|
|
|
if ( !fgPanelVisible() ) {
|
2001-06-26 18:23:07 +00:00
|
|
|
|
return;
|
2001-10-29 04:37:24 +00:00
|
|
|
|
}
|
1999-12-23 17:37:18 +00:00
|
|
|
|
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
// If the mouse is down, do something
|
2001-06-26 18:23:07 +00:00
|
|
|
|
if (_mouseDown) {
|
|
|
|
|
_mouseDelay--;
|
|
|
|
|
if (_mouseDelay < 0) {
|
|
|
|
|
_mouseInstrument->doMouseAction(_mouseButton, _mouseX, _mouseY);
|
|
|
|
|
_mouseDelay = 2;
|
|
|
|
|
}
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Now, draw the panel
|
2001-06-26 18:23:07 +00:00
|
|
|
|
float aspect_adjust = get_aspect_adjust(_xsize_node->getIntValue(),
|
|
|
|
|
_ysize_node->getIntValue());
|
|
|
|
|
if (aspect_adjust <1.0)
|
|
|
|
|
update(WIN_X, int(WIN_W * aspect_adjust), WIN_Y, WIN_H);
|
|
|
|
|
else
|
|
|
|
|
update(WIN_X, WIN_W, WIN_Y, int(WIN_H / aspect_adjust));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
FGPanel::update (GLfloat winx, GLfloat winw, GLfloat winy, GLfloat winh)
|
|
|
|
|
{
|
2001-10-05 20:26:21 +00:00
|
|
|
|
// Calculate accelerations
|
|
|
|
|
// and jiggle the panel accordingly
|
|
|
|
|
// The factors and bounds are just
|
|
|
|
|
// initial guesses; using sqrt smooths
|
|
|
|
|
// out the spikes.
|
|
|
|
|
double x_offset = _x_offset;
|
|
|
|
|
double y_offset = _y_offset;
|
|
|
|
|
|
|
|
|
|
if (_jitter != 0.0) {
|
|
|
|
|
double a_x_pilot = current_aircraft.fdm_state->get_A_X_pilot();
|
|
|
|
|
double a_y_pilot = current_aircraft.fdm_state->get_A_Y_pilot();
|
|
|
|
|
double a_z_pilot = current_aircraft.fdm_state->get_A_Z_pilot();
|
|
|
|
|
|
|
|
|
|
double a_zx_pilot = a_z_pilot - a_x_pilot;
|
|
|
|
|
|
|
|
|
|
int x_adjust = int(sqrt(fabs(a_y_pilot) * _jitter)) *
|
|
|
|
|
(a_y_pilot < 0 ? -1 : 1);
|
|
|
|
|
int y_adjust = int(sqrt(fabs(a_zx_pilot) * _jitter)) *
|
|
|
|
|
(a_zx_pilot < 0 ? -1 : 1);
|
|
|
|
|
|
|
|
|
|
// adjustments in screen coordinates
|
|
|
|
|
x_offset += x_adjust;
|
|
|
|
|
y_offset += y_adjust;
|
|
|
|
|
}
|
|
|
|
|
|
Virtual cockpit patches from Andy Ross:
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply the patch (let me know if folks need help with that step), and
then set the /sim/virtual-cockpit property to true. You can do this
on the command line with --prop:/sim/virtual-cockpit=1, or via the
property picker. Bind it to a key for fast toggling if you like.
The default bindings don't allow for "panning" the view, so you'll
have to modify yours. These are the mappings to my joystick's hat
switch, for those who need hints:
<axis n="6">
<desc>View Direction</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
<axis n="7">
<desc>View Elevation</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
While the current implementation is happy with just plastering the
panel's notion of "screen" into the 3D world, this is actually more
general. Each panel can, in principle, have it's own coordinate
system, and you could build a cockpit out of a bunch of them. The
mapping is specified by providing a 3D coordinate for three corners of
the quad the panel should be mapped to; this should be pretty simple
to work with.
All that's needed for a perfectly general solution is a convention on
where to store the information (a cockpit xml file, or put it in the
aircraft -set file, or...), and some work on the panel's coordinate
system conventions (some of which don't coexist very nicely with a
generalized 3D environment). Combine that with a plib model for the
non-panel interior of the cockpit, and we're golden.
I'm actually really pleased with this. It worked better and more
quickly than I could have imagined, and impact on the surrounding code
is quite light -- a few property tests only. But some stuff is still
missing:
+ No equivalent work was done to the HUD, so it still displays
incorrect headings when the view changes. The use of pixel
coordinates deep in the HUD code is going to give me fits doing the
port, I sure. It's not nearly so well put together as the panel
(where I just changed the setup code -- none of the rendering code
changed at all).
+ I forgot that the panel was clickable. :) Input events still have
the screen coordinates, which essentially kills the interactivity
when in virtual cockpit mode. This won't be hard to fix; it's only
broken because I forgot the feature existed.
And one note about the implementation choice: to get away from the
inevitable near clip plane issue, the virtual cockpit renderer simply
disables the z buffer. This means that cockpits built using these
panels need to be z-sorted, which isn't too hard since they are static
geometry. It also means that no two "virtual panels" can ever be
allowed to interpenetrate. No biggie.
2002-03-03 00:06:24 +00:00
|
|
|
|
if(fgGetBool("/sim/virtual-cockpit")) {
|
|
|
|
|
setupVirtualCockpit();
|
|
|
|
|
} else {
|
|
|
|
|
glMatrixMode(GL_PROJECTION);
|
|
|
|
|
glPushMatrix();
|
|
|
|
|
glLoadIdentity();
|
|
|
|
|
gluOrtho2D(winx, winx + winw, winy, winy + winh); /* right side up */
|
|
|
|
|
// gluOrtho2D(winx + winw, winx, winy + winh, winy); /* up side down */
|
|
|
|
|
|
|
|
|
|
glMatrixMode(GL_MODELVIEW);
|
|
|
|
|
glPushMatrix();
|
|
|
|
|
glLoadIdentity();
|
|
|
|
|
|
|
|
|
|
glTranslated(x_offset, y_offset, 0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Draw the background
|
2000-02-15 03:30:01 +00:00
|
|
|
|
glEnable(GL_TEXTURE_2D);
|
2000-02-21 22:00:24 +00:00
|
|
|
|
glDisable(GL_LIGHTING);
|
2000-03-17 06:16:15 +00:00
|
|
|
|
glEnable(GL_BLEND);
|
|
|
|
|
glEnable(GL_ALPHA_TEST);
|
|
|
|
|
glEnable(GL_COLOR_MATERIAL);
|
2000-05-27 06:40:55 +00:00
|
|
|
|
// glColor4f(1.0, 1.0, 1.0, 1.0);
|
2001-03-24 04:48:44 +00:00
|
|
|
|
if ( cur_light_params.sun_angle * SGD_RADIANS_TO_DEGREES < 95.0 ) {
|
2000-05-27 06:40:55 +00:00
|
|
|
|
glColor4fv( cur_light_params.scene_diffuse );
|
|
|
|
|
} else {
|
|
|
|
|
glColor4f(0.7, 0.2, 0.2, 1.0);
|
|
|
|
|
}
|
2002-02-19 21:57:09 +00:00
|
|
|
|
if (_bg != 0) {
|
|
|
|
|
glBindTexture(GL_TEXTURE_2D, _bg->getHandle());
|
|
|
|
|
// glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
|
|
|
|
|
// glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
|
|
|
|
|
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
|
|
|
|
|
glBegin(GL_POLYGON);
|
|
|
|
|
glTexCoord2f(0.0, 0.0); glVertex3f(WIN_X, WIN_Y, 0);
|
|
|
|
|
glTexCoord2f(1.0, 0.0); glVertex3f(WIN_X + _width, WIN_Y, 0);
|
|
|
|
|
glTexCoord2f(1.0, 1.0); glVertex3f(WIN_X + _width, WIN_Y + _height, 0);
|
|
|
|
|
glTexCoord2f(0.0, 1.0); glVertex3f(WIN_X, WIN_Y + _height, 0);
|
|
|
|
|
glEnd();
|
|
|
|
|
} else {
|
|
|
|
|
for (int i = 0; i < 4; i ++) {
|
|
|
|
|
// top row of textures...(1,3,5,7)
|
|
|
|
|
glBindTexture(GL_TEXTURE_2D, _mbg[i*2]->getHandle());
|
|
|
|
|
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
|
|
|
|
|
glBegin(GL_POLYGON);
|
|
|
|
|
glTexCoord2f(0.0, 0.0); glVertex3f(WIN_X + (_width/4) * i, WIN_Y + (_height/2), 0);
|
|
|
|
|
glTexCoord2f(1.0, 0.0); glVertex3f(WIN_X + (_width/4) * (i+1), WIN_Y + (_height/2), 0);
|
|
|
|
|
glTexCoord2f(1.0, 1.0); glVertex3f(WIN_X + (_width/4) * (i+1), WIN_Y + _height, 0);
|
|
|
|
|
glTexCoord2f(0.0, 1.0); glVertex3f(WIN_X + (_width/4) * i, WIN_Y + _height, 0);
|
|
|
|
|
glEnd();
|
|
|
|
|
// bottom row of textures...(2,4,6,8)
|
|
|
|
|
glBindTexture(GL_TEXTURE_2D, _mbg[(i*2)+1]->getHandle());
|
|
|
|
|
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
|
|
|
|
|
glBegin(GL_POLYGON);
|
|
|
|
|
glTexCoord2f(0.0, 0.0); glVertex3f(WIN_X + (_width/4) * i, WIN_Y, 0);
|
|
|
|
|
glTexCoord2f(1.0, 0.0); glVertex3f(WIN_X + (_width/4) * (i+1), WIN_Y, 0);
|
|
|
|
|
glTexCoord2f(1.0, 1.0); glVertex3f(WIN_X + (_width/4) * (i+1), WIN_Y + (_height/2), 0);
|
|
|
|
|
glTexCoord2f(0.0, 1.0); glVertex3f(WIN_X + (_width/4) * i, WIN_Y + (_height/2), 0);
|
|
|
|
|
glEnd();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
}
|
2000-02-15 03:30:01 +00:00
|
|
|
|
|
|
|
|
|
// Draw the instruments.
|
2000-02-21 22:00:24 +00:00
|
|
|
|
instrument_list_type::const_iterator current = _instruments.begin();
|
|
|
|
|
instrument_list_type::const_iterator end = _instruments.end();
|
|
|
|
|
|
|
|
|
|
for ( ; current != end; current++) {
|
|
|
|
|
FGPanelInstrument * instr = *current;
|
Virtual cockpit patches from Andy Ross:
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply the patch (let me know if folks need help with that step), and
then set the /sim/virtual-cockpit property to true. You can do this
on the command line with --prop:/sim/virtual-cockpit=1, or via the
property picker. Bind it to a key for fast toggling if you like.
The default bindings don't allow for "panning" the view, so you'll
have to modify yours. These are the mappings to my joystick's hat
switch, for those who need hints:
<axis n="6">
<desc>View Direction</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
<axis n="7">
<desc>View Elevation</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
While the current implementation is happy with just plastering the
panel's notion of "screen" into the 3D world, this is actually more
general. Each panel can, in principle, have it's own coordinate
system, and you could build a cockpit out of a bunch of them. The
mapping is specified by providing a 3D coordinate for three corners of
the quad the panel should be mapped to; this should be pretty simple
to work with.
All that's needed for a perfectly general solution is a convention on
where to store the information (a cockpit xml file, or put it in the
aircraft -set file, or...), and some work on the panel's coordinate
system conventions (some of which don't coexist very nicely with a
generalized 3D environment). Combine that with a plib model for the
non-panel interior of the cockpit, and we're golden.
I'm actually really pleased with this. It worked better and more
quickly than I could have imagined, and impact on the surrounding code
is quite light -- a few property tests only. But some stuff is still
missing:
+ No equivalent work was done to the HUD, so it still displays
incorrect headings when the view changes. The use of pixel
coordinates deep in the HUD code is going to give me fits doing the
port, I sure. It's not nearly so well put together as the panel
(where I just changed the setup code -- none of the rendering code
changed at all).
+ I forgot that the panel was clickable. :) Input events still have
the screen coordinates, which essentially kills the interactivity
when in virtual cockpit mode. This won't be hard to fix; it's only
broken because I forgot the feature existed.
And one note about the implementation choice: to get away from the
inevitable near clip plane issue, the virtual cockpit renderer simply
disables the z buffer. This means that cockpits built using these
panels need to be z-sorted, which isn't too hard since they are static
geometry. It also means that no two "virtual panels" can ever be
allowed to interpenetrate. No biggie.
2002-03-03 00:06:24 +00:00
|
|
|
|
glPushMatrix();
|
2000-02-21 22:00:24 +00:00
|
|
|
|
glTranslated(instr->getXPos(), instr->getYPos(), 0);
|
|
|
|
|
instr->draw();
|
Virtual cockpit patches from Andy Ross:
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply the patch (let me know if folks need help with that step), and
then set the /sim/virtual-cockpit property to true. You can do this
on the command line with --prop:/sim/virtual-cockpit=1, or via the
property picker. Bind it to a key for fast toggling if you like.
The default bindings don't allow for "panning" the view, so you'll
have to modify yours. These are the mappings to my joystick's hat
switch, for those who need hints:
<axis n="6">
<desc>View Direction</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
<axis n="7">
<desc>View Elevation</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
While the current implementation is happy with just plastering the
panel's notion of "screen" into the 3D world, this is actually more
general. Each panel can, in principle, have it's own coordinate
system, and you could build a cockpit out of a bunch of them. The
mapping is specified by providing a 3D coordinate for three corners of
the quad the panel should be mapped to; this should be pretty simple
to work with.
All that's needed for a perfectly general solution is a convention on
where to store the information (a cockpit xml file, or put it in the
aircraft -set file, or...), and some work on the panel's coordinate
system conventions (some of which don't coexist very nicely with a
generalized 3D environment). Combine that with a plib model for the
non-panel interior of the cockpit, and we're golden.
I'm actually really pleased with this. It worked better and more
quickly than I could have imagined, and impact on the surrounding code
is quite light -- a few property tests only. But some stuff is still
missing:
+ No equivalent work was done to the HUD, so it still displays
incorrect headings when the view changes. The use of pixel
coordinates deep in the HUD code is going to give me fits doing the
port, I sure. It's not nearly so well put together as the panel
(where I just changed the setup code -- none of the rendering code
changed at all).
+ I forgot that the panel was clickable. :) Input events still have
the screen coordinates, which essentially kills the interactivity
when in virtual cockpit mode. This won't be hard to fix; it's only
broken because I forgot the feature existed.
And one note about the implementation choice: to get away from the
inevitable near clip plane issue, the virtual cockpit renderer simply
disables the z buffer. This means that cockpits built using these
panels need to be z-sorted, which isn't too hard since they are static
geometry. It also means that no two "virtual panels" can ever be
allowed to interpenetrate. No biggie.
2002-03-03 00:06:24 +00:00
|
|
|
|
glPopMatrix();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(fgGetBool("/sim/virtual-cockpit")) {
|
|
|
|
|
cleanupVirtualCockpit();
|
|
|
|
|
} else {
|
|
|
|
|
glMatrixMode(GL_PROJECTION);
|
|
|
|
|
glPopMatrix();
|
|
|
|
|
glMatrixMode(GL_MODELVIEW);
|
|
|
|
|
glPopMatrix();
|
2000-02-21 22:00:24 +00:00
|
|
|
|
}
|
2000-02-15 03:30:01 +00:00
|
|
|
|
|
2000-02-21 22:00:24 +00:00
|
|
|
|
ssgForceBasicState();
|
|
|
|
|
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
|
1999-12-23 17:37:18 +00:00
|
|
|
|
}
|
|
|
|
|
|
Virtual cockpit patches from Andy Ross:
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply the patch (let me know if folks need help with that step), and
then set the /sim/virtual-cockpit property to true. You can do this
on the command line with --prop:/sim/virtual-cockpit=1, or via the
property picker. Bind it to a key for fast toggling if you like.
The default bindings don't allow for "panning" the view, so you'll
have to modify yours. These are the mappings to my joystick's hat
switch, for those who need hints:
<axis n="6">
<desc>View Direction</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
<axis n="7">
<desc>View Elevation</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
While the current implementation is happy with just plastering the
panel's notion of "screen" into the 3D world, this is actually more
general. Each panel can, in principle, have it's own coordinate
system, and you could build a cockpit out of a bunch of them. The
mapping is specified by providing a 3D coordinate for three corners of
the quad the panel should be mapped to; this should be pretty simple
to work with.
All that's needed for a perfectly general solution is a convention on
where to store the information (a cockpit xml file, or put it in the
aircraft -set file, or...), and some work on the panel's coordinate
system conventions (some of which don't coexist very nicely with a
generalized 3D environment). Combine that with a plib model for the
non-panel interior of the cockpit, and we're golden.
I'm actually really pleased with this. It worked better and more
quickly than I could have imagined, and impact on the surrounding code
is quite light -- a few property tests only. But some stuff is still
missing:
+ No equivalent work was done to the HUD, so it still displays
incorrect headings when the view changes. The use of pixel
coordinates deep in the HUD code is going to give me fits doing the
port, I sure. It's not nearly so well put together as the panel
(where I just changed the setup code -- none of the rendering code
changed at all).
+ I forgot that the panel was clickable. :) Input events still have
the screen coordinates, which essentially kills the interactivity
when in virtual cockpit mode. This won't be hard to fix; it's only
broken because I forgot the feature existed.
And one note about the implementation choice: to get away from the
inevitable near clip plane issue, the virtual cockpit renderer simply
disables the z buffer. This means that cockpits built using these
panels need to be z-sorted, which isn't too hard since they are static
geometry. It also means that no two "virtual panels" can ever be
allowed to interpenetrate. No biggie.
2002-03-03 00:06:24 +00:00
|
|
|
|
void
|
|
|
|
|
FGPanel::setupVirtualCockpit()
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
FGViewer* view = globals->get_current_view();
|
|
|
|
|
|
2002-03-04 13:27:53 +00:00
|
|
|
|
// Generate corners for the panel quad. Put the top edge of the
|
|
|
|
|
// panel 1m in and 6 degrees down from the forward direction, and
|
|
|
|
|
// make the whole thing 60 degrees wide. In principle, these
|
|
|
|
|
// should be settable per-panel, so that you can have lots of
|
|
|
|
|
// panel objects plastered about the cockpit in realistic
|
Virtual cockpit patches from Andy Ross:
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply the patch (let me know if folks need help with that step), and
then set the /sim/virtual-cockpit property to true. You can do this
on the command line with --prop:/sim/virtual-cockpit=1, or via the
property picker. Bind it to a key for fast toggling if you like.
The default bindings don't allow for "panning" the view, so you'll
have to modify yours. These are the mappings to my joystick's hat
switch, for those who need hints:
<axis n="6">
<desc>View Direction</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
<axis n="7">
<desc>View Elevation</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
While the current implementation is happy with just plastering the
panel's notion of "screen" into the 3D world, this is actually more
general. Each panel can, in principle, have it's own coordinate
system, and you could build a cockpit out of a bunch of them. The
mapping is specified by providing a 3D coordinate for three corners of
the quad the panel should be mapped to; this should be pretty simple
to work with.
All that's needed for a perfectly general solution is a convention on
where to store the information (a cockpit xml file, or put it in the
aircraft -set file, or...), and some work on the panel's coordinate
system conventions (some of which don't coexist very nicely with a
generalized 3D environment). Combine that with a plib model for the
non-panel interior of the cockpit, and we're golden.
I'm actually really pleased with this. It worked better and more
quickly than I could have imagined, and impact on the surrounding code
is quite light -- a few property tests only. But some stuff is still
missing:
+ No equivalent work was done to the HUD, so it still displays
incorrect headings when the view changes. The use of pixel
coordinates deep in the HUD code is going to give me fits doing the
port, I sure. It's not nearly so well put together as the panel
(where I just changed the setup code -- none of the rendering code
changed at all).
+ I forgot that the panel was clickable. :) Input events still have
the screen coordinates, which essentially kills the interactivity
when in virtual cockpit mode. This won't be hard to fix; it's only
broken because I forgot the feature existed.
And one note about the implementation choice: to get away from the
inevitable near clip plane issue, the virtual cockpit renderer simply
disables the z buffer. This means that cockpits built using these
panels need to be z-sorted, which isn't too hard since they are static
geometry. It also means that no two "virtual panels" can ever be
allowed to interpenetrate. No biggie.
2002-03-03 00:06:24 +00:00
|
|
|
|
// positions and orientations.
|
2002-03-04 13:27:53 +00:00
|
|
|
|
float a[3], b[3], c[3];
|
|
|
|
|
float pw = tan(30*SGD_DEGREES_TO_RADIANS);
|
|
|
|
|
float ph = 2 * pw * (float)_height/(float)_width;
|
|
|
|
|
float ptop = -tan(6*SGD_DEGREES_TO_RADIANS);
|
|
|
|
|
a[0] = -pw; a[1] = ptop-ph; a[2] = -1; // bottom left
|
|
|
|
|
b[0] = pw; b[1] = ptop-ph; b[2] = -1; // bottom right
|
|
|
|
|
c[0] = -pw; c[1] = ptop; c[2] = -1; // top left
|
Virtual cockpit patches from Andy Ross:
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply the patch (let me know if folks need help with that step), and
then set the /sim/virtual-cockpit property to true. You can do this
on the command line with --prop:/sim/virtual-cockpit=1, or via the
property picker. Bind it to a key for fast toggling if you like.
The default bindings don't allow for "panning" the view, so you'll
have to modify yours. These are the mappings to my joystick's hat
switch, for those who need hints:
<axis n="6">
<desc>View Direction</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
<axis n="7">
<desc>View Elevation</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
While the current implementation is happy with just plastering the
panel's notion of "screen" into the 3D world, this is actually more
general. Each panel can, in principle, have it's own coordinate
system, and you could build a cockpit out of a bunch of them. The
mapping is specified by providing a 3D coordinate for three corners of
the quad the panel should be mapped to; this should be pretty simple
to work with.
All that's needed for a perfectly general solution is a convention on
where to store the information (a cockpit xml file, or put it in the
aircraft -set file, or...), and some work on the panel's coordinate
system conventions (some of which don't coexist very nicely with a
generalized 3D environment). Combine that with a plib model for the
non-panel interior of the cockpit, and we're golden.
I'm actually really pleased with this. It worked better and more
quickly than I could have imagined, and impact on the surrounding code
is quite light -- a few property tests only. But some stuff is still
missing:
+ No equivalent work was done to the HUD, so it still displays
incorrect headings when the view changes. The use of pixel
coordinates deep in the HUD code is going to give me fits doing the
port, I sure. It's not nearly so well put together as the panel
(where I just changed the setup code -- none of the rendering code
changed at all).
+ I forgot that the panel was clickable. :) Input events still have
the screen coordinates, which essentially kills the interactivity
when in virtual cockpit mode. This won't be hard to fix; it's only
broken because I forgot the feature existed.
And one note about the implementation choice: to get away from the
inevitable near clip plane issue, the virtual cockpit renderer simply
disables the z buffer. This means that cockpits built using these
panels need to be z-sorted, which isn't too hard since they are static
geometry. It also means that no two "virtual panels" can ever be
allowed to interpenetrate. No biggie.
2002-03-03 00:06:24 +00:00
|
|
|
|
|
|
|
|
|
// A standard projection, in meters, with especially close clip
|
|
|
|
|
// planes.
|
|
|
|
|
glMatrixMode(GL_PROJECTION);
|
|
|
|
|
glPushMatrix();
|
|
|
|
|
glLoadIdentity();
|
|
|
|
|
gluPerspective(view->get_v_fov(), 1/view->get_aspect_ratio(),
|
|
|
|
|
0.01, 100);
|
|
|
|
|
|
|
|
|
|
glMatrixMode(GL_MODELVIEW);
|
|
|
|
|
glPushMatrix();
|
2002-03-04 13:27:53 +00:00
|
|
|
|
glLoadIdentity();
|
Virtual cockpit patches from Andy Ross:
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply the patch (let me know if folks need help with that step), and
then set the /sim/virtual-cockpit property to true. You can do this
on the command line with --prop:/sim/virtual-cockpit=1, or via the
property picker. Bind it to a key for fast toggling if you like.
The default bindings don't allow for "panning" the view, so you'll
have to modify yours. These are the mappings to my joystick's hat
switch, for those who need hints:
<axis n="6">
<desc>View Direction</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
<axis n="7">
<desc>View Elevation</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
While the current implementation is happy with just plastering the
panel's notion of "screen" into the 3D world, this is actually more
general. Each panel can, in principle, have it's own coordinate
system, and you could build a cockpit out of a bunch of them. The
mapping is specified by providing a 3D coordinate for three corners of
the quad the panel should be mapped to; this should be pretty simple
to work with.
All that's needed for a perfectly general solution is a convention on
where to store the information (a cockpit xml file, or put it in the
aircraft -set file, or...), and some work on the panel's coordinate
system conventions (some of which don't coexist very nicely with a
generalized 3D environment). Combine that with a plib model for the
non-panel interior of the cockpit, and we're golden.
I'm actually really pleased with this. It worked better and more
quickly than I could have imagined, and impact on the surrounding code
is quite light -- a few property tests only. But some stuff is still
missing:
+ No equivalent work was done to the HUD, so it still displays
incorrect headings when the view changes. The use of pixel
coordinates deep in the HUD code is going to give me fits doing the
port, I sure. It's not nearly so well put together as the panel
(where I just changed the setup code -- none of the rendering code
changed at all).
+ I forgot that the panel was clickable. :) Input events still have
the screen coordinates, which essentially kills the interactivity
when in virtual cockpit mode. This won't be hard to fix; it's only
broken because I forgot the feature existed.
And one note about the implementation choice: to get away from the
inevitable near clip plane issue, the virtual cockpit renderer simply
disables the z buffer. This means that cockpits built using these
panels need to be z-sorted, which isn't too hard since they are static
geometry. It also means that no two "virtual panels" can ever be
allowed to interpenetrate. No biggie.
2002-03-03 00:06:24 +00:00
|
|
|
|
|
|
|
|
|
// Generate a "look at" matrix using OpenGL (!) coordinate
|
|
|
|
|
// conventions.
|
|
|
|
|
float lookat[3];
|
Major viewer-code overhaul from Jim Wilson:
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.
2002-03-20 17:43:28 +00:00
|
|
|
|
float pitch = view->getPitchOffset_deg() * SGD_DEGREES_TO_RADIANS;
|
|
|
|
|
float rot = view->getHeadingOffset_deg() * SGD_DEGREES_TO_RADIANS;
|
Virtual cockpit patches from Andy Ross:
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply the patch (let me know if folks need help with that step), and
then set the /sim/virtual-cockpit property to true. You can do this
on the command line with --prop:/sim/virtual-cockpit=1, or via the
property picker. Bind it to a key for fast toggling if you like.
The default bindings don't allow for "panning" the view, so you'll
have to modify yours. These are the mappings to my joystick's hat
switch, for those who need hints:
<axis n="6">
<desc>View Direction</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
<axis n="7">
<desc>View Elevation</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
While the current implementation is happy with just plastering the
panel's notion of "screen" into the 3D world, this is actually more
general. Each panel can, in principle, have it's own coordinate
system, and you could build a cockpit out of a bunch of them. The
mapping is specified by providing a 3D coordinate for three corners of
the quad the panel should be mapped to; this should be pretty simple
to work with.
All that's needed for a perfectly general solution is a convention on
where to store the information (a cockpit xml file, or put it in the
aircraft -set file, or...), and some work on the panel's coordinate
system conventions (some of which don't coexist very nicely with a
generalized 3D environment). Combine that with a plib model for the
non-panel interior of the cockpit, and we're golden.
I'm actually really pleased with this. It worked better and more
quickly than I could have imagined, and impact on the surrounding code
is quite light -- a few property tests only. But some stuff is still
missing:
+ No equivalent work was done to the HUD, so it still displays
incorrect headings when the view changes. The use of pixel
coordinates deep in the HUD code is going to give me fits doing the
port, I sure. It's not nearly so well put together as the panel
(where I just changed the setup code -- none of the rendering code
changed at all).
+ I forgot that the panel was clickable. :) Input events still have
the screen coordinates, which essentially kills the interactivity
when in virtual cockpit mode. This won't be hard to fix; it's only
broken because I forgot the feature existed.
And one note about the implementation choice: to get away from the
inevitable near clip plane issue, the virtual cockpit renderer simply
disables the z buffer. This means that cockpits built using these
panels need to be z-sorted, which isn't too hard since they are static
geometry. It also means that no two "virtual panels" can ever be
allowed to interpenetrate. No biggie.
2002-03-03 00:06:24 +00:00
|
|
|
|
lookat[0] = -sin(rot);
|
|
|
|
|
lookat[1] = sin(pitch) / cos(pitch);
|
|
|
|
|
lookat[2] = -cos(rot);
|
|
|
|
|
if(fabs(lookat[1]) > 9999) lookat[1] = 9999; // FPU sanity
|
|
|
|
|
gluLookAt(0, 0, 0, lookat[0], lookat[1], lookat[2], 0, 1, 0);
|
|
|
|
|
|
|
|
|
|
// Translate the origin to the location of the panel quad
|
|
|
|
|
glTranslatef(a[0], a[1], a[2]);
|
|
|
|
|
|
|
|
|
|
// Generate a matrix to translate unit square coordinates from the
|
2002-03-04 13:27:53 +00:00
|
|
|
|
// panel to real world coordinates. Use a transposed basis for
|
|
|
|
|
// the panel quad. Note: this matrix is relatively expensive to
|
Virtual cockpit patches from Andy Ross:
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply the patch (let me know if folks need help with that step), and
then set the /sim/virtual-cockpit property to true. You can do this
on the command line with --prop:/sim/virtual-cockpit=1, or via the
property picker. Bind it to a key for fast toggling if you like.
The default bindings don't allow for "panning" the view, so you'll
have to modify yours. These are the mappings to my joystick's hat
switch, for those who need hints:
<axis n="6">
<desc>View Direction</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
<axis n="7">
<desc>View Elevation</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
While the current implementation is happy with just plastering the
panel's notion of "screen" into the 3D world, this is actually more
general. Each panel can, in principle, have it's own coordinate
system, and you could build a cockpit out of a bunch of them. The
mapping is specified by providing a 3D coordinate for three corners of
the quad the panel should be mapped to; this should be pretty simple
to work with.
All that's needed for a perfectly general solution is a convention on
where to store the information (a cockpit xml file, or put it in the
aircraft -set file, or...), and some work on the panel's coordinate
system conventions (some of which don't coexist very nicely with a
generalized 3D environment). Combine that with a plib model for the
non-panel interior of the cockpit, and we're golden.
I'm actually really pleased with this. It worked better and more
quickly than I could have imagined, and impact on the surrounding code
is quite light -- a few property tests only. But some stuff is still
missing:
+ No equivalent work was done to the HUD, so it still displays
incorrect headings when the view changes. The use of pixel
coordinates deep in the HUD code is going to give me fits doing the
port, I sure. It's not nearly so well put together as the panel
(where I just changed the setup code -- none of the rendering code
changed at all).
+ I forgot that the panel was clickable. :) Input events still have
the screen coordinates, which essentially kills the interactivity
when in virtual cockpit mode. This won't be hard to fix; it's only
broken because I forgot the feature existed.
And one note about the implementation choice: to get away from the
inevitable near clip plane issue, the virtual cockpit renderer simply
disables the z buffer. This means that cockpits built using these
panels need to be z-sorted, which isn't too hard since they are static
geometry. It also means that no two "virtual panels" can ever be
allowed to interpenetrate. No biggie.
2002-03-03 00:06:24 +00:00
|
|
|
|
// compute, and is invariant. Consider precomputing and storing
|
|
|
|
|
// it. Also, consider using the plib vector math routines, so the
|
|
|
|
|
// reuse junkies don't yell at me. (Fine, I hard-coded a cross
|
|
|
|
|
// product. Just shoot me and be done with it.)
|
2002-03-04 13:27:53 +00:00
|
|
|
|
float u[3], v[3], w[3], m[16];
|
Virtual cockpit patches from Andy Ross:
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply the patch (let me know if folks need help with that step), and
then set the /sim/virtual-cockpit property to true. You can do this
on the command line with --prop:/sim/virtual-cockpit=1, or via the
property picker. Bind it to a key for fast toggling if you like.
The default bindings don't allow for "panning" the view, so you'll
have to modify yours. These are the mappings to my joystick's hat
switch, for those who need hints:
<axis n="6">
<desc>View Direction</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
<axis n="7">
<desc>View Elevation</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
While the current implementation is happy with just plastering the
panel's notion of "screen" into the 3D world, this is actually more
general. Each panel can, in principle, have it's own coordinate
system, and you could build a cockpit out of a bunch of them. The
mapping is specified by providing a 3D coordinate for three corners of
the quad the panel should be mapped to; this should be pretty simple
to work with.
All that's needed for a perfectly general solution is a convention on
where to store the information (a cockpit xml file, or put it in the
aircraft -set file, or...), and some work on the panel's coordinate
system conventions (some of which don't coexist very nicely with a
generalized 3D environment). Combine that with a plib model for the
non-panel interior of the cockpit, and we're golden.
I'm actually really pleased with this. It worked better and more
quickly than I could have imagined, and impact on the surrounding code
is quite light -- a few property tests only. But some stuff is still
missing:
+ No equivalent work was done to the HUD, so it still displays
incorrect headings when the view changes. The use of pixel
coordinates deep in the HUD code is going to give me fits doing the
port, I sure. It's not nearly so well put together as the panel
(where I just changed the setup code -- none of the rendering code
changed at all).
+ I forgot that the panel was clickable. :) Input events still have
the screen coordinates, which essentially kills the interactivity
when in virtual cockpit mode. This won't be hard to fix; it's only
broken because I forgot the feature existed.
And one note about the implementation choice: to get away from the
inevitable near clip plane issue, the virtual cockpit renderer simply
disables the z buffer. This means that cockpits built using these
panels need to be z-sorted, which isn't too hard since they are static
geometry. It also means that no two "virtual panels" can ever be
allowed to interpenetrate. No biggie.
2002-03-03 00:06:24 +00:00
|
|
|
|
for(i=0; i<3; i++) u[i] = b[i] - a[i]; // U = B - A
|
|
|
|
|
for(i=0; i<3; i++) v[i] = c[i] - a[i]; // V = C - A
|
|
|
|
|
w[0] = u[1]*v[2] - v[1]*u[2]; // W = U x V
|
|
|
|
|
w[1] = u[2]*v[0] - v[2]*u[0];
|
|
|
|
|
w[2] = u[0]*v[1] - v[0]*u[1];
|
2002-03-04 13:27:53 +00:00
|
|
|
|
|
|
|
|
|
m[0] = u[0]; m[4] = v[0]; m[8] = w[0]; m[12] = 0; // |Ux Vx Wx|
|
|
|
|
|
m[1] = u[1]; m[5] = v[1]; m[9] = w[1]; m[13] = 0; // m = |Uy Vy Wy|
|
|
|
|
|
m[2] = u[2]; m[6] = v[2]; m[10] = w[2]; m[14] = 0; // |Uz Vz Wz|
|
|
|
|
|
m[3] = 0; m[7] = 0; m[11] = 0; m[15] = 1;
|
|
|
|
|
glMultMatrixf(m);
|
|
|
|
|
|
|
|
|
|
// Finally, a scaling factor to map the panel's width and height
|
|
|
|
|
// to the unit square.
|
|
|
|
|
glScalef(1./_width, 1./_height, 1);
|
|
|
|
|
|
Virtual cockpit patches from Andy Ross:
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply the patch (let me know if folks need help with that step), and
then set the /sim/virtual-cockpit property to true. You can do this
on the command line with --prop:/sim/virtual-cockpit=1, or via the
property picker. Bind it to a key for fast toggling if you like.
The default bindings don't allow for "panning" the view, so you'll
have to modify yours. These are the mappings to my joystick's hat
switch, for those who need hints:
<axis n="6">
<desc>View Direction</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
<axis n="7">
<desc>View Elevation</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
While the current implementation is happy with just plastering the
panel's notion of "screen" into the 3D world, this is actually more
general. Each panel can, in principle, have it's own coordinate
system, and you could build a cockpit out of a bunch of them. The
mapping is specified by providing a 3D coordinate for three corners of
the quad the panel should be mapped to; this should be pretty simple
to work with.
All that's needed for a perfectly general solution is a convention on
where to store the information (a cockpit xml file, or put it in the
aircraft -set file, or...), and some work on the panel's coordinate
system conventions (some of which don't coexist very nicely with a
generalized 3D environment). Combine that with a plib model for the
non-panel interior of the cockpit, and we're golden.
I'm actually really pleased with this. It worked better and more
quickly than I could have imagined, and impact on the surrounding code
is quite light -- a few property tests only. But some stuff is still
missing:
+ No equivalent work was done to the HUD, so it still displays
incorrect headings when the view changes. The use of pixel
coordinates deep in the HUD code is going to give me fits doing the
port, I sure. It's not nearly so well put together as the panel
(where I just changed the setup code -- none of the rendering code
changed at all).
+ I forgot that the panel was clickable. :) Input events still have
the screen coordinates, which essentially kills the interactivity
when in virtual cockpit mode. This won't be hard to fix; it's only
broken because I forgot the feature existed.
And one note about the implementation choice: to get away from the
inevitable near clip plane issue, the virtual cockpit renderer simply
disables the z buffer. This means that cockpits built using these
panels need to be z-sorted, which isn't too hard since they are static
geometry. It also means that no two "virtual panels" can ever be
allowed to interpenetrate. No biggie.
2002-03-03 00:06:24 +00:00
|
|
|
|
// Now, turn off the Z buffer. The panel code doesn't need
|
|
|
|
|
// it, and we're using different clip planes anyway (meaning we
|
|
|
|
|
// can't share it without glDepthRange() hackery or much
|
|
|
|
|
// framebuffer bandwidth wasteage)
|
|
|
|
|
glDisable(GL_DEPTH_TEST);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
FGPanel::cleanupVirtualCockpit()
|
|
|
|
|
{
|
|
|
|
|
glMatrixMode(GL_PROJECTION);
|
|
|
|
|
glPopMatrix();
|
|
|
|
|
glMatrixMode(GL_MODELVIEW);
|
|
|
|
|
glPopMatrix();
|
|
|
|
|
glEnable(GL_DEPTH_TEST);
|
|
|
|
|
}
|
|
|
|
|
|
David Megginson writes:
I have a scrollable panel working (it didn't take long in the end). A
panel can now be much wider or higher than the available area, and the
user can scroll around using [Shift]F5, [Shift]F6, [Shift]F7, and
[Shift]F8. The user can also scroll the panel down to get a bigger
external view. Mouse clicks seem still to be working correctly.
To set the panel's (virtual) height and width, use the panel file's /w
and /h properties in a panel XML file; to set the initial x- and y-
offsets (untested), use the panel file's /x-offset and /y-offset
properties; to set the initial height of the external view (untested
and optional), use the panel file's /view-height property. Note that
none of these show up in the regular FGFS property manager.
Unfortunately, these patches will not affect your initialization
problems with the property manager -- I'm having a hard time tracking
them down because I cannot reproduce them.
I have also made some patches to main.cxx and views.cxx to do two
things:
1. Expand or shrink the external view as the panel moves up and down.
2. Set the window ratio correctly, so that we don't get an oval sun
and flat clouds when the panel is visible (the problem before was
integer division, so I added casts).
Unfortunately, the window ratio is not set properly at start-up --
there are too many dependencies, and I haven't figured that part out
yet. As soon as you hide and redisplay the panel or move it
vertically (i.e. force fgReshape to be called), you'll see the correct
ratio.
2000-10-06 21:16:01 +00:00
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Set the panel's visibility.
|
|
|
|
|
*/
|
2000-04-27 22:45:48 +00:00
|
|
|
|
void
|
|
|
|
|
FGPanel::setVisibility (bool visibility)
|
2000-02-26 18:01:13 +00:00
|
|
|
|
{
|
2000-04-27 22:45:48 +00:00
|
|
|
|
_visibility = visibility;
|
|
|
|
|
}
|
2000-02-26 18:01:13 +00:00
|
|
|
|
|
David Megginson writes:
I have a scrollable panel working (it didn't take long in the end). A
panel can now be much wider or higher than the available area, and the
user can scroll around using [Shift]F5, [Shift]F6, [Shift]F7, and
[Shift]F8. The user can also scroll the panel down to get a bigger
external view. Mouse clicks seem still to be working correctly.
To set the panel's (virtual) height and width, use the panel file's /w
and /h properties in a panel XML file; to set the initial x- and y-
offsets (untested), use the panel file's /x-offset and /y-offset
properties; to set the initial height of the external view (untested
and optional), use the panel file's /view-height property. Note that
none of these show up in the regular FGFS property manager.
Unfortunately, these patches will not affect your initialization
problems with the property manager -- I'm having a hard time tracking
them down because I cannot reproduce them.
I have also made some patches to main.cxx and views.cxx to do two
things:
1. Expand or shrink the external view as the panel moves up and down.
2. Set the window ratio correctly, so that we don't get an oval sun
and flat clouds when the panel is visible (the problem before was
integer division, so I added casts).
Unfortunately, the window ratio is not set properly at start-up --
there are too many dependencies, and I haven't figured that part out
yet. As soon as you hide and redisplay the panel or move it
vertically (i.e. force fgReshape to be called), you'll see the correct
ratio.
2000-10-06 21:16:01 +00:00
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Return true if the panel is visible.
|
|
|
|
|
*/
|
2000-04-27 22:45:48 +00:00
|
|
|
|
bool
|
|
|
|
|
FGPanel::getVisibility () const
|
|
|
|
|
{
|
|
|
|
|
return _visibility;
|
|
|
|
|
}
|
|
|
|
|
|
David Megginson writes:
I have a scrollable panel working (it didn't take long in the end). A
panel can now be much wider or higher than the available area, and the
user can scroll around using [Shift]F5, [Shift]F6, [Shift]F7, and
[Shift]F8. The user can also scroll the panel down to get a bigger
external view. Mouse clicks seem still to be working correctly.
To set the panel's (virtual) height and width, use the panel file's /w
and /h properties in a panel XML file; to set the initial x- and y-
offsets (untested), use the panel file's /x-offset and /y-offset
properties; to set the initial height of the external view (untested
and optional), use the panel file's /view-height property. Note that
none of these show up in the regular FGFS property manager.
Unfortunately, these patches will not affect your initialization
problems with the property manager -- I'm having a hard time tracking
them down because I cannot reproduce them.
I have also made some patches to main.cxx and views.cxx to do two
things:
1. Expand or shrink the external view as the panel moves up and down.
2. Set the window ratio correctly, so that we don't get an oval sun
and flat clouds when the panel is visible (the problem before was
integer division, so I added casts).
Unfortunately, the window ratio is not set properly at start-up --
there are too many dependencies, and I haven't figured that part out
yet. As soon as you hide and redisplay the panel or move it
vertically (i.e. force fgReshape to be called), you'll see the correct
ratio.
2000-10-06 21:16:01 +00:00
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Set the panel's background texture.
|
|
|
|
|
*/
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
void
|
|
|
|
|
FGPanel::setBackground (ssgTexture * texture)
|
|
|
|
|
{
|
|
|
|
|
_bg = texture;
|
|
|
|
|
}
|
|
|
|
|
|
2002-02-19 21:57:09 +00:00
|
|
|
|
/**
|
|
|
|
|
* Set the panel's multiple background textures.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
FGPanel::setMultiBackground (ssgTexture * texture, int idx)
|
|
|
|
|
{
|
|
|
|
|
_bg = 0;
|
|
|
|
|
_mbg[idx] = texture;
|
|
|
|
|
}
|
David Megginson writes:
I have a scrollable panel working (it didn't take long in the end). A
panel can now be much wider or higher than the available area, and the
user can scroll around using [Shift]F5, [Shift]F6, [Shift]F7, and
[Shift]F8. The user can also scroll the panel down to get a bigger
external view. Mouse clicks seem still to be working correctly.
To set the panel's (virtual) height and width, use the panel file's /w
and /h properties in a panel XML file; to set the initial x- and y-
offsets (untested), use the panel file's /x-offset and /y-offset
properties; to set the initial height of the external view (untested
and optional), use the panel file's /view-height property. Note that
none of these show up in the regular FGFS property manager.
Unfortunately, these patches will not affect your initialization
problems with the property manager -- I'm having a hard time tracking
them down because I cannot reproduce them.
I have also made some patches to main.cxx and views.cxx to do two
things:
1. Expand or shrink the external view as the panel moves up and down.
2. Set the window ratio correctly, so that we don't get an oval sun
and flat clouds when the panel is visible (the problem before was
integer division, so I added casts).
Unfortunately, the window ratio is not set properly at start-up --
there are too many dependencies, and I haven't figured that part out
yet. As soon as you hide and redisplay the panel or move it
vertically (i.e. force fgReshape to be called), you'll see the correct
ratio.
2000-10-06 21:16:01 +00:00
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Set the panel's x-offset.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
FGPanel::setXOffset (int offset)
|
|
|
|
|
{
|
2001-06-20 20:50:49 +00:00
|
|
|
|
if (offset <= 0 && offset >= -_width + WIN_W)
|
David Megginson writes:
I have a scrollable panel working (it didn't take long in the end). A
panel can now be much wider or higher than the available area, and the
user can scroll around using [Shift]F5, [Shift]F6, [Shift]F7, and
[Shift]F8. The user can also scroll the panel down to get a bigger
external view. Mouse clicks seem still to be working correctly.
To set the panel's (virtual) height and width, use the panel file's /w
and /h properties in a panel XML file; to set the initial x- and y-
offsets (untested), use the panel file's /x-offset and /y-offset
properties; to set the initial height of the external view (untested
and optional), use the panel file's /view-height property. Note that
none of these show up in the regular FGFS property manager.
Unfortunately, these patches will not affect your initialization
problems with the property manager -- I'm having a hard time tracking
them down because I cannot reproduce them.
I have also made some patches to main.cxx and views.cxx to do two
things:
1. Expand or shrink the external view as the panel moves up and down.
2. Set the window ratio correctly, so that we don't get an oval sun
and flat clouds when the panel is visible (the problem before was
integer division, so I added casts).
Unfortunately, the window ratio is not set properly at start-up --
there are too many dependencies, and I haven't figured that part out
yet. As soon as you hide and redisplay the panel or move it
vertically (i.e. force fgReshape to be called), you'll see the correct
ratio.
2000-10-06 21:16:01 +00:00
|
|
|
|
_x_offset = offset;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Set the panel's y-offset.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
FGPanel::setYOffset (int offset)
|
|
|
|
|
{
|
|
|
|
|
if (offset <= 0 && offset >= -_height)
|
|
|
|
|
_y_offset = offset;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Perform a mouse action.
|
|
|
|
|
*/
|
2000-04-27 22:45:48 +00:00
|
|
|
|
bool
|
|
|
|
|
FGPanel::doMouseAction (int button, int updown, int x, int y)
|
|
|
|
|
{
|
2001-06-20 20:50:49 +00:00
|
|
|
|
// FIXME: this same code appears in update()
|
|
|
|
|
int xsize = _xsize_node->getIntValue();
|
|
|
|
|
int ysize = _ysize_node->getIntValue();
|
|
|
|
|
float aspect_adjust = get_aspect_adjust(xsize, ysize);
|
David Megginson writes:
I have a scrollable panel working (it didn't take long in the end). A
panel can now be much wider or higher than the available area, and the
user can scroll around using [Shift]F5, [Shift]F6, [Shift]F7, and
[Shift]F8. The user can also scroll the panel down to get a bigger
external view. Mouse clicks seem still to be working correctly.
To set the panel's (virtual) height and width, use the panel file's /w
and /h properties in a panel XML file; to set the initial x- and y-
offsets (untested), use the panel file's /x-offset and /y-offset
properties; to set the initial height of the external view (untested
and optional), use the panel file's /view-height property. Note that
none of these show up in the regular FGFS property manager.
Unfortunately, these patches will not affect your initialization
problems with the property manager -- I'm having a hard time tracking
them down because I cannot reproduce them.
I have also made some patches to main.cxx and views.cxx to do two
things:
1. Expand or shrink the external view as the panel moves up and down.
2. Set the window ratio correctly, so that we don't get an oval sun
and flat clouds when the panel is visible (the problem before was
integer division, so I added casts).
Unfortunately, the window ratio is not set properly at start-up --
there are too many dependencies, and I haven't figured that part out
yet. As soon as you hide and redisplay the panel or move it
vertically (i.e. force fgReshape to be called), you'll see the correct
ratio.
2000-10-06 21:16:01 +00:00
|
|
|
|
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
// Note a released button and return
|
2000-06-14 20:59:51 +00:00
|
|
|
|
// cerr << "Doing mouse action\n";
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
if (updown == 1) {
|
|
|
|
|
_mouseDown = false;
|
|
|
|
|
_mouseInstrument = 0;
|
2000-04-27 22:45:48 +00:00
|
|
|
|
return true;
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
}
|
2000-04-27 22:45:48 +00:00
|
|
|
|
|
David Megginson writes:
I have a scrollable panel working (it didn't take long in the end). A
panel can now be much wider or higher than the available area, and the
user can scroll around using [Shift]F5, [Shift]F6, [Shift]F7, and
[Shift]F8. The user can also scroll the panel down to get a bigger
external view. Mouse clicks seem still to be working correctly.
To set the panel's (virtual) height and width, use the panel file's /w
and /h properties in a panel XML file; to set the initial x- and y-
offsets (untested), use the panel file's /x-offset and /y-offset
properties; to set the initial height of the external view (untested
and optional), use the panel file's /view-height property. Note that
none of these show up in the regular FGFS property manager.
Unfortunately, these patches will not affect your initialization
problems with the property manager -- I'm having a hard time tracking
them down because I cannot reproduce them.
I have also made some patches to main.cxx and views.cxx to do two
things:
1. Expand or shrink the external view as the panel moves up and down.
2. Set the window ratio correctly, so that we don't get an oval sun
and flat clouds when the panel is visible (the problem before was
integer division, so I added casts).
Unfortunately, the window ratio is not set properly at start-up --
there are too many dependencies, and I haven't figured that part out
yet. As soon as you hide and redisplay the panel or move it
vertically (i.e. force fgReshape to be called), you'll see the correct
ratio.
2000-10-06 21:16:01 +00:00
|
|
|
|
// Scale for the real window size.
|
2001-06-20 20:50:49 +00:00
|
|
|
|
if (aspect_adjust < 1.0) {
|
|
|
|
|
x = int(((float)x / xsize) * WIN_W * aspect_adjust);
|
|
|
|
|
y = int(WIN_H - ((float(y) / ysize) * WIN_H));
|
|
|
|
|
} else {
|
|
|
|
|
x = int(((float)x / xsize) * WIN_W);
|
|
|
|
|
y = int((WIN_H - ((float(y) / ysize) * WIN_H)) / aspect_adjust);
|
|
|
|
|
}
|
David Megginson writes:
I have a scrollable panel working (it didn't take long in the end). A
panel can now be much wider or higher than the available area, and the
user can scroll around using [Shift]F5, [Shift]F6, [Shift]F7, and
[Shift]F8. The user can also scroll the panel down to get a bigger
external view. Mouse clicks seem still to be working correctly.
To set the panel's (virtual) height and width, use the panel file's /w
and /h properties in a panel XML file; to set the initial x- and y-
offsets (untested), use the panel file's /x-offset and /y-offset
properties; to set the initial height of the external view (untested
and optional), use the panel file's /view-height property. Note that
none of these show up in the regular FGFS property manager.
Unfortunately, these patches will not affect your initialization
problems with the property manager -- I'm having a hard time tracking
them down because I cannot reproduce them.
I have also made some patches to main.cxx and views.cxx to do two
things:
1. Expand or shrink the external view as the panel moves up and down.
2. Set the window ratio correctly, so that we don't get an oval sun
and flat clouds when the panel is visible (the problem before was
integer division, so I added casts).
Unfortunately, the window ratio is not set properly at start-up --
there are too many dependencies, and I haven't figured that part out
yet. As soon as you hide and redisplay the panel or move it
vertically (i.e. force fgReshape to be called), you'll see the correct
ratio.
2000-10-06 21:16:01 +00:00
|
|
|
|
|
|
|
|
|
// Adjust for offsets.
|
|
|
|
|
x -= _x_offset;
|
|
|
|
|
y -= _y_offset;
|
2000-04-27 22:45:48 +00:00
|
|
|
|
|
David Megginson writes:
I have a scrollable panel working (it didn't take long in the end). A
panel can now be much wider or higher than the available area, and the
user can scroll around using [Shift]F5, [Shift]F6, [Shift]F7, and
[Shift]F8. The user can also scroll the panel down to get a bigger
external view. Mouse clicks seem still to be working correctly.
To set the panel's (virtual) height and width, use the panel file's /w
and /h properties in a panel XML file; to set the initial x- and y-
offsets (untested), use the panel file's /x-offset and /y-offset
properties; to set the initial height of the external view (untested
and optional), use the panel file's /view-height property. Note that
none of these show up in the regular FGFS property manager.
Unfortunately, these patches will not affect your initialization
problems with the property manager -- I'm having a hard time tracking
them down because I cannot reproduce them.
I have also made some patches to main.cxx and views.cxx to do two
things:
1. Expand or shrink the external view as the panel moves up and down.
2. Set the window ratio correctly, so that we don't get an oval sun
and flat clouds when the panel is visible (the problem before was
integer division, so I added casts).
Unfortunately, the window ratio is not set properly at start-up --
there are too many dependencies, and I haven't figured that part out
yet. As soon as you hide and redisplay the panel or move it
vertically (i.e. force fgReshape to be called), you'll see the correct
ratio.
2000-10-06 21:16:01 +00:00
|
|
|
|
// Search for a matching instrument.
|
2000-09-13 21:51:07 +00:00
|
|
|
|
for (int i = 0; i < (int)_instruments.size(); i++) {
|
2000-04-27 22:45:48 +00:00
|
|
|
|
FGPanelInstrument *inst = _instruments[i];
|
|
|
|
|
int ix = inst->getXPos();
|
|
|
|
|
int iy = inst->getYPos();
|
|
|
|
|
int iw = inst->getWidth() / 2;
|
|
|
|
|
int ih = inst->getHeight() / 2;
|
|
|
|
|
if (x >= ix - iw && x < ix + iw && y >= iy - ih && y < iy + ih) {
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
_mouseDown = true;
|
|
|
|
|
_mouseDelay = 20;
|
|
|
|
|
_mouseInstrument = inst;
|
|
|
|
|
_mouseButton = button;
|
|
|
|
|
_mouseX = x - ix;
|
|
|
|
|
_mouseY = y - iy;
|
|
|
|
|
// Always do the action once.
|
|
|
|
|
_mouseInstrument->doMouseAction(_mouseButton, _mouseX, _mouseY);
|
|
|
|
|
return true;
|
2000-04-27 22:45:48 +00:00
|
|
|
|
}
|
2000-02-26 18:01:13 +00:00
|
|
|
|
}
|
2000-04-27 22:45:48 +00:00
|
|
|
|
return false;
|
|
|
|
|
}
|
2000-02-26 18:01:13 +00:00
|
|
|
|
|
2000-04-27 22:45:48 +00:00
|
|
|
|
|
2000-09-08 20:47:18 +00:00
|
|
|
|
|
|
|
|
|
////////////////////////////////////////////////////////////////////////.
|
|
|
|
|
// Implementation of FGPanelAction.
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
|
|
|
|
|
FGPanelAction::FGPanelAction ()
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
FGPanelAction::FGPanelAction (int button, int x, int y, int w, int h)
|
|
|
|
|
: _button(button), _x(x), _y(y), _w(w), _h(h)
|
|
|
|
|
{
|
2001-08-10 05:16:41 +00:00
|
|
|
|
for (unsigned int i = 0; i < _bindings.size(); i++)
|
|
|
|
|
delete _bindings[i];
|
2000-09-08 20:47:18 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
FGPanelAction::~FGPanelAction ()
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2000-04-27 22:45:48 +00:00
|
|
|
|
void
|
2001-08-10 05:16:41 +00:00
|
|
|
|
FGPanelAction::addBinding (FGBinding * binding)
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
{
|
2001-07-27 21:59:53 +00:00
|
|
|
|
_bindings.push_back(binding);
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2001-07-27 21:59:53 +00:00
|
|
|
|
FGPanelAction::doAction ()
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
{
|
2001-08-03 00:17:58 +00:00
|
|
|
|
if (test()) {
|
|
|
|
|
int nBindings = _bindings.size();
|
|
|
|
|
for (int i = 0; i < nBindings; i++) {
|
2001-08-10 05:16:41 +00:00
|
|
|
|
_bindings[i]->fire();
|
2001-08-03 00:17:58 +00:00
|
|
|
|
}
|
2001-07-27 21:59:53 +00:00
|
|
|
|
}
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2000-09-08 20:47:18 +00:00
|
|
|
|
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
// Implementation of FGPanelTransformation.
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
|
|
|
|
|
FGPanelTransformation::FGPanelTransformation ()
|
2001-05-15 23:08:25 +00:00
|
|
|
|
: table(0)
|
2000-09-08 20:47:18 +00:00
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
FGPanelTransformation::~FGPanelTransformation ()
|
|
|
|
|
{
|
2001-11-30 20:55:14 +00:00
|
|
|
|
delete table;
|
2000-09-08 20:47:18 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
1999-12-23 17:37:18 +00:00
|
|
|
|
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
2000-02-15 03:30:01 +00:00
|
|
|
|
// Implementation of FGPanelInstrument.
|
1999-12-23 17:37:18 +00:00
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
|
|
|
|
|
|
2000-02-15 03:30:01 +00:00
|
|
|
|
FGPanelInstrument::FGPanelInstrument ()
|
1999-12-23 17:37:18 +00:00
|
|
|
|
{
|
2000-02-15 03:30:01 +00:00
|
|
|
|
setPosition(0, 0);
|
|
|
|
|
setSize(0, 0);
|
1999-12-23 17:37:18 +00:00
|
|
|
|
}
|
|
|
|
|
|
2000-02-15 03:30:01 +00:00
|
|
|
|
FGPanelInstrument::FGPanelInstrument (int x, int y, int w, int h)
|
|
|
|
|
{
|
|
|
|
|
setPosition(x, y);
|
|
|
|
|
setSize(w, h);
|
|
|
|
|
}
|
1999-12-23 17:37:18 +00:00
|
|
|
|
|
2000-02-15 03:30:01 +00:00
|
|
|
|
FGPanelInstrument::~FGPanelInstrument ()
|
|
|
|
|
{
|
2000-09-08 20:47:18 +00:00
|
|
|
|
for (action_list_type::iterator it = _actions.begin();
|
|
|
|
|
it != _actions.end();
|
|
|
|
|
it++) {
|
|
|
|
|
delete *it;
|
|
|
|
|
*it = 0;
|
2000-04-27 22:45:48 +00:00
|
|
|
|
}
|
2000-02-15 03:30:01 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
FGPanelInstrument::setPosition (int x, int y)
|
1999-12-23 17:37:18 +00:00
|
|
|
|
{
|
2000-02-15 03:30:01 +00:00
|
|
|
|
_x = x;
|
|
|
|
|
_y = y;
|
1999-12-23 17:37:18 +00:00
|
|
|
|
}
|
|
|
|
|
|
2000-02-15 03:30:01 +00:00
|
|
|
|
void
|
|
|
|
|
FGPanelInstrument::setSize (int w, int h)
|
|
|
|
|
{
|
|
|
|
|
_w = w;
|
|
|
|
|
_h = h;
|
|
|
|
|
}
|
1999-05-12 02:04:38 +00:00
|
|
|
|
|
2000-02-15 03:30:01 +00:00
|
|
|
|
int
|
|
|
|
|
FGPanelInstrument::getXPos () const
|
|
|
|
|
{
|
|
|
|
|
return _x;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int
|
|
|
|
|
FGPanelInstrument::getYPos () const
|
|
|
|
|
{
|
|
|
|
|
return _y;
|
1999-01-07 19:25:53 +00:00
|
|
|
|
}
|
|
|
|
|
|
2000-04-27 22:45:48 +00:00
|
|
|
|
int
|
|
|
|
|
FGPanelInstrument::getWidth () const
|
|
|
|
|
{
|
|
|
|
|
return _w;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int
|
|
|
|
|
FGPanelInstrument::getHeight () const
|
|
|
|
|
{
|
|
|
|
|
return _h;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2000-09-08 20:47:18 +00:00
|
|
|
|
FGPanelInstrument::addAction (FGPanelAction * action)
|
2000-04-27 22:45:48 +00:00
|
|
|
|
{
|
2000-09-08 20:47:18 +00:00
|
|
|
|
_actions.push_back(action);
|
2000-04-27 22:45:48 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Coordinates relative to centre.
|
|
|
|
|
bool
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
FGPanelInstrument::doMouseAction (int button, int x, int y)
|
2000-04-27 22:45:48 +00:00
|
|
|
|
{
|
2001-08-03 00:17:58 +00:00
|
|
|
|
if (test()) {
|
|
|
|
|
action_list_type::iterator it = _actions.begin();
|
|
|
|
|
action_list_type::iterator last = _actions.end();
|
|
|
|
|
for ( ; it != last; it++) {
|
|
|
|
|
if ((*it)->inArea(button, x, y)) {
|
|
|
|
|
(*it)->doAction();
|
|
|
|
|
return true;
|
|
|
|
|
}
|
2000-04-27 22:45:48 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
1998-08-28 18:14:39 +00:00
|
|
|
|
|
1999-12-23 17:37:18 +00:00
|
|
|
|
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
2000-02-21 22:00:24 +00:00
|
|
|
|
// Implementation of FGLayeredInstrument.
|
1999-12-23 17:37:18 +00:00
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
1999-01-07 19:25:53 +00:00
|
|
|
|
|
2000-02-21 22:00:24 +00:00
|
|
|
|
FGLayeredInstrument::FGLayeredInstrument (int x, int y, int w, int h)
|
2000-02-15 03:30:01 +00:00
|
|
|
|
: FGPanelInstrument(x, y, w, h)
|
|
|
|
|
{
|
|
|
|
|
}
|
1999-12-23 17:37:18 +00:00
|
|
|
|
|
2000-02-21 22:00:24 +00:00
|
|
|
|
FGLayeredInstrument::~FGLayeredInstrument ()
|
2000-02-15 03:30:01 +00:00
|
|
|
|
{
|
2000-09-08 20:47:18 +00:00
|
|
|
|
for (layer_list::iterator it = _layers.begin(); it != _layers.end(); it++) {
|
|
|
|
|
delete *it;
|
|
|
|
|
*it = 0;
|
|
|
|
|
}
|
2000-02-15 03:30:01 +00:00
|
|
|
|
}
|
1999-12-23 17:37:18 +00:00
|
|
|
|
|
2000-02-15 03:30:01 +00:00
|
|
|
|
void
|
2000-09-06 00:07:48 +00:00
|
|
|
|
FGLayeredInstrument::draw ()
|
1999-12-23 17:37:18 +00:00
|
|
|
|
{
|
2001-08-03 00:17:58 +00:00
|
|
|
|
if (test()) {
|
|
|
|
|
for (int i = 0; i < (int)_layers.size(); i++) {
|
|
|
|
|
glPushMatrix();
|
Virtual cockpit patches from Andy Ross:
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply the patch (let me know if folks need help with that step), and
then set the /sim/virtual-cockpit property to true. You can do this
on the command line with --prop:/sim/virtual-cockpit=1, or via the
property picker. Bind it to a key for fast toggling if you like.
The default bindings don't allow for "panning" the view, so you'll
have to modify yours. These are the mappings to my joystick's hat
switch, for those who need hints:
<axis n="6">
<desc>View Direction</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-offset-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
<axis n="7">
<desc>View Elevation</desc>
<low>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">1.0</step>
</binding>
</low>
<high>
<repeatable>true</repeatable>
<binding>
<command>property-adjust</command>
<property>/sim/view/goal-tilt-deg</property>
<step type="double">-1.0</step>
</binding>
</high>
</axis>
While the current implementation is happy with just plastering the
panel's notion of "screen" into the 3D world, this is actually more
general. Each panel can, in principle, have it's own coordinate
system, and you could build a cockpit out of a bunch of them. The
mapping is specified by providing a 3D coordinate for three corners of
the quad the panel should be mapped to; this should be pretty simple
to work with.
All that's needed for a perfectly general solution is a convention on
where to store the information (a cockpit xml file, or put it in the
aircraft -set file, or...), and some work on the panel's coordinate
system conventions (some of which don't coexist very nicely with a
generalized 3D environment). Combine that with a plib model for the
non-panel interior of the cockpit, and we're golden.
I'm actually really pleased with this. It worked better and more
quickly than I could have imagined, and impact on the surrounding code
is quite light -- a few property tests only. But some stuff is still
missing:
+ No equivalent work was done to the HUD, so it still displays
incorrect headings when the view changes. The use of pixel
coordinates deep in the HUD code is going to give me fits doing the
port, I sure. It's not nearly so well put together as the panel
(where I just changed the setup code -- none of the rendering code
changed at all).
+ I forgot that the panel was clickable. :) Input events still have
the screen coordinates, which essentially kills the interactivity
when in virtual cockpit mode. This won't be hard to fix; it's only
broken because I forgot the feature existed.
And one note about the implementation choice: to get away from the
inevitable near clip plane issue, the virtual cockpit renderer simply
disables the z buffer. This means that cockpits built using these
panels need to be z-sorted, which isn't too hard since they are static
geometry. It also means that no two "virtual panels" can ever be
allowed to interpenetrate. No biggie.
2002-03-03 00:06:24 +00:00
|
|
|
|
if(!fgGetBool("/sim/virtual-cockpit"))
|
|
|
|
|
glTranslatef(0.0, 0.0, (i / 100.0) + 0.1);
|
2001-08-03 00:17:58 +00:00
|
|
|
|
_layers[i]->draw();
|
|
|
|
|
glPopMatrix();
|
|
|
|
|
}
|
2000-02-21 22:00:24 +00:00
|
|
|
|
}
|
1999-12-23 17:37:18 +00:00
|
|
|
|
}
|
|
|
|
|
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
int
|
2000-02-21 22:00:24 +00:00
|
|
|
|
FGLayeredInstrument::addLayer (FGInstrumentLayer *layer)
|
1999-12-23 17:37:18 +00:00
|
|
|
|
{
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
int n = _layers.size();
|
2000-06-14 20:59:51 +00:00
|
|
|
|
if (layer->getWidth() == -1) {
|
|
|
|
|
layer->setWidth(getWidth());
|
|
|
|
|
}
|
|
|
|
|
if (layer->getHeight() == -1) {
|
|
|
|
|
layer->setHeight(getHeight());
|
|
|
|
|
}
|
2000-02-21 22:00:24 +00:00
|
|
|
|
_layers.push_back(layer);
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
return n;
|
1998-08-28 18:14:39 +00:00
|
|
|
|
}
|
|
|
|
|
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
int
|
2000-09-22 17:20:56 +00:00
|
|
|
|
FGLayeredInstrument::addLayer (FGCroppedTexture &texture,
|
2000-09-13 21:51:07 +00:00
|
|
|
|
int w, int h)
|
2000-02-15 03:30:01 +00:00
|
|
|
|
{
|
2000-06-14 20:59:51 +00:00
|
|
|
|
return addLayer(new FGTexturedLayer(texture, w, h));
|
2000-02-15 03:30:01 +00:00
|
|
|
|
}
|
1999-01-07 19:25:53 +00:00
|
|
|
|
|
2000-02-15 03:30:01 +00:00
|
|
|
|
void
|
2000-09-08 20:47:18 +00:00
|
|
|
|
FGLayeredInstrument::addTransformation (FGPanelTransformation * transformation)
|
2000-02-15 03:30:01 +00:00
|
|
|
|
{
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
int layer = _layers.size() - 1;
|
2000-09-08 20:47:18 +00:00
|
|
|
|
_layers[layer]->addTransformation(transformation);
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
}
|
|
|
|
|
|
1999-12-23 17:37:18 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
2000-02-21 22:00:24 +00:00
|
|
|
|
// Implementation of FGInstrumentLayer.
|
1999-12-23 17:37:18 +00:00
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
FGInstrumentLayer::FGInstrumentLayer (int w, int h)
|
2000-02-21 22:00:24 +00:00
|
|
|
|
: _w(w),
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
_h(h)
|
2000-02-15 03:30:01 +00:00
|
|
|
|
{
|
1999-05-06 22:16:12 +00:00
|
|
|
|
}
|
1999-02-12 01:46:29 +00:00
|
|
|
|
|
2000-02-21 22:00:24 +00:00
|
|
|
|
FGInstrumentLayer::~FGInstrumentLayer ()
|
2000-02-15 03:30:01 +00:00
|
|
|
|
{
|
2000-09-08 20:47:18 +00:00
|
|
|
|
for (transformation_list::iterator it = _transformations.begin();
|
|
|
|
|
it != _transformations.end();
|
|
|
|
|
it++) {
|
2000-02-21 22:00:24 +00:00
|
|
|
|
delete *it;
|
2000-09-08 20:47:18 +00:00
|
|
|
|
*it = 0;
|
2000-02-21 22:00:24 +00:00
|
|
|
|
}
|
1999-12-23 17:37:18 +00:00
|
|
|
|
}
|
|
|
|
|
|
2000-02-15 03:30:01 +00:00
|
|
|
|
void
|
2000-02-21 22:00:24 +00:00
|
|
|
|
FGInstrumentLayer::transform () const
|
|
|
|
|
{
|
|
|
|
|
transformation_list::const_iterator it = _transformations.begin();
|
|
|
|
|
transformation_list::const_iterator last = _transformations.end();
|
|
|
|
|
while (it != last) {
|
2000-09-08 20:47:18 +00:00
|
|
|
|
FGPanelTransformation *t = *it;
|
2001-08-03 00:17:58 +00:00
|
|
|
|
if (t->test()) {
|
|
|
|
|
float val = (t->node == 0 ? 0.0 : t->node->getFloatValue());
|
|
|
|
|
if (val < t->min) {
|
|
|
|
|
val = t->min;
|
|
|
|
|
} else if (val > t->max) {
|
|
|
|
|
val = t->max;
|
|
|
|
|
}
|
|
|
|
|
if(t->table==0) {
|
2001-05-15 23:08:25 +00:00
|
|
|
|
val = val * t->factor + t->offset;
|
2001-08-03 00:17:58 +00:00
|
|
|
|
} else {
|
2001-05-15 23:08:25 +00:00
|
|
|
|
val = t->table->interpolate(val) * t->factor + t->offset;
|
2001-08-03 00:17:58 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (t->type) {
|
|
|
|
|
case FGPanelTransformation::XSHIFT:
|
|
|
|
|
glTranslatef(val, 0.0, 0.0);
|
|
|
|
|
break;
|
|
|
|
|
case FGPanelTransformation::YSHIFT:
|
|
|
|
|
glTranslatef(0.0, val, 0.0);
|
|
|
|
|
break;
|
|
|
|
|
case FGPanelTransformation::ROTATION:
|
|
|
|
|
glRotatef(-val, 0.0, 0.0, 1.0);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2000-02-21 22:00:24 +00:00
|
|
|
|
}
|
|
|
|
|
it++;
|
2000-02-15 03:30:01 +00:00
|
|
|
|
}
|
1998-11-09 23:38:50 +00:00
|
|
|
|
}
|
|
|
|
|
|
2000-02-15 03:30:01 +00:00
|
|
|
|
void
|
2000-09-08 20:47:18 +00:00
|
|
|
|
FGInstrumentLayer::addTransformation (FGPanelTransformation * transformation)
|
1999-12-23 17:37:18 +00:00
|
|
|
|
{
|
2000-09-08 20:47:18 +00:00
|
|
|
|
_transformations.push_back(transformation);
|
1999-05-06 22:16:12 +00:00
|
|
|
|
}
|
1999-05-12 02:04:38 +00:00
|
|
|
|
|
1999-12-23 17:37:18 +00:00
|
|
|
|
|
2001-08-03 00:17:58 +00:00
|
|
|
|
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
// Implementation of FGGroupLayer.
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
|
|
|
|
|
FGGroupLayer::FGGroupLayer ()
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
FGGroupLayer::~FGGroupLayer ()
|
|
|
|
|
{
|
2001-08-10 05:16:41 +00:00
|
|
|
|
for (unsigned int i = 0; i < _layers.size(); i++)
|
2001-08-03 00:17:58 +00:00
|
|
|
|
delete _layers[i];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
FGGroupLayer::draw ()
|
|
|
|
|
{
|
|
|
|
|
if (test()) {
|
|
|
|
|
int nLayers = _layers.size();
|
|
|
|
|
for (int i = 0; i < nLayers; i++)
|
|
|
|
|
_layers[i]->draw();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
FGGroupLayer::addLayer (FGInstrumentLayer * layer)
|
|
|
|
|
{
|
|
|
|
|
_layers.push_back(layer);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
1999-12-23 17:37:18 +00:00
|
|
|
|
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
// Implementation of FGTexturedLayer.
|
1999-12-23 17:37:18 +00:00
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
|
2000-06-14 20:59:51 +00:00
|
|
|
|
|
2000-09-22 17:20:56 +00:00
|
|
|
|
FGTexturedLayer::FGTexturedLayer (const FGCroppedTexture &texture, int w, int h)
|
2000-09-06 00:07:48 +00:00
|
|
|
|
: FGInstrumentLayer(w, h)
|
1999-12-23 17:37:18 +00:00
|
|
|
|
{
|
2000-09-06 00:07:48 +00:00
|
|
|
|
setTexture(texture);
|
1999-05-06 22:16:12 +00:00
|
|
|
|
}
|
1999-05-12 02:04:38 +00:00
|
|
|
|
|
2000-09-06 00:07:48 +00:00
|
|
|
|
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
FGTexturedLayer::~FGTexturedLayer ()
|
1999-12-23 17:37:18 +00:00
|
|
|
|
{
|
1999-05-06 22:16:12 +00:00
|
|
|
|
}
|
1999-05-12 02:04:38 +00:00
|
|
|
|
|
2000-09-06 00:07:48 +00:00
|
|
|
|
|
2000-02-15 03:30:01 +00:00
|
|
|
|
void
|
2000-09-06 00:07:48 +00:00
|
|
|
|
FGTexturedLayer::draw ()
|
1999-12-23 17:37:18 +00:00
|
|
|
|
{
|
2001-08-03 00:17:58 +00:00
|
|
|
|
if (test()) {
|
|
|
|
|
int w2 = _w / 2;
|
|
|
|
|
int h2 = _h / 2;
|
|
|
|
|
|
|
|
|
|
transform();
|
|
|
|
|
glBindTexture(GL_TEXTURE_2D, _texture.getTexture()->getHandle());
|
|
|
|
|
glBegin(GL_POLYGON);
|
|
|
|
|
|
2000-09-22 17:20:56 +00:00
|
|
|
|
// From Curt: turn on the panel
|
|
|
|
|
// lights after sundown.
|
2001-08-03 00:17:58 +00:00
|
|
|
|
if ( cur_light_params.sun_angle * SGD_RADIANS_TO_DEGREES < 95.0 ) {
|
2000-05-27 06:40:55 +00:00
|
|
|
|
glColor4fv( cur_light_params.scene_diffuse );
|
2001-08-03 00:17:58 +00:00
|
|
|
|
} else {
|
2000-05-27 06:40:55 +00:00
|
|
|
|
glColor4f(0.7, 0.2, 0.2, 1.0);
|
2001-08-03 00:17:58 +00:00
|
|
|
|
}
|
2000-09-22 17:20:56 +00:00
|
|
|
|
|
|
|
|
|
|
2001-08-03 00:17:58 +00:00
|
|
|
|
glTexCoord2f(_texture.getMinX(), _texture.getMinY()); glVertex2f(-w2, -h2);
|
|
|
|
|
glTexCoord2f(_texture.getMaxX(), _texture.getMinY()); glVertex2f(w2, -h2);
|
|
|
|
|
glTexCoord2f(_texture.getMaxX(), _texture.getMaxY()); glVertex2f(w2, h2);
|
|
|
|
|
glTexCoord2f(_texture.getMinX(), _texture.getMaxY()); glVertex2f(-w2, h2);
|
|
|
|
|
glEnd();
|
|
|
|
|
}
|
2000-02-15 03:30:01 +00:00
|
|
|
|
}
|
1999-12-23 17:37:18 +00:00
|
|
|
|
|
|
|
|
|
|
2000-02-15 03:30:01 +00:00
|
|
|
|
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
// Implementation of FGTextLayer.
|
2000-02-15 03:30:01 +00:00
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
|
2000-09-30 03:35:38 +00:00
|
|
|
|
FGTextLayer::FGTextLayer (int w, int h)
|
2002-02-19 23:54:17 +00:00
|
|
|
|
: FGInstrumentLayer(w, h), _pointSize(14.0), _font_name("default")
|
2000-02-15 03:30:01 +00:00
|
|
|
|
{
|
2000-09-30 03:35:38 +00:00
|
|
|
|
_then.stamp();
|
2000-02-21 22:00:24 +00:00
|
|
|
|
_color[0] = _color[1] = _color[2] = 0.0;
|
2000-03-17 06:16:15 +00:00
|
|
|
|
_color[3] = 1.0;
|
2000-02-15 03:30:01 +00:00
|
|
|
|
}
|
|
|
|
|
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
FGTextLayer::~FGTextLayer ()
|
2000-02-15 03:30:01 +00:00
|
|
|
|
{
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
chunk_list::iterator it = _chunks.begin();
|
|
|
|
|
chunk_list::iterator last = _chunks.end();
|
|
|
|
|
for ( ; it != last; it++) {
|
|
|
|
|
delete *it;
|
|
|
|
|
}
|
2000-02-15 03:30:01 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2000-09-06 00:07:48 +00:00
|
|
|
|
FGTextLayer::draw ()
|
2000-02-15 03:30:01 +00:00
|
|
|
|
{
|
2001-08-03 00:17:58 +00:00
|
|
|
|
if (test()) {
|
|
|
|
|
glPushMatrix();
|
|
|
|
|
glColor4fv(_color);
|
|
|
|
|
transform();
|
2002-02-19 23:54:17 +00:00
|
|
|
|
if ( _font_name == "led" ) {
|
|
|
|
|
text_renderer.setFont(led_font);
|
|
|
|
|
} else {
|
|
|
|
|
text_renderer.setFont(guiFntHandle);
|
|
|
|
|
}
|
2001-08-03 00:17:58 +00:00
|
|
|
|
text_renderer.setPointSize(_pointSize);
|
|
|
|
|
text_renderer.begin();
|
|
|
|
|
text_renderer.start3f(0, 0, 0);
|
|
|
|
|
|
|
|
|
|
_now.stamp();
|
|
|
|
|
if (_now - _then > 100000) {
|
|
|
|
|
recalc_value();
|
|
|
|
|
_then = _now;
|
|
|
|
|
}
|
|
|
|
|
text_renderer.puts((char *)(_value.c_str()));
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
|
2001-08-03 00:17:58 +00:00
|
|
|
|
text_renderer.end();
|
|
|
|
|
glColor4f(1.0, 1.0, 1.0, 1.0); // FIXME
|
|
|
|
|
glPopMatrix();
|
|
|
|
|
}
|
2000-02-15 03:30:01 +00:00
|
|
|
|
}
|
1999-12-23 17:37:18 +00:00
|
|
|
|
|
2000-02-15 03:30:01 +00:00
|
|
|
|
void
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
FGTextLayer::addChunk (FGTextLayer::Chunk * chunk)
|
|
|
|
|
{
|
|
|
|
|
_chunks.push_back(chunk);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
FGTextLayer::setColor (float r, float g, float b)
|
1999-12-23 17:37:18 +00:00
|
|
|
|
{
|
2000-02-21 22:00:24 +00:00
|
|
|
|
_color[0] = r;
|
|
|
|
|
_color[1] = g;
|
|
|
|
|
_color[2] = b;
|
2000-03-17 06:16:15 +00:00
|
|
|
|
_color[3] = 1.0;
|
1999-12-23 17:37:18 +00:00
|
|
|
|
}
|
|
|
|
|
|
2000-02-21 22:00:24 +00:00
|
|
|
|
void
|
2000-09-13 21:51:07 +00:00
|
|
|
|
FGTextLayer::setPointSize (float size)
|
2000-02-15 03:30:01 +00:00
|
|
|
|
{
|
2000-09-13 21:51:07 +00:00
|
|
|
|
_pointSize = size;
|
2000-02-15 03:30:01 +00:00
|
|
|
|
}
|
1999-12-23 17:37:18 +00:00
|
|
|
|
|
2002-02-19 23:54:17 +00:00
|
|
|
|
void
|
|
|
|
|
FGTextLayer::setFontName(const string &name)
|
|
|
|
|
{
|
|
|
|
|
_font_name = name;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2000-02-15 03:30:01 +00:00
|
|
|
|
void
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
FGTextLayer::setFont(fntFont * font)
|
1999-12-23 17:37:18 +00:00
|
|
|
|
{
|
2000-09-30 03:35:38 +00:00
|
|
|
|
text_renderer.setFont(font);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
FGTextLayer::recalc_value () const
|
|
|
|
|
{
|
|
|
|
|
_value = "";
|
|
|
|
|
chunk_list::const_iterator it = _chunks.begin();
|
|
|
|
|
chunk_list::const_iterator last = _chunks.end();
|
|
|
|
|
for ( ; it != last; it++) {
|
|
|
|
|
_value += (*it)->getValue();
|
|
|
|
|
}
|
1999-05-06 22:16:12 +00:00
|
|
|
|
}
|
2000-02-15 03:30:01 +00:00
|
|
|
|
|
|
|
|
|
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
// Implementation of FGTextLayer::Chunk.
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
|
2000-09-13 21:51:07 +00:00
|
|
|
|
FGTextLayer::Chunk::Chunk (const string &text, const string &fmt)
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
: _type(FGTextLayer::TEXT), _fmt(fmt)
|
|
|
|
|
{
|
2000-09-13 21:51:07 +00:00
|
|
|
|
_text = text;
|
|
|
|
|
if (_fmt == "")
|
|
|
|
|
_fmt = "%s";
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
}
|
|
|
|
|
|
2001-06-12 05:15:48 +00:00
|
|
|
|
FGTextLayer::Chunk::Chunk (ChunkType type, const SGPropertyNode * node,
|
2000-09-13 21:51:07 +00:00
|
|
|
|
const string &fmt, float mult)
|
2000-09-06 00:07:48 +00:00
|
|
|
|
: _type(type), _fmt(fmt), _mult(mult)
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
{
|
2000-09-13 21:51:07 +00:00
|
|
|
|
if (_fmt == "") {
|
2000-09-06 00:07:48 +00:00
|
|
|
|
if (type == TEXT_VALUE)
|
|
|
|
|
_fmt = "%s";
|
|
|
|
|
else
|
|
|
|
|
_fmt = "%.2f";
|
|
|
|
|
}
|
2001-06-12 05:15:48 +00:00
|
|
|
|
_node = node;
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
}
|
|
|
|
|
|
2000-09-13 21:51:07 +00:00
|
|
|
|
const char *
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
FGTextLayer::Chunk::getValue () const
|
|
|
|
|
{
|
2001-08-03 00:17:58 +00:00
|
|
|
|
if (test()) {
|
|
|
|
|
switch (_type) {
|
|
|
|
|
case TEXT:
|
|
|
|
|
sprintf(_buf, _fmt.c_str(), _text.c_str());
|
|
|
|
|
return _buf;
|
|
|
|
|
case TEXT_VALUE:
|
2002-03-19 17:12:13 +00:00
|
|
|
|
sprintf(_buf, _fmt.c_str(), _node->getStringValue());
|
2001-08-03 00:17:58 +00:00
|
|
|
|
break;
|
|
|
|
|
case DOUBLE_VALUE:
|
|
|
|
|
sprintf(_buf, _fmt.c_str(), _node->getFloatValue() * _mult);
|
|
|
|
|
break;
|
|
|
|
|
}
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
return _buf;
|
2001-08-03 00:17:58 +00:00
|
|
|
|
} else {
|
|
|
|
|
return "";
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
// Implementation of FGSwitchLayer.
|
|
|
|
|
////////////////////////////////////////////////////////////////////////
|
|
|
|
|
|
2001-06-12 05:15:48 +00:00
|
|
|
|
FGSwitchLayer::FGSwitchLayer (int w, int h, const SGPropertyNode * node,
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
FGInstrumentLayer * layer1,
|
|
|
|
|
FGInstrumentLayer * layer2)
|
2001-06-12 05:15:48 +00:00
|
|
|
|
: FGInstrumentLayer(w, h), _node(node), _layer1(layer1), _layer2(layer2)
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
FGSwitchLayer::~FGSwitchLayer ()
|
|
|
|
|
{
|
|
|
|
|
delete _layer1;
|
|
|
|
|
delete _layer2;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2000-09-06 00:07:48 +00:00
|
|
|
|
FGSwitchLayer::draw ()
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
{
|
2001-08-03 00:17:58 +00:00
|
|
|
|
if (test()) {
|
|
|
|
|
transform();
|
|
|
|
|
if (_node->getBoolValue()) {
|
|
|
|
|
_layer1->draw();
|
|
|
|
|
} else {
|
|
|
|
|
_layer2->draw();
|
|
|
|
|
}
|
User-visible
- knobs now continue to rotate when you hold down the mouse
- the middle mouse button makes knobs rotate much faster
- there are NAV1, NAV2, and ADF radios that can be tuned using the mouse
- there are standby frequencies for NAV1 and NAV2, and buttons to swap
- there is a crude, rather silly-looking DME, hard-wired to NAV1
- there is a crude, rather silly-looking autopilot that can lock
the heading (to the bug on the gyro), can lock to NAV1, and can lock
the current altitude
- the knobs for changing the radials on NAV1 and NAV2 look much better
and are in the right place
- tuning into an ILS frequency doesn't change the displayed radial for
NAV1
Code
- I've created a new module, sp_panel.[ch]xx, that constructs the
default single-prop panel; this works entirely outside of FGPanel,
so it is possible to construct similar modules for other sorts of
panels; all code specific to the default panel has been removed from
panel.cxx
- current_panel is now a pointer
- radiostack.[ch]xx keeps track both of the actual radial and of the
selected radial (they will differ with ILS); the NAV gauges should
not spin around automatically to show the actual radial (we need to
do something similar with the autopilot)
- the panel is initialized fairly early
- make sure that standby frequencies also get initialized
- I've started combining and clipping small textures to save texture
memory; there's a lot more to do, but at least I've made a start
2000-05-02 18:26:00 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2000-02-15 03:30:01 +00:00
|
|
|
|
|
|
|
|
|
// end of panel.cxx
|
2002-02-19 21:57:09 +00:00
|
|
|
|
|
|
|
|
|
|
Major viewer-code overhaul from Jim Wilson:
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.
2002-03-20 17:43:28 +00:00
|
|
|
|
|