opengc-devel — Developer's discussion list

[Opengc-devel] OpenGC coordinate system

[Damion S. <dam...@ho...>]

Actually, I don't think I've mentioned the OpenGC coordinate system before,
so it's good that you bring this up.

Gauges and components are designed in units of millimeters. m_MonitorSize is
the size of your display in millimeters and there's a corresponding
m_MonitorResolution; together these are used to provide a rough calibration
from "design" millimeters to "physical" millimeters. So, presumably, if
things are calibrated right, a gauge component that is 80 millimeters tall
in the code will actually appear 80 mm tall on your monitor. Right now, this
is invariant of window size as well, so OpenGC will clip off any portion of
the gauge which would "physically" extend beyond window.

This is important for more than than just proper scaling, because knowing
the final "pixel" size of a gauge/component allows you to set up gl windows
so that gaugecomponents are clipped properly (very important to accomplish,
among many examples, the artificial horizon).

There's also the separate issue of how to allow zooming, but I'm still
trying to figure out how that fits into the calibrated framework.

-Damion-

> //-----------------Desktop Measurement--------------------
>
> m_MonitorSize.x = ___  and m_MonitorSize = _________
>
> You might try 400 and 300 respectively and note the results.
>
> Also note next line: units per pixel is determined by the value in the x
> direction.

[Opengc-devel] OpenGC build process

[Damion S. <dam...@ho...>]

Hi all...

A quick update on the status of cross-platform building of OpenGC. I've
taken a first stab at using the CMake tool from www.kitware.com to create a
cross-platform build environment. In a nutshell, CMake generates makefiles
and Visual Studio project files on the fly and hides all of the nitty gritty
details. I use it for a project at work where it generates makefiles for ~8
flavors of Unix and 3 flavors of Windows on a daily basis, so it should be
pretty reliable.

In preparation for the changeover, you should download and compile the
latest CMake tree from:

http://public.kitware.com/CMake/

Windows users can snag a precompiled binary rather than build from scratch.
Unfortunately, builds of GLTT, Freetype, and now SimGear, will still have to
be performed manually. Fortunately, this seems to have gone relatively
smoothly for most people, and I hope to have GLTT and Freetype rolled into
the CMake build process shortly.

The OpenGC repository is not yet updated to reflect these changes, but
should be within a few days.

Cheers,

-Damion-

[Opengc-devel] John W's Unix release of OpenGC

[Damion S. <dam...@ho...>]

I'm pleased to announce alpha support for the Unix folks running =
Flightgear. John Wojnaroski has created a tarball of the files =
neccessary to build OpenGC under Cygwin (and therefore presumably Linux) =
which can be had by trekking over to the OpenGC download page.

Please direct all questions to either the OpenGC or Flightgear devel =
lists, and keep in mind that we intend to have a completely automated =
unified build system going at some point in the near future. Thanks to =
everyone who sent in suggestions on how to do this; I'll be replying to =
you shortly, as I've been extremely busy with work the last two weeks. =
Those of you who do a lot of cross-platform work might be interested in =
a package called CMake, which you can find at =
http://public.kitware.com/CMake/ I've used this for the past year at =
work and although complicated, it's extremely powerful.

Anyways, stay tuned.

Cheers,

-Damion-

[Opengc-devel] OpenGC / FlightGear

[Damion S. <dam...@ho...>]

> FG and OpenGC are connected. The "interface" module is called
> ogcFGDataSource.cxx/hxx. This replaces the ogcFSUIPCDatasource files in
> OpenGC.

Very cool! You've managed to demonstrate how the DataSource interface was
intended to be used, and it's nice to know that it actually works. Hopefully
the SimGear UDP interface will work for X-Plane as well, assuming it's
primarily a matter of describing the datagram format.

> Probably need to create a tar install file with the libraries and a small
> README doc and urls for the two font libraries (freetype and gltt). the
gltt
> source and library will be included in the tar files. Getting it to work
was
> a little troublesome, no need  for others to suffer that pain, the install
> will create a working copy. Right now the source will load and build under
> /usr/local/OpenGC with a file structure that mimics FG. Build is gnu-ish :
> aclocal, automake, etc etc.

I'll stick the new class in the CVS repository. I think it's now obvious
that we need file based initialization, to having to set data source type
(and gauge type, window size, etc.) at compile time. We also need a
transparent way to build OpenGC in a cross-platform fashion. I've got a few
ideas, but input is welcome. One of the next major changes to OpenGC will be
to reorganize code in a hierarchy so that platform configurations are
separate from base code.

Anyway, great job. I look forward to giving it a try.

-Damion-

[Opengc-devel] updates

[Damion S. <dam...@ho...>]

Hi all,

A bunch of updates today (all committed to CVS), some noticeable, some not:

Lance's updates:

1) Preliminary flight director code added to 777ArtificialHorizon

