1
0
Fork 0
flightgear/src/Cockpit/panel.cxx

1160 lines
27 KiB
C++
Raw Normal View History

2000-02-15 03:30:01 +00:00
// panel.cxx - default, 2D single-engine prop instrument panel
//
2000-02-15 03:30:01 +00:00
// Written by David Megginson, started January 2000.
//
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.
//
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.
//
2000-02-15 03:30:01 +00:00
// $Id$
#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>
2000-02-15 03:30:01 +00:00
#include <plib/ssg.h>
#include <plib/fnt.h>
2000-02-16 23:01:03 +00:00
#include <simgear/debug/logstream.hxx>
#include <simgear/misc/sg_path.hxx>
#include <Main/globals.hxx>
#include <Main/fg_props.hxx>
#include <Main/viewmgr.hxx>
#include <Time/light.hxx>
#include "hud.hxx"
#include "panel.hxx"
#define WIN_X 0
#define WIN_Y 0
#define WIN_W 1024
#define WIN_H 768
3D panel support from Andy Ross: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. [and later] OK, this is fixed by the attached panel.cxx file. What's happened is that the winding order for the text layer's polygons is wrong, so I reverse it before drawing. That's largely a hatchet job to make things work for now, though. We should figure out why the winding order is wrong for only text layers and fix it. I checked the plib sources -- they're definitely doing things CCW, as is all the rest of the panel code. Odd. I'm also not sure why the 2D panel doesn't care (it works in both winding orders). But this will allow you to check in working code, anyway. There's a big comment to this effect in there.
2002-06-28 14:17:40 +00:00
// The number of polygon-offset "units" to place between layers. In
// principle, one is supposed to be enough. In practice, I find that
// my hardware/driver requires many more.
#define POFF_UNITS 4
3D panel support from Andy Ross: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. [and later] OK, this is fixed by the attached panel.cxx file. What's happened is that the winding order for the text layer's polygons is wrong, so I reverse it before drawing. That's largely a hatchet job to make things work for now, though. We should figure out why the winding order is wrong for only text layers and fix it. I checked the plib sources -- they're definitely doing things CCW, as is all the rest of the panel code. Odd. I'm also not sure why the 2D panel doesn't care (it works in both winding orders). But this will allow you to check in working code, anyway. There's a big comment to this effect in there.
2002-06-28 14:17:40 +00:00
////////////////////////////////////////////////////////////////////////
// Local functions.
////////////////////////////////////////////////////////////////////////
/**
* Calculate the aspect adjustment for the panel.
*/
static float
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.
////////////////////////////////////////////////////////////////////////
bool
fgPanelVisible ()
{
2003-03-30 12:46:08 +00:00
if(globals->get_current_panel() == 0)
return false;
2003-03-30 12:46:08 +00:00
if(globals->get_current_panel()->getVisibility() == 0)
return false;
if(globals->get_viewmgr()->get_current() != 0)
return false;
3D panel support from Andy Ross: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. [and later] OK, this is fixed by the attached panel.cxx file. What's happened is that the winding order for the text layer's polygons is wrong, so I reverse it before drawing. That's largely a hatchet job to make things work for now, though. We should figure out why the winding order is wrong for only text layers and fix it. I checked the plib sources -- they're definitely doing things CCW, as is all the rest of the panel code. Odd. I'm also not sure why the 2D panel doesn't care (it works in both winding orders). But this will allow you to check in working code, anyway. There's a big comment to this effect in there.
2002-06-28 14:17:40 +00:00
if(globals->get_current_view()->getHeadingOffset_deg() * SGD_DEGREES_TO_RADIANS != 0)
return false;
return true;
}
////////////////////////////////////////////////////////////////////////
// Implementation of FGTextureManager.
////////////////////////////////////////////////////////////////////////
map<string,ssgTexture *> FGTextureManager::_textureMap;
ssgTexture *
FGTextureManager::createTexture (const string &relativePath)
{
ssgTexture * texture = _textureMap[relativePath];
if (texture == 0) {
2001-06-01 17:55:49 +00:00
SG_LOG( SG_COCKPIT, SG_DEBUG,
"Texture " << relativePath << " does not yet exist" );
SGPath tpath(globals->get_fg_root());
tpath.append(relativePath);
texture = new ssgTexture((char *)tpath.c_str(), false, false);
_textureMap[relativePath] = texture;
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() );
}
return texture;
}
////////////////////////////////////////////////////////////////////////
// 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;
}
////////////////////////////////////////////////////////////////////////
// Implementation of FGPanel.
////////////////////////////////////////////////////////////////////////
static fntRenderer text_renderer;
static fntTexFont *default_font = 0;
static fntTexFont *led_font = 0;
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.
*/
FGPanel::FGPanel ()
: _mouseDown(false),
_mouseInstrument(0),
_width(WIN_W), _height(int(WIN_H * 0.5768 + 1)),
2003-03-30 16:49:48 +00:00
_view_height(int(WIN_H * 0.4232)),
_visibility(fgGetNode("/sim/panel/visibility", true)),
_x_offset(fgGetNode("/sim/panel/x-offset", true)),
_y_offset(fgGetNode("/sim/panel/y-offset", true)),
_jitter(fgGetNode("/sim/panel/jitter", true)),
_flipx(fgGetNode("/sim/panel/flip-x", true)),
_xsize_node(fgGetNode("/sim/startup/xsize", true)),
_ysize_node(fgGetNode("/sim/startup/ysize", true))
2000-02-15 03:30:01 +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.
*/
FGPanel::~FGPanel ()
{
for (instrument_list_type::iterator it = _instruments.begin();
it != _instruments.end();
it++) {
delete *it;
*it = 0;
2000-02-15 03:30:01 +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.
*/
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
/**
* Initialize the panel.
*/
void
FGPanel::init ()
{
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() ) ;
}
/**
* Bind panel properties.
*/
void
FGPanel::bind ()
{
fgSetArchivable("/sim/panel/visibility");
fgSetArchivable("/sim/panel/x-offset");
fgSetArchivable("/sim/panel/y-offset");
fgSetArchivable("/sim/panel/jitter");
}
/**
* 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
FGPanel::update (double dt)
2000-02-15 03:30:01 +00:00
{
// Do nothing if the panel isn't visible.
2001-10-29 04:37:24 +00:00
if ( !fgPanelVisible() ) {
return;
2001-10-29 04:37:24 +00:00
}
2002-10-29 19:44:03 +00:00
updateMouseDelay();
// Now, draw the panel
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));
}
2002-10-29 19:44:03 +00:00
/**
* Handle repeatable mouse events. Called from update() and from
* fgUpdate3DPanels(). This functionality needs to move into the
* input subsystem. Counting a tick every two frames is clumsy...
*/
void FGPanel::updateMouseDelay()
{
if (_mouseDown) {
_mouseDelay--;
if (_mouseDelay < 0) {
_mouseInstrument->doMouseAction(_mouseButton, 0, _mouseX, _mouseY);
2002-10-29 19:44:03 +00:00
_mouseDelay = 2;
}
}
}
void
FGPanel::update (GLfloat winx, GLfloat winw, GLfloat winy, GLfloat winh)
{
// Calculate accelerations
// and jiggle the panel accordingly
// The factors and bounds are just
// initial guesses; using sqrt smooths
// out the spikes.
2003-03-30 16:49:48 +00:00
double x_offset = _x_offset->getIntValue();
double y_offset = _y_offset->getIntValue();
3D panel support from Andy Ross: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. [and later] OK, this is fixed by the attached panel.cxx file. What's happened is that the winding order for the text layer's polygons is wrong, so I reverse it before drawing. That's largely a hatchet job to make things work for now, though. We should figure out why the winding order is wrong for only text layers and fix it. I checked the plib sources -- they're definitely doing things CCW, as is all the rest of the panel code. Odd. I'm also not sure why the 2D panel doesn't care (it works in both winding orders). But this will allow you to check in working code, anyway. There's a big comment to this effect in there.
2002-06-28 14:17:40 +00:00
#if 0
2003-03-30 16:49:48 +00:00
if (_jitter->getFloatValue() != 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;
2003-03-30 16:49:48 +00:00
int x_adjust = int(sqrt(fabs(a_y_pilot) * _jitter->getFloatValue())) *
(a_y_pilot < 0 ? -1 : 1);
2003-03-30 16:49:48 +00:00
int y_adjust = int(sqrt(fabs(a_zx_pilot) * _jitter->getFloatValue())) *
(a_zx_pilot < 0 ? -1 : 1);
// adjustments in screen coordinates
x_offset += x_adjust;
y_offset += y_adjust;
}
3D panel support from Andy Ross: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. [and later] OK, this is fixed by the attached panel.cxx file. What's happened is that the winding order for the text layer's polygons is wrong, so I reverse it before drawing. That's largely a hatchet job to make things work for now, though. We should figure out why the winding order is wrong for only text layers and fix it. I checked the plib sources -- they're definitely doing things CCW, as is all the rest of the panel code. Odd. I'm also not sure why the 2D panel doesn't care (it works in both winding orders). But this will allow you to check in working code, anyway. There's a big comment to this effect in there.
2002-06-28 14:17:40 +00:00
#endif
3D panel support from Andy Ross: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. [and later] OK, this is fixed by the attached panel.cxx file. What's happened is that the winding order for the text layer's polygons is wrong, so I reverse it before drawing. That's largely a hatchet job to make things work for now, though. We should figure out why the winding order is wrong for only text layers and fix it. I checked the plib sources -- they're definitely doing things CCW, as is all the rest of the panel code. Odd. I'm also not sure why the 2D panel doesn't care (it works in both winding orders). But this will allow you to check in working code, anyway. There's a big comment to this effect in there.
2002-06-28 14:17:40 +00:00
glMatrixMode(GL_PROJECTION);
glPushMatrix();
glLoadIdentity();
2003-03-30 16:49:48 +00:00
if ( _flipx->getBoolValue() ) {
gluOrtho2D(winx + winw, winx, winy + winh, winy); /* up side down */
} else {
gluOrtho2D(winx, winx + winw, winy, winy + winh); /* right side up */
}
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
3D panel support from Andy Ross: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. [and later] OK, this is fixed by the attached panel.cxx file. What's happened is that the winding order for the text layer's polygons is wrong, so I reverse it before drawing. That's largely a hatchet job to make things work for now, though. We should figure out why the winding order is wrong for only text layers and fix it. I checked the plib sources -- they're definitely doing things CCW, as is all the rest of the panel code. Odd. I'm also not sure why the 2D panel doesn't care (it works in both winding orders). But this will allow you to check in working code, anyway. There's a big comment to this effect in there.
2002-06-28 14:17:40 +00:00
glMatrixMode(GL_MODELVIEW);
glPushMatrix();
glLoadIdentity();
glTranslated(x_offset, y_offset, 0);
draw();
glMatrixMode(GL_PROJECTION);
glPopMatrix();
glMatrixMode(GL_MODELVIEW);
glPopMatrix();
ssgForceBasicState();
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
}
void
FGPanel::draw()
{
// In 3D mode, it's possible that we are being drawn exactly on top
// of an existing polygon. Use an offset to prevent z-fighting. In
// 2D mode, this is a no-op.
glEnable(GL_POLYGON_OFFSET_FILL);
glPolygonOffset(-1, -POFF_UNITS);
3D panel support from Andy Ross: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. [and later] OK, this is fixed by the attached panel.cxx file. What's happened is that the winding order for the text layer's polygons is wrong, so I reverse it before drawing. That's largely a hatchet job to make things work for now, though. We should figure out why the winding order is wrong for only text layers and fix it. I checked the plib sources -- they're definitely doing things CCW, as is all the rest of the panel code. Odd. I'm also not sure why the 2D panel doesn't care (it works in both winding orders). But this will allow you to check in working code, anyway. There's a big comment to this effect in there.
2002-06-28 14:17:40 +00:00
// save some state
glPushAttrib( GL_COLOR_BUFFER_BIT | GL_ENABLE_BIT | GL_LIGHTING_BIT
| GL_TEXTURE_BIT | GL_PIXEL_MODE_BIT | GL_CULL_FACE
| GL_DEPTH_BUFFER_BIT );
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
// Draw the background
2000-02-15 03:30:01 +00:00
glEnable(GL_TEXTURE_2D);
glDisable(GL_LIGHTING);
2000-03-17 06:16:15 +00:00
glEnable(GL_BLEND);
glEnable(GL_ALPHA_TEST);
glEnable(GL_COLOR_MATERIAL);
glEnable(GL_CULL_FACE);
glCullFace(GL_BACK);
glDisable(GL_DEPTH_TEST);
sgVec4 panel_color;
FGLight *l = (FGLight *)(globals->get_subsystem("lighting"));
sgCopyVec4( panel_color, l->scene_diffuse());
if ( fgGetDouble("/systems/electrical/outputs/instrument-lights") > 1.0 ) {
if ( panel_color[0] < 0.7 ) panel_color[0] = 0.7;
if ( panel_color[1] < 0.2 ) panel_color[1] = 0.2;
if ( panel_color[2] < 0.2 ) panel_color[2] = 0.2;
2000-05-27 06:40:55 +00:00
}
glColor4fv( panel_color );
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);
3D panel support from Andy Ross: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. [and later] OK, this is fixed by the attached panel.cxx file. What's happened is that the winding order for the text layer's polygons is wrong, so I reverse it before drawing. That's largely a hatchet job to make things work for now, though. We should figure out why the winding order is wrong for only text layers and fix it. I checked the plib sources -- they're definitely doing things CCW, as is all the rest of the panel code. Odd. I'm also not sure why the 2D panel doesn't care (it works in both winding orders). But this will allow you to check in working code, anyway. There's a big comment to this effect in there.
2002-06-28 14:17:40 +00:00
glTexCoord2f(0.0, 0.0); glVertex2f(WIN_X, WIN_Y);
glTexCoord2f(1.0, 0.0); glVertex2f(WIN_X + _width, WIN_Y);
glTexCoord2f(1.0, 1.0); glVertex2f(WIN_X + _width, WIN_Y + _height);
glTexCoord2f(0.0, 1.0); glVertex2f(WIN_X, WIN_Y + _height);
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);
3D panel support from Andy Ross: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. [and later] OK, this is fixed by the attached panel.cxx file. What's happened is that the winding order for the text layer's polygons is wrong, so I reverse it before drawing. That's largely a hatchet job to make things work for now, though. We should figure out why the winding order is wrong for only text layers and fix it. I checked the plib sources -- they're definitely doing things CCW, as is all the rest of the panel code. Odd. I'm also not sure why the 2D panel doesn't care (it works in both winding orders). But this will allow you to check in working code, anyway. There's a big comment to this effect in there.
2002-06-28 14:17:40 +00:00
glTexCoord2f(0.0, 0.0); glVertex2f(WIN_X + (_width/4) * i, WIN_Y + (_height/2));
glTexCoord2f(1.0, 0.0); glVertex2f(WIN_X + (_width/4) * (i+1), WIN_Y + (_height/2));
glTexCoord2f(1.0, 1.0); glVertex2f(WIN_X + (_width/4) * (i+1), WIN_Y + _height);
glTexCoord2f(0.0, 1.0); glVertex2f(WIN_X + (_width/4) * i, WIN_Y + _height);
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);
3D panel support from Andy Ross: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. [and later] OK, this is fixed by the attached panel.cxx file. What's happened is that the winding order for the text layer's polygons is wrong, so I reverse it before drawing. That's largely a hatchet job to make things work for now, though. We should figure out why the winding order is wrong for only text layers and fix it. I checked the plib sources -- they're definitely doing things CCW, as is all the rest of the panel code. Odd. I'm also not sure why the 2D panel doesn't care (it works in both winding orders). But this will allow you to check in working code, anyway. There's a big comment to this effect in there.
2002-06-28 14:17:40 +00:00
glTexCoord2f(0.0, 0.0); glVertex2f(WIN_X + (_width/4) * i, WIN_Y);
glTexCoord2f(1.0, 0.0); glVertex2f(WIN_X + (_width/4) * (i+1), WIN_Y);
glTexCoord2f(1.0, 1.0); glVertex2f(WIN_X + (_width/4) * (i+1), WIN_Y + (_height/2));
glTexCoord2f(0.0, 1.0); glVertex2f(WIN_X + (_width/4) * i, WIN_Y + (_height/2));
glEnd();
}
}
2000-02-15 03:30:01 +00:00
3D panel support from Andy Ross: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. [and later] OK, this is fixed by the attached panel.cxx file. What's happened is that the winding order for the text layer's polygons is wrong, so I reverse it before drawing. That's largely a hatchet job to make things work for now, though. We should figure out why the winding order is wrong for only text layers and fix it. I checked the plib sources -- they're definitely doing things CCW, as is all the rest of the panel code. Odd. I'm also not sure why the 2D panel doesn't care (it works in both winding orders). But this will allow you to check in working code, anyway. There's a big comment to this effect in there.
2002-06-28 14:17:40 +00:00
// Draw the instruments.
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();
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();
}
// Draw yellow "hotspots" if directed to. This is a panel authoring
// feature; not intended to be high performance or to look good.
if ( fgGetBool("/sim/panel-hotspots") ) {
glDisable(GL_TEXTURE_2D);
glColor3f(1, 1, 0);
for ( unsigned int i = 0; i < _instruments.size(); i++ )
_instruments[i]->drawHotspots();
}
// restore some original state
glPopAttrib();
glPolygonOffset(0, 0);
3D panel support from Andy Ross: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. [and later] OK, this is fixed by the attached panel.cxx file. What's happened is that the winding order for the text layer's polygons is wrong, so I reverse it before drawing. That's largely a hatchet job to make things work for now, though. We should figure out why the winding order is wrong for only text layers and fix it. I checked the plib sources -- they're definitely doing things CCW, as is all the rest of the panel code. Odd. I'm also not sure why the 2D panel doesn't care (it works in both winding orders). But this will allow you to check in working code, anyway. There's a big comment to this effect in there.
2002-06-28 14:17:40 +00:00
glDisable(GL_POLYGON_OFFSET_FILL);
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
}
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.
*/
void
FGPanel::setVisibility (bool visibility)
{
2003-03-30 16:49:48 +00:00
_visibility->setBoolValue( 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
/**
* Return true if the panel is visible.
*/
bool
FGPanel::getVisibility () const
{
2003-03-30 16:49:48 +00:00
return _visibility->getBoolValue();
}
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.
*/
void
FGPanel::setBackground (ssgTexture * texture)
{
_bg = texture;
}
/**
* 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)
{
if (offset <= 0 && offset >= -_width + WIN_W)
2003-03-30 16:49:48 +00:00
_x_offset->setIntValue( offset );
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 y-offset.
*/
void
FGPanel::setYOffset (int offset)
{
if (offset <= 0 && offset >= -_height)
2003-03-30 16:49:48 +00:00
_y_offset->setIntValue( offset );
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
}
/**
2002-10-29 19:44:03 +00:00
* Handle a mouse action in panel-local (not screen) coordinates.
* Used by the 3D panel code in Model/panelnode.cxx, in situations
* where the panel doesn't control its own screen location.
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
*/
bool
2002-10-29 19:44:03 +00:00
FGPanel::doLocalMouseAction(int button, int updown, int x, int y)
{
2002-10-29 19:44:03 +00:00
// Note a released button and return
if (updown == 1) {
if (_mouseInstrument != 0)
_mouseInstrument->doMouseAction(_mouseButton, 1, _mouseX, _mouseY);
_mouseDown = false;
_mouseInstrument = 0;
return false;
}
2002-10-29 19:44:03 +00:00
// Search for a matching instrument.
2000-09-13 21:51:07 +00:00
for (int i = 0; i < (int)_instruments.size(); i++) {
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) {
_mouseDown = true;
_mouseDelay = 20;
_mouseInstrument = inst;
_mouseButton = button;
_mouseX = x - ix;
_mouseY = y - iy;
2002-10-29 19:44:03 +00:00
// Always do the action once.
return _mouseInstrument->doMouseAction(_mouseButton, 0,
_mouseX, _mouseY);
}
}
return false;
}
2002-10-29 19:44:03 +00:00
/**
* Perform a mouse action.
*/
bool
FGPanel::doMouseAction (int button, int updown, int x, int y)
{
// 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);
// Scale for the real window size.
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);
}
// Adjust for offsets.
2003-03-30 16:49:48 +00:00
x -= _x_offset->getIntValue();
y -= _y_offset->getIntValue();
2002-10-29 19:44:03 +00:00
// Having fixed up the coordinates, fall through to the local
// coordinate handler.
return doLocalMouseAction(button, updown, x, y);
2002-10-29 19:44:03 +00:00
}
////////////////////////////////////////////////////////////////////////.
// Implementation of FGPanelAction.
////////////////////////////////////////////////////////////////////////
FGPanelAction::FGPanelAction ()
{
}
FGPanelAction::FGPanelAction (int button, int x, int y, int w, int h,
bool repeatable)
: _button(button), _x(x), _y(y), _w(w), _h(h), _repeatable(repeatable)
{
for (unsigned int i = 0; i < 2; i++) {
for (unsigned int j = 0; j < _bindings[i].size(); j++)
delete _bindings[i][j];
}
}
FGPanelAction::~FGPanelAction ()
{
}
void
FGPanelAction::addBinding (FGBinding * binding, int updown)
{
_bindings[updown].push_back(binding);
}
bool
FGPanelAction::doAction (int updown)
{
if (test()) {
if ((updown != _last_state) || (updown == 0 && _repeatable)) {
int nBindings = _bindings[updown].size();
for (int i = 0; i < nBindings; i++)
_bindings[updown][i]->fire();
}
_last_state = updown;
return true;
} else {
return false;
}
}
////////////////////////////////////////////////////////////////////////
// Implementation of FGPanelTransformation.
////////////////////////////////////////////////////////////////////////
FGPanelTransformation::FGPanelTransformation ()
2001-05-15 23:08:25 +00:00
: table(0)
{
}
FGPanelTransformation::~FGPanelTransformation ()
{
delete table;
}
////////////////////////////////////////////////////////////////////////
2000-02-15 03:30:01 +00:00
// Implementation of FGPanelInstrument.
////////////////////////////////////////////////////////////////////////
2000-02-15 03:30:01 +00:00
FGPanelInstrument::FGPanelInstrument ()
{
2000-02-15 03:30:01 +00:00
setPosition(0, 0);
setSize(0, 0);
}
2000-02-15 03:30:01 +00:00
FGPanelInstrument::FGPanelInstrument (int x, int y, int w, int h)
{
setPosition(x, y);
setSize(w, h);
}
2000-02-15 03:30:01 +00:00
FGPanelInstrument::~FGPanelInstrument ()
{
for (action_list_type::iterator it = _actions.begin();
it != _actions.end();
it++) {
delete *it;
*it = 0;
}
2000-02-15 03:30:01 +00:00
}
void
FGPanelInstrument::drawHotspots()
{
for ( unsigned int i = 0; i < _actions.size(); i++ ) {
FGPanelAction* a = _actions[i];
float x1 = getXPos() + a->getX();
float x2 = x1 + a->getWidth();
float y1 = getYPos() + a->getY();
float y2 = y1 + a->getHeight();
glBegin(GL_LINE_LOOP);
glVertex2f(x1, y1);
glVertex2f(x1, y2);
glVertex2f(x2, y2);
glVertex2f(x2, y1);
glEnd();
}
}
2000-02-15 03:30:01 +00:00
void
FGPanelInstrument::setPosition (int x, int y)
{
2000-02-15 03:30:01 +00:00
_x = x;
_y = y;
}
2000-02-15 03:30:01 +00:00
void
FGPanelInstrument::setSize (int w, int h)
{
_w = w;
_h = h;
}
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
}
int
FGPanelInstrument::getWidth () const
{
return _w;
}
int
FGPanelInstrument::getHeight () const
{
return _h;
}
void
FGPanelInstrument::addAction (FGPanelAction * action)
{
_actions.push_back(action);
}
// Coordinates relative to centre.
bool
FGPanelInstrument::doMouseAction (int button, int updown, int x, int y)
{
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(updown))
return true;
}
}
return false;
}
////////////////////////////////////////////////////////////////////////
// Implementation of FGLayeredInstrument.
////////////////////////////////////////////////////////////////////////
1999-01-07 19:25:53 +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)
{
}
FGLayeredInstrument::~FGLayeredInstrument ()
2000-02-15 03:30:01 +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
}
2000-02-15 03:30:01 +00:00
void
FGLayeredInstrument::draw ()
{
3D panel support from Andy Ross: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. [and later] OK, this is fixed by the attached panel.cxx file. What's happened is that the winding order for the text layer's polygons is wrong, so I reverse it before drawing. That's largely a hatchet job to make things work for now, though. We should figure out why the winding order is wrong for only text layers and fix it. I checked the plib sources -- they're definitely doing things CCW, as is all the rest of the panel code. Odd. I'm also not sure why the 2D panel doesn't care (it works in both winding orders). But this will allow you to check in working code, anyway. There's a big comment to this effect in there.
2002-06-28 14:17:40 +00:00
if (!test())
return;
for (int i = 0; i < (int)_layers.size(); i++) {
glPushMatrix();
_layers[i]->draw();
glPopMatrix();
}
}
int
FGLayeredInstrument::addLayer (FGInstrumentLayer *layer)
{
int n = _layers.size();
if (layer->getWidth() == -1) {
layer->setWidth(getWidth());
}
if (layer->getHeight() == -1) {
layer->setHeight(getHeight());
}
_layers.push_back(layer);
return n;
}
int
FGLayeredInstrument::addLayer (FGCroppedTexture &texture,
2000-09-13 21:51:07 +00:00
int w, int h)
2000-02-15 03:30:01 +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
FGLayeredInstrument::addTransformation (FGPanelTransformation * transformation)
2000-02-15 03:30:01 +00:00
{
int layer = _layers.size() - 1;
_layers[layer]->addTransformation(transformation);
}
////////////////////////////////////////////////////////////////////////
// Implementation of FGInstrumentLayer.
////////////////////////////////////////////////////////////////////////
FGInstrumentLayer::FGInstrumentLayer (int w, int h)
: _w(w),
_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
FGInstrumentLayer::~FGInstrumentLayer ()
2000-02-15 03:30:01 +00:00
{
for (transformation_list::iterator it = _transformations.begin();
it != _transformations.end();
it++) {
delete *it;
*it = 0;
}
}
2000-02-15 03:30:01 +00:00
void
FGInstrumentLayer::transform () const
{
transformation_list::const_iterator it = _transformations.begin();
transformation_list::const_iterator last = _transformations.end();
while (it != last) {
FGPanelTransformation *t = *it;
if (t->test()) {
float val = (t->node == 0 ? 0.0 : t->node->getFloatValue());
if (t->has_mod)
val = fmod(val, t->mod);
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;
} else {
2001-05-15 23:08:25 +00:00
val = t->table->interpolate(val) * t->factor + t->offset;
}
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;
}
}
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
FGInstrumentLayer::addTransformation (FGPanelTransformation * transformation)
{
_transformations.push_back(transformation);
1999-05-06 22:16:12 +00:00
}
////////////////////////////////////////////////////////////////////////
// Implementation of FGGroupLayer.
////////////////////////////////////////////////////////////////////////
FGGroupLayer::FGGroupLayer ()
{
}
FGGroupLayer::~FGGroupLayer ()
{
for (unsigned int i = 0; i < _layers.size(); i++)
delete _layers[i];
}
void
FGGroupLayer::draw ()
{
if (test()) {
transform();
int nLayers = _layers.size();
for (int i = 0; i < nLayers; i++)
_layers[i]->draw();
}
}
void
FGGroupLayer::addLayer (FGInstrumentLayer * layer)
{
_layers.push_back(layer);
}
////////////////////////////////////////////////////////////////////////
// Implementation of FGTexturedLayer.
////////////////////////////////////////////////////////////////////////
FGTexturedLayer::FGTexturedLayer (const FGCroppedTexture &texture, int w, int h)
: FGInstrumentLayer(w, h)
{
setTexture(texture);
1999-05-06 22:16:12 +00:00
}
FGTexturedLayer::~FGTexturedLayer ()
{
1999-05-06 22:16:12 +00:00
}
2000-02-15 03:30:01 +00:00
void
FGTexturedLayer::draw ()
{
if (test()) {
int w2 = _w / 2;
int h2 = _h / 2;
transform();
glBindTexture(GL_TEXTURE_2D, _texture.getTexture()->getHandle());
glBegin(GL_POLYGON);
// From Curt: turn on the panel
// lights after sundown.
sgVec4 panel_color;
FGLight *l = (FGLight *)(globals->get_subsystem("lighting"));
sgCopyVec4( panel_color, l->scene_diffuse());
if ( fgGetDouble("/systems/electrical/outputs/instrument-lights") > 1.0 ) {
if ( panel_color[0] < 0.7 ) panel_color[0] = 0.7;
if ( panel_color[1] < 0.2 ) panel_color[1] = 0.2;
if ( panel_color[2] < 0.2 ) panel_color[2] = 0.2;
}
glColor4fv( panel_color );
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
}
2000-02-15 03:30:01 +00:00
////////////////////////////////////////////////////////////////////////
// Implementation of FGTextLayer.
2000-02-15 03:30:01 +00:00
////////////////////////////////////////////////////////////////////////
FGTextLayer::FGTextLayer (int w, int h)
: FGInstrumentLayer(w, h), _pointSize(14.0), _font_name("default")
2000-02-15 03:30:01 +00:00
{
_then.stamp();
_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
}
FGTextLayer::~FGTextLayer ()
2000-02-15 03:30:01 +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
FGTextLayer::draw ()
2000-02-15 03:30:01 +00:00
{
if (test()) {
glColor4fv(_color);
transform();
if ( _font_name == "led" && led_font != 0) {
text_renderer.setFont(led_font);
} else {
text_renderer.setFont(guiFntHandle);
}
text_renderer.setPointSize(_pointSize);
text_renderer.begin();
text_renderer.start3f(0, 0, 0);
_now.stamp();
long diff = _now - _then;
3D panel support from Andy Ross: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. [and later] OK, this is fixed by the attached panel.cxx file. What's happened is that the winding order for the text layer's polygons is wrong, so I reverse it before drawing. That's largely a hatchet job to make things work for now, though. We should figure out why the winding order is wrong for only text layers and fix it. I checked the plib sources -- they're definitely doing things CCW, as is all the rest of the panel code. Odd. I'm also not sure why the 2D panel doesn't care (it works in both winding orders). But this will allow you to check in working code, anyway. There's a big comment to this effect in there.
2002-06-28 14:17:40 +00:00
if (diff > 100000 || diff < 0 ) {
// ( diff < 0 ) is a sanity check and indicates our time stamp
// difference math probably overflowed. We can handle a max
// difference of 35.8 minutes since the returned value is in
// usec. So if the panel is left off longer than that we can
// over flow the math with it is turned back on. This (diff <
// 0) catches that situation, get's us out of trouble, and
// back on track.
recalc_value();
_then = _now;
}
3D panel support from Andy Ross: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. [and later] OK, this is fixed by the attached panel.cxx file. What's happened is that the winding order for the text layer's polygons is wrong, so I reverse it before drawing. That's largely a hatchet job to make things work for now, though. We should figure out why the winding order is wrong for only text layers and fix it. I checked the plib sources -- they're definitely doing things CCW, as is all the rest of the panel code. Odd. I'm also not sure why the 2D panel doesn't care (it works in both winding orders). But this will allow you to check in working code, anyway. There's a big comment to this effect in there.
2002-06-28 14:17:40 +00:00
// Something is goofy. The code in this file renders only CCW
// polygons, and I have verified that the font code in plib
// renders only CCW trianbles. Yet they come out backwards.
// Something around here or in plib is either changing the winding
// order or (more likely) pushing a left-handed matrix onto the
// stack. But I can't find it; get out the chainsaw...
glFrontFace(GL_CW);
text_renderer.puts((char *)(_value.c_str()));
3D panel support from Andy Ross: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. [and later] OK, this is fixed by the attached panel.cxx file. What's happened is that the winding order for the text layer's polygons is wrong, so I reverse it before drawing. That's largely a hatchet job to make things work for now, though. We should figure out why the winding order is wrong for only text layers and fix it. I checked the plib sources -- they're definitely doing things CCW, as is all the rest of the panel code. Odd. I'm also not sure why the 2D panel doesn't care (it works in both winding orders). But this will allow you to check in working code, anyway. There's a big comment to this effect in there.
2002-06-28 14:17:40 +00:00
glFrontFace(GL_CCW);
text_renderer.end();
glColor4f(1.0, 1.0, 1.0, 1.0); // FIXME
}
2000-02-15 03:30:01 +00:00
}
2000-02-15 03:30:01 +00:00
void
FGTextLayer::addChunk (FGTextLayer::Chunk * chunk)
{
_chunks.push_back(chunk);
}
void
FGTextLayer::setColor (float r, float g, float b)
{
_color[0] = r;
_color[1] = g;
_color[2] = b;
2000-03-17 06:16:15 +00:00
_color[3] = 1.0;
}
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
}
void
FGTextLayer::setFontName(const string &name)
{
_font_name = name;
}
2000-02-15 03:30:01 +00:00
void
FGTextLayer::setFont(fntFont * font)
{
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
////////////////////////////////////////////////////////////////////////
// Implementation of FGTextLayer::Chunk.
////////////////////////////////////////////////////////////////////////
2000-09-13 21:51:07 +00:00
FGTextLayer::Chunk::Chunk (const string &text, const string &fmt)
: _type(FGTextLayer::TEXT), _fmt(fmt)
{
2000-09-13 21:51:07 +00:00
_text = text;
if (_fmt.empty())
2000-09-13 21:51:07 +00:00
_fmt = "%s";
}
FGTextLayer::Chunk::Chunk (ChunkType type, const SGPropertyNode * node,
const string &fmt, float mult, float offs)
: _type(type), _fmt(fmt), _mult(mult), _offs(offs)
{
if (_fmt.empty()) {
if (type == TEXT_VALUE)
_fmt = "%s";
else
_fmt = "%.2f";
}
_node = node;
}
2000-09-13 21:51:07 +00:00
const char *
FGTextLayer::Chunk::getValue () const
{
if (test()) {
_buf[0] = '\0';
switch (_type) {
case TEXT:
sprintf(_buf, _fmt.c_str(), _text.c_str());
return _buf;
case TEXT_VALUE:
sprintf(_buf, _fmt.c_str(), _node->getStringValue());
break;
case DOUBLE_VALUE:
sprintf(_buf, _fmt.c_str(), _offs + _node->getFloatValue() * _mult);
break;
}
return _buf;
} else {
return "";
}
}
////////////////////////////////////////////////////////////////////////
// Implementation of FGSwitchLayer.
////////////////////////////////////////////////////////////////////////
FGSwitchLayer::FGSwitchLayer ()
: FGGroupLayer()
{
}
void
FGSwitchLayer::draw ()
{
if (test()) {
transform();
int nLayers = _layers.size();
for (int i = 0; i < nLayers; i++) {
if (_layers[i]->test()) {
_layers[i]->draw();
return;
}
}
}
}
2000-02-15 03:30:01 +00:00
// end of panel.cxx
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