opengc-devel Mailing List for Open-source Glass Cockpit (OpenGC) (Page 11)
Status: Pre-Alpha
Brought to you by:
madmartigan
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(22) |
Nov
(3) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(12) |
Oct
(31) |
Nov
(6) |
Dec
(2) |
2003 |
Jan
(1) |
Feb
|
Mar
(5) |
Apr
(9) |
May
(18) |
Jun
|
Jul
|
Aug
(7) |
Sep
(56) |
Oct
(23) |
Nov
(7) |
Dec
(7) |
2004 |
Jan
(2) |
Feb
(2) |
Mar
(7) |
Apr
(26) |
May
(3) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(6) |
Nov
(5) |
Dec
|
2005 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Damion S. <dam...@ho...> - 2001-11-05 21:06:07
|
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. |
From: Damion S. <dam...@ho...> - 2001-11-05 06:38:33
|
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- |
From: Damion S. <dam...@ho...> - 2001-11-04 00:40:24
|
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- |
From: Damion S. <dam...@ho...> - 2001-10-30 22:58:48
|
> 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- |
From: Damion S. <dam...@ho...> - 2001-10-27 03:11:02
|
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- |
From: Damion S. <dam...@ho...> - 2001-10-26 17:35:36
|
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- |
From: Lance W. <lan...@lo...> - 2001-10-26 10:29:47
|
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. |
From: Lance W. <lan...@lo...> - 2001-10-24 12:04:07
|
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. |
From: Lance W. <lan...@lo...> - 2001-10-24 09:05:33
|
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. |
From: John W. <ca...@mm...> - 2001-10-24 03:02:17
|
(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 |
From: John W. <ca...@mm...> - 2001-10-24 02:55:46
|
----- 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 > |
From: Damion S. <dam...@ho...> - 2001-10-23 23:43:39
|
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- |
From: Damion S. <dam...@ho...> - 2001-10-23 18:11:37
|
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- |
From: Damion S. <dam...@ho...> - 2001-10-23 18:08:30
|
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- |
From: Damion S. <dam...@ho...> - 2001-10-23 18:04:07
|
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. > |
From: Damion S. <dam...@ho...> - 2001-10-23 17:48:51
|
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- |
From: Lance W. <lan...@lo...> - 2001-10-22 13:02:57
|
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. |
From: Lance W. <lan...@lo...> - 2001-10-22 11:41:45
|
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. |
From: Lance W. <lan...@lo...> - 2001-10-22 09:20:52
|
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. |
From: Lance W. <lan...@lo...> - 2001-10-22 09:15:36
|
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. |
From: Damion S. <dam...@ho...> - 2001-10-21 17:19:33
|
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- |
From: Damion S. <dam...@ho...> - 2001-10-21 06:36:20
|
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- |
From: Alasdair C. <ala...@bt...> - 2001-10-20 18:53:42
|
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 |
From: John W. <ca...@mm...> - 2001-10-19 03:33:30
|
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. > |
From: John W. <ca...@mm...> - 2001-10-16 19:43:03
|
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. |