2) Reworking of how FSUIPC accesses are handled. He reports substantial
speed improvements on his machine and the code is cleaner.

My updates:

3) FontManager now checks to make sure it's not duplicating fonts (which was
why it exists in the first place). This cuts overall memory usage by about
50% and reduces load times by 75%.

4) Copyright info added to each file (see below)

5) UpdateData() removed from DataSource - all data should now be updated in
an overloaded OnIdle function

Copyright notes:

I've added a GPL-based copyright header to each file (except for third party
stuff). Please use this copyright when adding files to the project. If you
contribute to a file's development, add your name to the "contributors" and
"copyright" lists. Individuals not affiliated with the OpenGC project but
who authored a file from which yours is derived should be credited here as
well. If you think that someone forgot to add you, please remind them
nicely.

I'd also like to suggest the following file header layout (currently in use
as of today):

// Filename

/*
Copyright
*/

/*
File description
*/

The copyright section should _only_ contain the copyright. If you wish to
thank third parties who did not actually contribute to the specific file but
provided help, notes, etc., please do this at the end of the file
description section. Please be sure to acknowledge the appropriate people,
as very few of us program in a vacuum.

FSUIPC:

A new version of FSUIPC was released today, making FSUIPC compatible with
FS2002 (among other cool things, it adds TCAS). OpenGC is currently _not_
compatible with this version of FSUIPC, but will be as soon as the version 7
SDK is released. Many offsets have changed, causing several gauge components
to malfunction, including the newly implemented flight director. As far as I
know, earlier versions of FSUIPC still work fine (but do not work with
FS2002).

Other news:

Lance has suggested that we put together a "who's doing what" list to avoid
duplication of effort. I'll be out of town Sunday-Wed but will take care of
this ASAP as soon as I get back. For now, please post to the devel list if
you're working on something major that you'd like others to know about.

My plans for the next month or so:

1) Finish the gauge components comprising the 777 PFD. This will give us one
completely functional gauge to experiment with.

2) Convert to file-based initialization of ogcAppObject

Cheers,

-Damion-

[Opengc-devel] Re: First impressions and some patches.

[Damion S. <dam...@ho...>]

Hi....

> Again i'm not certain this went to everybody - it comes back to me ok, but
> doesn't show up on the SourceForge list (and that's about 5 hours after I
> posted it!).

The sourceforge archive appears to update only once every 24 hours.

> As it stands, OpenGC is painfully slow. The hardware I ran it on is not
the

<snip>

> FSUIPCDataSource. In the idle function, it reads and processes the whole
15k
> data block available from fsuipc, EVERY TIME! This is a major stumbling

Believe it or not, this was intentional. What you're wondering now is _why_.
Well, there are 3 ways of accessing FSUIPC data (here I read two variables):

1) tempvar, queue state1 read to tempvar, transfer data, tempvar, queue
state2 read to tempvar, etc.
2) tempvar, queue state1 read to tempvar, tempvar2, queue state2 read to
tempvar2, transfer data
3) bigtempvar, queue entire FSUIPC state to tempvar, transfer data, extract
vars from bigtempvar

If you think 3 is slow, 1 would have completely killed your system. I talked
to Pete Dowson and it turns out that the "read" operation is relatively slow
compared to the rest of FSUIPC. The reason I chose 3 over 2 was that it
avoids the need to have "n" temp variables to read "n" state variables. But,
if it turns out that this is a big performance hit on slower machines, I can
switch to 2. On my machine the performance is quite acceptable, but there's
no reason not to move to something that's better for everyone.

So to clarify, what you're suggesting is to queue all desired variables
(only), then perform one read operation. Will do. Thanks for the analysis.

> I've also snaffled a file from the fltk library to get rid of the console
> window for WIN32 release versions.

Actually, there's a compiler flag to handle this too. I turned the console
back on for debugging purposes, but I'd be interested in seeing the file as
well.

> If you don't want stuff submitted like this, just yell - always willing to
> oblige :-)

Actually, this is the reason the project is open-source.

> By the way, I'm willing to be a fully paid up, card carrying project
member
> if you like.

Send me an email with your sourceforge username, then you'll have CVS
read/write access.

> Is there a list of who's doing what so we don't tread on other peoples
toes?

There should be. I'll add one to the sourceforge lists. Maybe
Opengc-devel-todo? Any suggestions for the name?

> As a sideline I built & ran it on Linux, just to see if it would - it did!
> (I did change the template bit though).

Cool! What template changes did you make?

Also, I'll add your patch. I'll be leaving for a business trip on Sunday so
I can't gurantee I'll be around much over the next four days, but I'll get
to it ASAP.

Thanks for all the input,

-Damion-

[Opengc-devel] First impressions and some patches.

[Lance W. <lan...@lo...>]

Some observations (based on Windows version).

As it stands, OpenGC is painfully slow. The hardware I ran it on is not the
greatest (P200, 48 Mb with some strange on-board graphics card - well hey,
it was free :-), but with FreeFd I could get a usable 5 fps - OpenGC ran at
less that ONE fps.

Bummer.

So I started delving and turned line and font smoothing off, but it was
still horribly slow. More delving turned up the cause of the problem in the
FSUIPCDataSource. In the idle function, it reads and processes the whole 15k
data block available from fsuipc, EVERY TIME! This is a major stumbling
block. When I trimmed the idle function down to only read the variables that
are used, there was a vast speed improvement, better than FreeFd - so I
suggest there is room for improvement here. Also in its present form I think
it might overload WideClient/WideServer. Several times FS would stop
completely, until I killed ogc.


Patches.

While I was in there I implemented the standard magenta cross hair flight
director. Code follows...
I've also snaffled a file from the fltk library to get rid of the console
window for WIN32 release versions.

Cheers

Lance

P.S.'s

If you don't want stuff submitted like this, just yell - always willing to
oblige :-)
By the way, I'm willing to be a fully paid up, card carrying project member
if you like.
Is there a list of who's doing what so we don't tread on other peoples toes?


P.P.S.
As a sideline I built & ran it on Linux, just to see if it would - it did!
(I did change the template bit though).

ogcDataSource.h
--------------------------------------------------------------
239,244d238
< 
<   // Flight Director
<   unsigned int Director_Active;
<   double       Director_Bank;
<   double       Director_Pitch;
< 
---------------------------------------------------------------

ogcBoeing777ArtificialHorizon.cpp
---------------------------------------------------------------
469,494d468
<   //----------------Flight Director----------------
<   // Reset the modelview matrix
<   glPopMatrix();
<   glPushMatrix();
<   if (m_pDataSource->Director_Active == 1)
<   {
< 	// Move to the center of the window
< 	glTranslated(47,49,0);
< 	glColor3ub(255,0,255);
< 	glLineWidth(3.0);
< 	glPushMatrix();
<
glTranslated(0,(m_pDataSource->Director_Pitch-m_pDataSource->Pitch)*2.0,0);
< 	glBegin(GL_LINES);
< 	glVertex2f(-20,0);
< 	glVertex2f(20,0);
< 	glEnd();
< 	glPopMatrix();
< 	glPushMatrix();
<
glTranslated((m_pDataSource->Director_Bank-m_pDataSource->Bank),0,0);
< 	glRotated(90.0, 0, 0, 1);
< 	glBegin(GL_LINES);
< 	glVertex2f(-20,0);
< 	glVertex2f(20,0);
< 	glEnd();
< 	glPopMatrix();
<    }
---------------------------------------------------------------


ogcFSUIPCDataSource.cpp

Current idle function
---------------------------------------------------------------
<   Director_Active = (unsigned int) *(short*)(&m_pData[0x2EE0]);
<   Director_Bank = -1*( (double) *(double*)(&m_pData[0x2EF0]) );
<   Director_Pitch = -1*( (double) *(double*)(&m_pData[0x2EE8]) );
---------------------------------------------------------------

New idle function
---------------------------------------------------------------
void ogcFSUIPCDataSource::OnIdle()
{
  DWORD dwResult;

  // Modified to always try & open the connection if it's down.
  // This means you can start OpenGC before FS.
  if(!m_ValidConnection)
    {
      // Try to open the FSUIPC connection
      if (FSUIPC_Open(SIM_ANY, &dwResult))
	{
	  m_ValidConnection = true;
	} else
	  return;
    }

  // Temporary variables
  long _bank;
  long _pitch;
  long _tHeading;
  long _tas;
  long _ias;
  long _fracMeters;
  long _unitMeters;
  short _dirActive;
  double _dirPitch;
  double _dirBank;
  
  FSUIPC_Read(0x057c, 4, &_bank, &dwResult);
  FSUIPC_Read(0x0578, 4, &_pitch, &dwResult);
  FSUIPC_Read(0x0580, 4, &_tHeading, &dwResult);
  FSUIPC_Read(0x02b8, 4, &_tas, &dwResult);
  FSUIPC_Read(0x02bc, 4, &_ias, &dwResult);
  FSUIPC_Read(0x0570, 4, &_fracMeters, &dwResult);
  FSUIPC_Read(0x0574, 4, &_unitMeters, &dwResult);
  FSUIPC_Read(0x2ee0, 2, &_dirActive, &dwResult);
  FSUIPC_Read(0x2ef0, 8, &_dirBank, &dwResult);
  FSUIPC_Read(0x2ee8, 8, &_dirPitch, &dwResult);

  FSUIPC_Process(&dwResult);

  Bank = -360.0*( (double) _bank )/(65356.0*65356.0);
  Pitch = -360.0*( (double) _pitch )/(65356.0*65356.0);

  True_Heading = 360.0*((double)_tHeading)/(65356.0*65356.0);

  Magnetic_Heading = True_Heading - Magnetic_Variation;

  TAS = (double)_tas/128;

  IAS = (double)_ias/128;

  // Compute altitude
  // Note that we use the meters and fractional meters data, rather than
  // the barometric altitude in feet as computed by FSUIPC (which seems
  // to update rather slowly)
  //unsigned long fractionalMeters = *(unsigned long*)(&m_pData[0x0570]);
  unsigned long fractionalMeters = (unsigned long)_fracMeters;
  long unitMeters = _unitMeters;

  // 4294967296 is 2^32, because the fractional unit is scaled to maximum
  // possible magnitude of an unsigned long int
  Barometric_Alt_Metres = (double) unitMeters + (double) fractionalMeters /
4294967296;
  Barometric_Alt_Feet = Barometric_Alt_Metres * 3.28084;
  
  Director_Active = (unsigned int) _dirActive;
  Director_Bank = -1*( (double) _dirBank );
  Director_Pitch = -1*( (double) _dirPitch );
}
-------------------------------------------------------------


****************************************************************************
LOGICSCOPE REALISATIONS LTD, 64 Great Eastern St, London EC2A 3QR
 
The information contained in this document is intended only for the
addressee.It may contain confidential and/or legally privileged material.You
may not review, retransmit, disseminate, publish or otherwise use or rely on
the information in this document unless you are its intended recipient.If
you have received this document in error, Please contact the sender and
delete all copies of this material.

FW: [Opengc-devel] gcc port

[Lance W. <lan...@lo...>]

This works on gcc:

template< class TDataType>
class ogcOrderedPair
{
public:
  ogcOrderedPair() { x = 0; y = 0; }
  ~ogcOrderedPair() { }

  TDataType x;
  TDataType y;
};


Cheers

Lance

> -----Original Message-----
> From: Alasdair Campbell [mailto:ala...@bt...]
> Sent: 20 October 2001 19:58
> To: ope...@li...
> Subject: [Opengc-devel] gcc port
> 
> 
> I read Damian's interesting stuff in Glightgear-devel and 
> have got quite 
> interested. I stumbled at the first fence with the following error:
> 
> In file included from ogcRenderWindow.h:14,
>                  from ogcAppObject.h:22,
>                  from main.cpp:13:
> ogcOrderedPair.h:22: parse error before `;'
> ogcOrderedPair.h:25: parse error before `;'
> 
> Found the following on  
> http://www.cs.rpi.edu/projects/STL/htdocs/stl.html
>  
> ".....
>  Compiling programs that use STL
> 
>   STL makes very aggressive use of the template feature of 
> C++, and currently
>  only a few compilers are capable of compiling programs that use STL.
>  Unfortunately these do not include the GNU g++ compiler or 
> the SUN CC 
> compiler. "
>  
>  Does this mean we can't use gcc to compile opengc?
> 
> Or has John got around the problem with ogcOrderedPair ? I am 
> a C++ novice, 
> so not so clued up on templates.  I am using gcc 2.95.2.1
> 
> -- 
> Kind Regards,
> 
> Alasdair Campbell
> 
> 
> _______________________________________________
> Opengc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengc-devel
> 
****************************************************************************
LOGICSCOPE REALISATIONS LTD, 64 Great Eastern St, London EC2A 3QR
 
The information contained in this document is intended only for the
addressee.It may contain confidential and/or legally privileged material.You
may not review, retransmit, disseminate, publish or otherwise use or rely on
the information in this document unless you are its intended recipient.If
you have received this document in error, Please contact the sender and
delete all copies of this material.

[Opengc-devel] Serious bug

[Lance W. <lan...@lo...>]

This is the cause of why I couldn't get a Windows release version running.

File:		ogcBoeingPFDHeadingIndicator
Function:	Render
Line:		68 (ish)

The line declares a char buffer of length 2 for use with '_itoa' on line
128(ish). It is not big enough, it should be at least 3. '_itoa' converts
displayHeading/10 which can run from 0 to 36 and so the buffer needs 3
characters, 2 for the number and one for the terminating null.


Cheers

Lance
****************************************************************************
LOGICSCOPE REALISATIONS LTD, 64 Great Eastern St, London EC2A 3QR
 
The information contained in this document is intended only for the
addressee.It may contain confidential and/or legally privileged material.You
may not review, retransmit, disseminate, publish or otherwise use or rely on
the information in this document unless you are its intended recipient.If
you have received this document in error, Please contact the sender and
delete all copies of this material.

[Opengc-devel] Re: [Flightgear-devel] Help on C++ Classes

[John W. <ca...@mm...>]

(Ooops, I just sent the wrong msg, my apologies. Here is the right one)

To: Andy & Damion

Thank you for the prompt replies and comments.

Right on, error msgs become a lot clearer as one gains knowledge and
experience with the language. Especially those caused by typos, missing
brackets, semi-colons that "reparse" your code. I appreciate all your
patience and help. It sounds like my approach to the design is okay and
doable - it is just a matter of forming the correct statements and syntax to
make it happen. Too bad they don't build compilers that can read your mind
;-)

Appreciate the offer to review the source but before I start sending out
code, I do need to study your comments and work more.

Thanks again
John W

[Opengc-devel] Re: [Flightgear-devel] Help on C++ Classes

[John W. <ca...@mm...>]

----- Original Message -----
From: "Damion Shelton" <dam...@ho...>
To: <fli...@fl...>; <ope...@li...>
Sent: Tuesday, October 23, 2001 4:43 PM
Subject: Re: [Flightgear-devel] Help on C++ Classes


> Hi...
>
> Maybe I can clarify a bit about the design of the ogcDataSource class.
> First, _all_ of the data members of ogcDataSource are public. This is
> intentionally "poor" design, but it makes life a lot easier since we won't
> need Get and Set functions for each of the potentially several hundred
> variables in the class.
>
> The OnIdle() function is called by the ogcApplication class once per
> rendering cycle, and "polls" the data source for fresh data, prior to
> ogcApplication entering the list of gauges and executing virtual render
> functions. So, your OnIdle() code should grab all relevant variables from
> FlightGear and store them locally (sounds like this is what you're trying
to
> do anyways).
>
> In the other data source, ogcFSUIPCDataSource, OnIdle() calls a FSUIPC
> library function which transfers a memory block from FS200x into an
internal
> array, and then extracts variables out of this array into the
ogcDataSource
> state variables. Again, it sounds like this is what you're trying to do
with
> FlightGear.
>
> > > On paper the idea looks like this.
> > > i.e // Opengc data_side = FlightGear data_side
> > >     ogcData.altitude ( or ogcData->altitude) =
> cur_fdm_state->get_Altitude;
> > >     ogcData.pitch = cur_fdm_state->get_Theta_deg()
> > >
> > > and so forth......
> >
> > This looks perfectly fine, actually.  You need parenthesis after
> > get_Altitude, but I'm sure that's just a typo.
>
> This looks fine to me also.
>
> > Not to be too glib, but 99% of the time, when someone complains about
> > getting "weird error messages", the answer can be found right there in
> > the text of the error message.  Compilers are obtuse sometimes, but
> > they don't lie.  Usually they mean what the say.  How about an example
> > of an error?  Are you sure the ogcData fields are accessible?  If
> > you're in a subclass, you still can't touch private data.
>
> This would be a concern, but all derived classes from ogcDataSource should
> use public derivation, and therefore have access to public members of the
> base class. My other two data sources worked without any problems (as far
as
> inheritance goes).
>
> > A better way would be for the OGC stuff to provide setBLAH() methods
> > (or an equivalent API) for your glue code to use.  Sticking FlightGear
> > internals right into the core of the OGC code strikes me as awfully
> > incestuous.
>
> As mentioned earlier, I've avoided get's and set's because of the
potential
> for bloated code. I assume gauge programmers are intelligent enough not go
> mucking around with datasource members when displaying gauges.
>
> I also don't see any problem with having the FGInterface object be a
member
> of ogcFGDataSource. In fact, I'd recommend it. Then, as you suggested,
each
> OnIdle() update would contain something like:
>
> pitch = FGInterface->GetPitch();
> roll = FGInterface->GetRoll();
> ...etc
>
> Keep in mind that since you're accessing public members from within the
> class itself, you don't need to preface the variable with the
> ogcFGDataSource class name (as in ogcFGDataSource.pitch). I don't know if
> this is how you were coding it or was just for the example. Feel free to
> directly email me the code if you want me to look over it.
>
> Anyways, glad to hear that you're making progress, even if it's
frustrating
> at times.
>
> -Damion-
>
> _______________________________________________
> Flightgear-devel mailing list
> Fli...@fl...
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
>

[Opengc-devel] Re: [Flightgear-devel] Help on C++ Classes

[Damion S. <dam...@ho...>]

Hi...

Maybe I can clarify a bit about the design of the ogcDataSource class.
First, _all_ of the data members of ogcDataSource are public. This is
intentionally "poor" design, but it makes life a lot easier since we won't
need Get and Set functions for each of the potentially several hundred
variables in the class.

The OnIdle() function is called by the ogcApplication class once per
rendering cycle, and "polls" the data source for fresh data, prior to
ogcApplication entering the list of gauges and executing virtual render
functions. So, your OnIdle() code should grab all relevant variables from
FlightGear and store them locally (sounds like this is what you're trying to
do anyways).

In the other data source, ogcFSUIPCDataSource, OnIdle() calls a FSUIPC
library function which transfers a memory block from FS200x into an internal
array, and then extracts variables out of this array into the ogcDataSource
state variables. Again, it sounds like this is what you're trying to do with
FlightGear.

> > On paper the idea looks like this.
> > i.e // Opengc data_side = FlightGear data_side
> >     ogcData.altitude ( or ogcData->altitude) =
cur_fdm_state->get_Altitude;
> >     ogcData.pitch = cur_fdm_state->get_Theta_deg()
> >
> > and so forth......
>
> This looks perfectly fine, actually.  You need parenthesis after
> get_Altitude, but I'm sure that's just a typo.

This looks fine to me also.

> Not to be too glib, but 99% of the time, when someone complains about
> getting "weird error messages", the answer can be found right there in
> the text of the error message.  Compilers are obtuse sometimes, but
> they don't lie.  Usually they mean what the say.  How about an example
> of an error?  Are you sure the ogcData fields are accessible?  If
> you're in a subclass, you still can't touch private data.

This would be a concern, but all derived classes from ogcDataSource should
use public derivation, and therefore have access to public members of the
base class. My other two data sources worked without any problems (as far as
inheritance goes).

> A better way would be for the OGC stuff to provide setBLAH() methods
> (or an equivalent API) for your glue code to use.  Sticking FlightGear
> internals right into the core of the OGC code strikes me as awfully
> incestuous.

As mentioned earlier, I've avoided get's and set's because of the potential
for bloated code. I assume gauge programmers are intelligent enough not go
mucking around with datasource members when displaying gauges.

I also don't see any problem with having the FGInterface object be a member
of ogcFGDataSource. In fact, I'd recommend it. Then, as you suggested, each
OnIdle() update would contain something like:

pitch = FGInterface->GetPitch();
roll = FGInterface->GetRoll();
...etc

Keep in mind that since you're accessing public members from within the
class itself, you don't need to preface the variable with the
ogcFGDataSource class name (as in ogcFGDataSource.pitch). I don't know if
this is how you were coding it or was just for the example. Feel free to
directly email me the code if you want me to look over it.

Anyways, glad to hear that you're making progress, even if it's frustrating
at times.

-Damion-

[Opengc-devel] Alasdair's question

[Damion S. <dam...@ho...>]

I'd suggest talking to John about those problems. I got started with STL =
at work on a project where well over half the developers are using GCC, =
so it seems likely that this is probably a library or include problem. =
Hope things work out, I'm unfortunately not terribly GCC literate.

-Damion-

[Opengc-devel] networking

[Damion S. <dam...@ho...>]

Hello again,

Yes, I'm planning on the broadcast model for now. I don't see any real need
for handshaking at this point; possibly down the road if the we get into a
situation where, for example, a flight computer needs to communicate with a
navigation display (but that would be a nice problem to have).

The broadcast model allows a sim to toss data out as fast as it can, and the
gauges to render as fast as they can, so that would seem to be the way to
go. I'll take a look at the package you mentioned, thanks for the info.

-Damion-

[Opengc-devel] Re: Bugs

[Damion S. <dam...@ho...>]

No, your bug wasn't premature. However, I'm not seeing it on my machine and
no one else has reported it. Possibly, it's dependent on your hardware
setup? Could you provide details on your graphics card, and also the screen
capture that you mentioned?

Thanks,

-Damion-

----- Original Message -----
From: "Lance White" <lan...@lo...>
To: "'Damion Shelton'" <da...@op...>
Sent: Tuesday, October 23, 2001 7:49 AM
Subject: Re: Bugs


> Sorry if you get this twice - I posted this to the devel list (and got a
> mail back to me from the list) but it's not shown up on the SourceForge
web
> list so I don't know if anybody else got it.
>
>
> Rendering problem - seems to be fixed if you remove the following code
from
> ogcBoeing777ArtificialHorizon.cpp
>
> #if 0
>   // Draw in the sky color
>   glColor3ub(0,153,204);
>
>   aCircle.SetOrigin(47,49);
>   aCircle.SetRadius(46);
>   aCircle.SetDegreesPerPoint(5);
>   aCircle.SetArcStartEnd(300.0,360.0);
>
>   glBegin(GL_TRIANGLE_FAN);
>   glVertex2f(0,98);
>   glVertex2f(0,72);
>   aCircle.Evaluate();
>   glVertex2f(47,98);
>   glEnd();
>
>   aCircle.SetArcStartEnd(0.0,60.0);
>   glBegin(GL_TRIANGLE_FAN);
>   glVertex2f(94,98);
>   glVertex2f(47,98);
>   aCircle.Evaluate();
>   glVertex2f(94,72);
>   glEnd();
> #endif
>
> Unless the previous behaviour is correct (although I've not seen this
> before).
>
> I've also got some code to read INI files if you want it (compiles on
WIN32
> & *nix)
>
>
> Cheers
>
> Lance
>
****************************************************************************
> LOGICSCOPE REALISATIONS LTD, 64 Great Eastern St, London EC2A 3QR
>
> The information contained in this document is intended only for the
> addressee.It may contain confidential and/or legally privileged
material.You
> may not review, retransmit, disseminate, publish or otherwise use or rely
on
> the information in this document unless you are its intended recipient.If
> you have received this document in error, Please contact the sender and
> delete all copies of this material.
>

[Opengc-devel] oops

[Damion S. <dam...@ho...>]

Ok, so:

1) Remove shoe
2) Insert foot in mouth

I seem to have forgotten to subscribe to the developer list, which would
explain why I haven't been getting your emails. This is the problem with
talking on too many lists about the same project. Anyways, I'll try and
reply to everyone who's emailed so far, if you don't here from me send me a
reminder ;-)

-Damion-

RE: [Opengc-devel] Bugs

[Lance W. <lan...@lo...>]

Rendering problem - seems to be fixed if you remove the following code from
ogcBoeing777ArtificialHorizon.cpp

#if 0
  // Draw in the sky color
  glColor3ub(0,153,204);

  aCircle.SetOrigin(47,49);
  aCircle.SetRadius(46);
  aCircle.SetDegreesPerPoint(5);
  aCircle.SetArcStartEnd(300.0,360.0);

  glBegin(GL_TRIANGLE_FAN);
  glVertex2f(0,98);
  glVertex2f(0,72);
  aCircle.Evaluate();
  glVertex2f(47,98);
  glEnd();

  aCircle.SetArcStartEnd(0.0,60.0);
  glBegin(GL_TRIANGLE_FAN);
  glVertex2f(94,98);
  glVertex2f(47,98);
  aCircle.Evaluate();
  glVertex2f(94,72);
  glEnd();
#endif

Unless the previous behaviour is correct (although I've not seen this
before).


Cheers

Lance
****************************************************************************
LOGICSCOPE REALISATIONS LTD, 64 Great Eastern St, London EC2A 3QR
 
The information contained in this document is intended only for the
addressee.It may contain confidential and/or legally privileged material.You
may not review, retransmit, disseminate, publish or otherwise use or rely on
the information in this document unless you are its intended recipient.If
you have received this document in error, Please contact the sender and
delete all copies of this material.

[Opengc-devel] Bugs

[Lance W. <lan...@lo...>]

This might be a bit premature but...

Building & running on Windows 2000.

1) There is a rendering problem with the artificial horizon when pitch is
about 7.5 degrees below the horizon. The bank angle markings together with
the bit of blue sky they sit on are splatted on top of the horizon
background, therefore the background in an arch around the top of the
display is always blue, even if you are pointing stratight down at the
ground (I've got a jpeg of this if you want to see it).

2) Release build doesn't work at all. It doesn't seem to call the glut idle
function in the glut main loop (although it seems to set everything up OK as
far as I can see) and CPU ramps to 100%.

Cheers

Lance

P.S. Should we be using the BUGS section on SourceForge or is that only for
team members?
****************************************************************************
LOGICSCOPE REALISATIONS LTD, 64 Great Eastern St, London EC2A 3QR
 
The information contained in this document is intended only for the
addressee.It may contain confidential and/or legally privileged material.You
may not review, retransmit, disseminate, publish or otherwise use or rely on
the information in this document unless you are its intended recipient.If
you have received this document in error, Please contact the sender and
delete all copies of this material.

[Opengc-devel] RE: TCP/IP - UDP interface

[Lance W. <lan...@lo...>]

I forgot - I've got some code lurking at home that ties RTSP to FSUIPC
(throwing FS2K data to a Linux box) - You can have it if you want.
****************************************************************************
LOGICSCOPE REALISATIONS LTD, 64 Great Eastern St, London EC2A 3QR
 
The information contained in this document is intended only for the
addressee.It may contain confidential and/or legally privileged material.You
may not review, retransmit, disseminate, publish or otherwise use or rely on
the information in this document unless you are its intended recipient.If
you have received this document in error, Please contact the sender and
delete all copies of this material.

[Opengc-devel] TCP/IP - UDP interface

[Lance W. <lan...@lo...>]

It depends how you want the interface to work. Do you want it to be
broadcast (UDP), in which case RTSP (Real-Time Simulation Protocol) seems to
be quite good. This was published in the May 2001 edition of Dr. Dobbs
Journal (but I'm not sure what the licensing position on this is - all the
source code is available, but there is no mention of whether it's free or
not).
 
If you want a Request/Response interface (TCP/IP), this is really quite
noddy, it's the protocol you need to work out first (I develop real-time
messaging systems for financial packages).
 
 
Cheers
 
Lance
 
 
RTSP package from :
 
http://www.ddj.com/ftp/2001/2001_05/rtsp.zip
<http://www.ddj.com/ftp/2001/2001_05/rtsp.zip> 
****************************************************************************
LOGICSCOPE REALISATIONS LTD, 64 Great Eastern St, London EC2A 3QR
 
The information contained in this document is intended only for the
addressee.It may contain confidential and/or legally privileged material.You
may not review, retransmit, disseminate, publish or otherwise use or rely on
the information in this document unless you are its intended recipient.If
you have received this document in error, Please contact the sender and
delete all copies of this material.

[Opengc-devel] Re: opengc 0.02 source

[Damion S. <dam...@ho...>]

Hi...

> The heading indicator appears incomplete. I'm not familiar with the 777
> flight deck, but where is the nav info displayed ?(on the HSI below the
> ADI?). Does this area need some work?

Oh yes. I make no claim that the existing 777 PFD is _in any way_ complete,
so there is still quite a bit missing from the existing code. At least for
the first gauge, I'm taking the approach of getting high level functionality
going before worrying about the details.

For any of the developers, please feel free to hack on existing gauges to
improve functionality (although you should probably post something to the
list first to make sure that you aren't duplicating effort).

-Damion-

[Opengc-devel] opengc 0.02 source

[Damion S. <dam...@ho...>]

I apologize in advance if any of you receive duplicates of this message. =
There are now two lists on Sourceforge, devel and announce. After this =
message, I will only post developer messages to the devel list and =
reserve the announce list for end-user announcements.

First, John is working on a cygwin/linux (and theoretically Mac OSX =
port) as well as a Flightgear data source object. The open-source model =
in action!

Second - after promising to do so for several days - I've synced the CVS =
source to the 0.02 release. No major changes, but it does include the =
scrolling portion of the altitude and speed tapes.

And third, if anyone has any suggestions on a good cross-platform TCP/IP =
/ UDP interface, please let me know.

Cheers,

-Damion-

[Opengc-devel] gcc port

[Alasdair C. <ala...@bt...>]

I read Damian's interesting stuff in Glightgear-devel and have got quite 
interested. I stumbled at the first fence with the following error:

In file included from ogcRenderWindow.h:14,
                 from ogcAppObject.h:22,
                 from main.cpp:13:
ogcOrderedPair.h:22: parse error before `;'
ogcOrderedPair.h:25: parse error before `;'

Found the following on  http://www.cs.rpi.edu/projects/STL/htdocs/stl.html
 
".....
 Compiling programs that use STL

  STL makes very aggressive use of the template feature of C++, and currently
 only a few compilers are capable of compiling programs that use STL.
 Unfortunately these do not include the GNU g++ compiler or the SUN CC 
compiler. "
 
 Does this mean we can't use gcc to compile opengc?

Or has John got around the problem with ogcOrderedPair ? I am a C++ novice, 
so not so clued up on templates.  I am using gcc 2.95.2.1

-- 
Kind Regards,

Alasdair Campbell

[Opengc-devel] Re: OpenGC Port/Network (Retrans)

[John W. <ca...@mm...>]

Retrans to see why msg is not sticking to the mail list...

> Hi
>
> Thank you Damion, for all the info.
>
> Your explanation was very clear. I'll research the problem further. BTW:
> Some older manuals for Borland C++ ( pre 1995) do not call out typename as
a
> keyword but you would think by now all compilers would include it.
>
> There is a small test program called socktest.tgz  located at
> http://vso.cape.com/~nhv. Unfortunately, you have to download most of the
> flightgear source and libraries to use it. But it does follow a lot of
what
> you said regards networks,UDP vs TCP/IP, etc. and the general approach for
> connecting via a network. I'll be using  merge the OpenGC code with the
> network interface to the flightgear state variables.
>
> Once I get this working, I hope to add it to the FlightGear package and
> continue expanding the flight deck. Will need DEPs (data entry panels),
> system instrumentation, and a few more flight gauges - HSI, radar
altimeter,
> maps, whatever.
>
> Again, thank you for the quick response and info.
>

[Opengc-devel] OpenGC Port/Network

[John W. <ca...@mm...>]

Hi

Thank you Damion, for all the info.

Your explanation was very clear. I'll research the problem further. BTW:
Some older manuals for Borland C++ ( pre 1995) do not call out typename as a
keyword but you would think by now all compilers would include it.

There is a small test program called socktest.tgz  located at
http://vso.cape.com/~nhv. Unfortunately, you have to download most of the
flightgear source and libraries to use it. But it does follow a lot of what
you said regards networks,UDP vs TCP/IP, etc. and the general approach for
connecting via a network. I'll be using  merge the OpenGC code with the
network interface to the flightgear state variables.

Once I get this working, I hope to add it to the FlightGear package and
continue expanding the flight deck. Will need DEPs (data entry panels),
system instrumentation, and a few more flight gauges - HSI, radar altimeter,
maps, whatever.

Again, thank you for the quick response and info.