opengc-devel Mailing List for Open-source Glass Cockpit (OpenGC) (Page 10)
Status: Pre-Alpha
Brought to you by:
madmartigan
Menu
▾
▴
opengc-devel — Developer's discussion list
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: Rick M. <ri...@cc...> - 2002-10-23 15:12:23
|
I believe I have everything in place and the aclocal, automake -a, autoconf, and ./configure steps appear to go without error. The make step seems to fail. The last messages I see are as follows: make[2]: *** [ogcDataSource.o] Error 1 make[2]: Leaving directory '/home/rick/opengc/Source/DataSources' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/rick/opengc/Source' make: *** [all-recursive] Error 1 Prior to these statements, I see a number of warning statements ending with "does not give a valid preprocessing token" (e.g., ../../Source/DataSources/ogcDataSource.h:422:3: warning: pasting "->" and "Wind_Velocity" does not givie a valid preprocessing token). Looking through the archives, I did install the fltk rpms (not sure where they fit in) and I also modified CMakeLists.txt to reflect the proper paths. I downloaded the opengc source earlier today via CVS. I am currently running FlightGear (successful build) on this system. Any suggestions would be greatly appreciated. Rick |
|
From: Damion S. <dam...@ho...> - 2002-10-23 02:49:01
|
Hi, Just a quick note to say that the CVS of OpenGC now builds successfully under Linux! X-Plane is the first (and currently only) sim to be supported under both Windows and Linux, but I hope to convert Flightgear over in the not too distant future. A few notes/warnings: 1) I'm currently in the process of stabilizing the build across Windows and Linux, so the CVS might not build correctly under Windows for the next 24 hours. If possible, avoid updating from the CVS until I send a message verifying that everything works. 2) The changes to use FLTK rather than GLUT were quite minor - FLTK has a "Glut emulation mode" which compiles the existing code directly by changing the header to <FL/glut.H> from <GL/glut.h>. _However_, you will need FLTK 1.1 to build OpenGC now. I will be providing more details on this once the build is verified on both platforms. One nice side effect of switching to FLTK is that it removes an external library requirement... Also, I have not had any negative comments about removing the out-of-date makefiles, so this will happen sometime in the next few days as well. Cheers, -Damion- _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 |
|
From: Damion S. <dam...@ho...> - 2002-10-21 04:50:51
|
Hi everyone, I've been working on making the CVS repository of OpenGC run under Linux and have run into a few issues... Most importantly, I've become increasingly frustrated with using Glut as the window manager. Little has been done on the code in the past few years, and because of the restrictive license it was distributed under, this is unlikely to change. Glut also provides little in terms of an application framework (decent menus for instance). I have been working with the Fast-Light Toolkit (FLTK) at my day job for the past year and have decided it's the "way of the future" for OpenGC. Not only is it a more modern code-base, it provides (should we want it) a menuing interface, more advanced mouse interactions, and a number of other cool features. How will this affect you? Well, you won't need Glut anymore to build and run OpenGC. On the other hand, you will need to download and build FLTK. This is a very straightforward process, on both Windows and Linux, and takes only a few minutes. CMake will find the FLTK installation and set up the directories for you (under Windows you may need to use the interface to select the root FLTK directory once, but it will be remembered after that). Hopefully, this conversion will go relatively smoothly. I don't like mucking with the fundamentals of OpenGC, but in this case I think it's for the better. On a possiblly more controversial note, I think that the time has come to enforce the use of CMake as the the only allowable build tool for OpenGC. The alternate makefiles have not been updated for quite some time and are not able to build OpenGC in its current state (even before the changes to support FLTK). Unless someone volunteers to maintain them on a regular basis, I think they should be removed to avoid confusion. I have not committed any of these changes to the repository yet, so speak now.... comments are welcome as always. Cheers, -Damion- _________________________________________________________________ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp |
|
From: Damion S. <dam...@ho...> - 2002-10-13 01:43:14
|
Hi everyone, A user sent me a note that the version 0.3 archives were causing problems, and it appears as if the Windows XP archiver managed to corrupt the zip files. This has hopefully been fixed by issuing a new set of files generated with a 3rd party compressor (denoted by the r2 in the filename). If you've experienced problems, please try the new files. Cheers, -Damion- _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com |
|
From: Damion S. <dam...@ho...> - 2002-10-05 19:10:24
|
Hi folks, OpenGC 0.3 is now available for download. This version adds several new 737 gauges plus preliminary X-Plane 6.30 support. You can reach the download page by visiting http://www.opengc.org Cheers, -Damion- _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com |
|
From: Damion S. <dam...@ho...> - 2002-09-29 20:04:27
|
Hi everyone, I just wanted to give you a quick status update of what I've been doing over the last couple of weeks. 1) X-Plane is supported once again! I've reimplemented X-Plane support using the Plib library (which is already required to build OpenGC). This means that the X-Plane data source should be supported on all platforms (Win/Linux/MacOS X) although I have not had a chance to check support on anything but Windows. The X-Plane data source is still a bit sketchy, but works fine. In particular, byte-swapping over Mac/PC networks is not supported, nor does the data source implement bidirectional communications to request particular sim parameters. If you want to try out X-Plane, look through the code and "check" the appropriate output boxes in X-Plane's data output dialog. Because Austin tends to change things rapidly and unpredictably, the data source in OpenGC will always track a particular version of X-Plane. In this case, only 6.30 or related versions (most of the .20's I think) are supported. 5.xx versions will not work. 2) The file initialization portion of the AppObject has been substantially improved. It now follows a crude finite state machine model, which helps to enforce the order in which things are initialized. ***Please refer to the sample opengc.ini present in the CVS. The new data initialization code is fairly strict in how it wants things done, but is also better about reporting errors and exiting gracefully. Other improvements to the file reader: a) Comment lines using # are supported b) Gauge names have been standardized to GaugeName, rather than ogcGaugeName (there was a mix). For example, the correct name is now Boeing737EICAS, not ogcBoeing737EICAS. I have also reduced the number of parameters parsed in the command line. My opinion (comments welcome) is that the bulk of the initialization should be handled using the INI file, and not the command line. This may break Flightgear support; if so, I apologize. 3) Misc. news I think I've found a memory leak that causes OpenGC to consume an additional 20-30K/sec (under Windows at least). This will eventually overwhelm available memory and crash the program. I'm still trying to determine what's causing this; if anyone has any ideas, let me know. It does not seem to be dependent on which data source is used, so I suspect a gauge. As a final reminder, you will probably have to change your INI file to comply with the reader structure. Cheers, -Damion- _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com |
|
From: Damion S. <dam...@ho...> - 2002-09-14 21:17:06
|
Hi everyone, I've begun preliminary modifications on the ogcDataSource base class to provide the generic ability to get and set values of variables. To clarify the distinction: Old model: all variables are public, access to them is not controlled, writing to flight model is impossible New model: all variables are protected, access to them occurs with Get/Set functions. Writing to flight model occurs with appropriate Set call. To this end I've started putting together compiler macros (defined at the beginning of ogcDataSource.h) which automatically generate the approprate Get/Set functions and member variables from a one-line declaration. This saves you time in coding and makes the header easier to read. I also changed the documentation style, so that the declaration of a single variable now looks like: /** The number of cows being transported */ ogcDataReadMacro(Num_Cows_In_Baggage, int); Note that ogcDataReadMacro does not generate a Set() function; it's intended for variables which are "read-only" as far as the flight model is concerned. Most variables stored in the data source fall into this category. The other macro is ogcDataReadWriteMacro, which generates a Set function that in its default implementation does nothing and should be overridden in a derived class to add specific functionality. Variables which can be written include commanded control surface deflections (for autopilots), nav radio settings, etc. As of right now, these updates do not affect existing code in any way. Although the eventual intent is to have all data members be protected members of the class, they are currently still public to maintain compatibility with existing code. At some point, once the initial conversion is finished, I'll notify the list that we should start converting over gauges, components, and any other code that accesses data sources to the Get/Set model. In most cases the change will be from: localCopy = m_pDataSource->Variable_Name to localCopy = m_pDataSource->GetVariable_Name(); so I don't anticipate that this will be a major problem. If you want to start doing this early, great. If not, that's fine too. Not all of the members of the data source class support Get() operations yet, only those defined using macros. I will have to add additional macros to handle strings and arrays of values (for the engines) and haven't done this yet. To summarize, what you should do now: 1) Look over the header file. Tell me what you like/dislike. Now's the time to complain if it doesn't meet your needs. 2) Begin converting your code to the Get() model, if possible (not yet possible for engines or autopilot code). 3) Feedback! The data source class is central to OpenGC and it's important that it's up to the job. Cheers, -Damion- _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com |
|
From: Damion S. <dam...@ho...> - 2002-09-14 20:51:55
|
Hi, Glad you're excited about the project. OpenGC does not currently support Flightgear on any platform but Linux. This will change as the networking code becomes better developed, but for now the downloadable versions only support FS2000/02 on Windows machines. Your problem is not related to XP, because I use that as my development platform. Can you be more specific about your problem? Does a text window appear at any point? Are error messages displayed? Cheers, -Damion- >From: "Miguel Angel" <man...@wa...> >To: <ope...@li...> >Subject: [Opengc-devel] Help! >Date: Sat, 14 Sep 2002 21:23:58 +0200 > >Hellow folks! > >I´ve just see your great project that it´s already a reality! I´m very >impressed that will be a freeware project like this! >At first, I´m a very flight simulator enthusiast, Every flight simulator >is an art work. That´s I think. > >The other day I saw FlightGear project at AVSIM Home Web. And I decided >to download it. >I was so impressed from the very early version I saw the last year, >than I began to look for all over the FlightGear Web, and I found under >the Screenshots Your great Glass Freeware project. Oh! WOW . I thank, >I found the freeware Project Magenta. It´s wonderfull. > >But, Here is my discontent began! When I installed the program, It >didn´t work. > >Maybe due to my Windows XP Professional Operating System? I´ve just >installed the last Glut dll system and doesn´t work too! > >Would you kindly tell me What is wrong with me. I think I´ve installed >your great program as the instructions tell! > >Please, please give me an answer, please give a solution! > >Greetings and Go on with THE GOOD WORK! _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com |
|
From: Miguel A. <man...@wa...> - 2002-09-14 19:24:07
|
Hellow folks! =20 I=B4ve just see your great project that it=B4s already a reality! I=B4m = very impressed that will be a freeware project like this! At first, I=B4m a very flight simulator enthusiast, Every flight = simulator is an art work. That=B4s I think. =20 The other day I saw FlightGear project at AVSIM Home Web. And I decided to download it. I was so impressed from the very early version I saw the last year, than I began to look for all over the FlightGear Web, and I found under the Screenshots Your great Glass Freeware project. Oh! WOW . I thank, I found the freeware Project Magenta. It=B4s wonderfull. =20 But, Here is my discontent began! When I installed the program, It didn=B4t work.=20 =20 Maybe due to my Windows XP Professional Operating System? I=B4ve just installed the last Glut dll system and doesn=B4t work too! =20 Would you kindly tell me What is wrong with me. I think I=B4ve installed your great program as the instructions tell! =20 Please, please give me an answer, please give a solution! =20 Greetings and Go on with THE GOOD WORK! |
|
From: Damion S. <dam...@ho...> - 2002-09-13 05:00:39
|
Hi... First off, one bug that was my fault. If you've received any errors about "failing to create lock" on the nav directory when doing a CVS update, that was a result of a misconfiguration of CVS on my part. I've patched it temporarily, and I'll have to make some changes in the next couple days to fix it permanently (nothing major though). To change subject, several quick requests regarding checking in code... 1) Please make sure that whatever state the repository is in when you check in new code or modifications is one that can successfully build. Unless the mailing list agrees ahead of time, we should try to keep the CVS version in buildable form. It looks like there should be some files (the new nav stuff) included in /Source/CMakeLists.txt that aren't there - I'm getting unresolved external errors during linking. 2) It's very helpful to others if you add a CVS comment when committing changes. We use a shorthand at work to indicate the nature of the commit: ENH = enhancement/new feature BUG = bug fix (the code compiles, but does the wrong thing) ERR = fix coding error (doesn't compile) An example comment is "ENH: Added Airbus nav display" And, for the questions: Is it possible to rename the "nav" directory to "Nav"? This may be more trouble than it's worth though, but if there's interest in renaming I may be able to do it manually on the server and save some hassle. I like the way the nav stuff is laid out (in terms of the generic structure - cool!), but was a bit curious about the "nav" prefix. Is the intention to distinguish the nav code from other opengc code (prefixed with ogc)? Or should these files be called, for example, "ogcNavWaypoint.h". The main reason I ask is to avoid confusion in the repository about what is OpenGC code and what is 3rd party code (especially since the nav files contain the OpenGC copyright). Thanks, the final bit of news is to check out: http://cvs.opengc.org/opengc/cgi-bin/cvsweb.cgi I don't yet have a link to this page from the OpenGC main page but the repository browsing is fully functional. Cheers, -Damion- _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com |
|
From: Damion S. <dam...@ho...> - 2002-09-13 04:05:38
|
Hi all, With the addition of many new coders recently I thought it might be a good idea to go over a few programming style guidelines. Don't feel bad if you haven't followed them up to this point, since I haven't bothered telling too many people! After getting your feedback, I'll post a version on the website. With large projects (which this is becoming) it's important for all of the code in the project to look similar to avoid confusion by new people. To clarify once again: this list is not a criticism of existing code! I've sorted these by how flexible I think we should be in enforcing guidelines. ----Non-negotiable: 1) Set your editor to insert 2 spaces instead of tabs. With normal tabs, indenting looks different depending on your editor setup. Spaces guarantee a uniform appearance. I eventually hope to have a Perl script to check for hard tabs and clean them up. 2) Insert a blank line at the end of each file to make GCC happy (otherwise warnings result). 3) Member variables (public, protected, or otherwise) are named as m_FooVariable. This allows you to rapidly distinguish between local function variables and class members when reading class functions. 3a) Avoid underscore "_" characters in variable names. The exception to this is the data source (as currently implemented). 4) Class member functions are named FunctionName. Bad names include: functionName, functionname, Function_Name, etc. 5) Ifdef your header files. Don't use weird names (Visual Studio is good at producing unusual ifdefs). 6) Include the copyright in front of each class you author. Be generous with credit: if you base your code on someone else's, give them a contributor credit. ----Somewhat negotiable: 1) Use white space liberally to improve readability. 2) Variable names should describe what they do. Good: m_DistanceToWaypoint, Bad: m_Dw 3) The same goes for function names ----Very negotiable (i.e. up to personal taste but handy): 1) Name pointers as pFoo, and member pointers as m_pFoo. 2) Use doxygen style comments when possible. We don't currently use doxygen - would it be useful to people? 3) Program in as generic a style as feasible. When possible, opt for several classes with specific functionality rather than one mega-class. --- Anyways, let me know what you think. Comments are encouraged. Cheers, -Damion- |
|
From: <jur...@ai...> - 2002-09-12 08:25:30
|
Hi Damion,
and other co-developers,
Can you please create a developer account on opengc for Bart DeVriendt,
he is an expert in Boeing 737 systems architecture and helped me out for
some time now in
developping on my latest additions to the project.
Please send the info to ba...@pe..., he is already member of the
mailing list.
I can guarantee good programming and precision skills. He is also expert in
web
site development and maintenance. So if you would like some help in
updating the web page,
I'm sure he'll be glad to.
By the way, I have udated my initial version of the ND display, it is a
pre-alpha release..., only for visualisation purpose, not
yet for flight use. Lat Lon coordinates of the plane are stillnot correct,
but it already gives you a good idea of how
it will look like.
To install add
NEWGAUGE
ogcBoeing737NAV
30 30 0.8 0.80
ENDGAUGE
I started off with the freeware super flight planner navdata but now found
a better source. The next nav database version will
be used from DAFIF Edition 7 (DIGITAL AERONAUTICAL FLIGHT INFORMATION DATA
).
And it's also freeware. Thanks Bart, for that hint.
Thanks in advance,
J. Roeland
|
|
From: Damion S. <dam...@ho...> - 2002-09-07 18:22:33
|
Hi, An early version of message passing in OpenGC is now working. Messages are of type ogcMessage, an enumerated type defined in ogcMessages.h. A message may be dispatched by the appobject and consists of an ogcMessage defined in the messages header and a void pointer to an arbitrary piece of data. Many times the void pointer will just be null. This is loosely similar to the message passing style in many windowing interfaces. Messages can be generated in a variety of ways, including (but not limited to): 1) Keyboard events 2) Mouse click events 3) Internal events within gauges (if a gauge does processing of some sort and decides it needs to inform the world of the results). 4) Other internal events within OpenGC (RenderWindow, App, etc.) I have not yet implemented the ability to read text file definitions for mapping key presses to messages, although I hope to by early next week. For now, I've implemented a simple gauge called ogcKeypad which consists of a numerical keypad (telephone style) and calculator style display. Hitting buttons with the mouse fires off messages to the application, and these eventually percolate back down to the display and cause it to update. It's important to note that the display need not be a member of the ogcKeypad gauge for this to work; the connection between buttons and keypad is handled entirely through messages. To try out the gauge, use the following opengc.ini fragment: NEWGAUGE Keypad 10 10 1.0 1.0 ENDGAUGE None of this code affects the function of existing gauges, however I've modified the CMakeLists.txt file so you should re-run CMake prior to building. Cheers, -Damion- _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com |
|
From: Damion S. <dam...@ho...> - 2002-09-05 20:27:59
|
Hi, I've been kicking a few ideas around in my head and would like to solicit comments on the following ideas: 1) An OpenGC namespace. Instead making the distinction between OpenGC and "the rest of the world" based on naming convention (i.e. ogcDataSource) the distinction would be enforced with the namespace command. Within the namespace you would use DataSource, and outside of the namespace ogc::DataSource. 2) A substantial overhaul of the data source base class. There are several problems with my original design for the data source: a) All of the member variables are public, so read/write control is not enforced. An object in OpenGC can modify the data source without any other gauges knowing this occurred; they assume the value they see is from the sim. b) There is no way to know whether or not a particular data source is capable of reading/writing a particular piece of data. c) For that matter, there is no way at all to write data back to the flight model since the data source updates itself completely in a destructive fashion once per rendering cycle. It is essence read-only as far as interacting with the sim goes. So, how do we get around this? What I've come up with so far is a scheme that would resemble the following. The base class provides two accessor functions, GetValue() and SetValue(). Within a gauge, you refer to a particular piece of data using an enum. For example, to access the altitude in meters, you'd call GetValue(Altitude_Meters). Setting of values would be handled in a somewhat different fashion. The data source would collect all of the SetValue() calls that occur within a single rendering cycle without modifying the local values modified by the set call. At the end of the rendering cycle, the specific implementation of the data source (FSUIPCDataSource, for example) would be responsible for writing as much of this data as possible back to the sim. The other option, aside from an enum-based approach with the Get/SetValue() commands would be to code Get and Set functions for each variable defined in the data source. The default Get function would return a copy of the value stored in the data source and default Set function would do nothing, leaving specific implementation of the Set function up to the derived class. Though this would (probably) be more work than the enum approach, it might be more flexible. Each approach has it's ups and downs. Thoughts/comments? Cheers, -Damion- _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx |
|
From: Damion S. <dam...@ho...> - 2002-09-05 20:06:24
|
Hi, >I found a new dataset which is also freeware and up to date and that >contains all data as far as I could verify... >So it might be that I will use this dataset instead as it is directly >sourced from Jeppesen data. As long as it's freeware and legal I'm happy with any data source. I'm certainly not an expert in geographic data handling! >Also, just a remark, not a critisism. I find the current way the >geographical points are implemented object >orientally wise insufficient for the requirements of my new gauge so I >think of rearranging that also. Could you explain? Do you mean the mapping between screen coordinates and "physical" OpenGL coordinates? What would you like to see changed? >I hope to finish this project by the end of october 2002, but not to let >you wait until then, I will gradually start >updating my sources in opengc so you can start looking, or giving comments >about it. My only request is to please make sure that things are uploaded in "buildable" form. Having a functional Nav display will be an incredible leap forward for the project. Cheers, -Damion- _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com |
|
From: <jur...@ai...> - 2002-09-04 11:16:47
|
Hi mailing list, dear co-developers of openGC After inserting the Boeing 737 digital vertical speed gauge and analog flap indicator, I would like to tell you about my new project, a Boeing 737-800 NAV display containing not only nav radio info and distances but also waypoints, vor stations around, airports, flight plans and airway segments from a range of 20NM up to a range of 160 NM. I allready started developments and at this point the new NAV can allready handle my lat lon coordinates. Herefor, I will add a new (and neat) object in the project called RijksDriehoeksHayfordConverter which is a very good convertor object from latitude longitude WGS84 coordinates to a 2D projection on screen. The main idea is to make it modular as a component, so that you can incorporate this NAV display in your own gauge compositions in the glass cockpit display. (see B737-800 which can display the nav display in three different ways.) So, wrapping different gui's around should not be a problem. I think boeiing is using the same kind of NAV displays these days in their latest models from the 737 till the 777. For the nav points, Damion suggested me to use the allready present navlist, ilslist, fixlist objects. However, I was a little disappointed when I noticed that a lot of data is not present in the data file of Robin Peel. Especially a lot of waypoints. (eg River at holland coast near Rotterdam). I found a new dataset which is also freeware and up to date and that contains all data as far as I could verify... So it might be that I will use this dataset instead as it is directly sourced from Jeppesen data. Also, just a remark, not a critisism. I find the current way the geographical points are implemented object orientally wise insufficient for the requirements of my new gauge so I think of rearranging that also. However, I plan to make the new objects compatible with the allready existing ones so that if anybody wants, he can choose between the two sets. I hope to finish this project by the end of october 2002, but not to let you wait until then, I will gradually start updating my sources in opengc so you can start looking, or giving comments about it. So everybody, if you find something missing from the original NAV displays, please let me know and I'll try my level best to incorporate your wishes. Also, concerning my previous additions, the Boeing 737 digital vertical speed gauge and analog flap indicator, feel free to comment. Jurgen Roeland. |
|
From: Damion S. <dam...@ho...> - 2002-09-02 03:55:18
|
Hi, I've fixed a few problems with the 777 VSI related to the exponential vertical scale. The changes are relatively minor, but the errors were bothering me. Cheers, -Damion- _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx |
|
From: Damion S. <dam...@ho...> - 2002-08-27 19:02:39
|
Hi everyone, We've picked up a few new developers recently and I thought it would be a good time to udpate the format of the header placed at the top of each source file. Specifically: 1) Copyright is now listed as applying to both the original author of a file and any contributing authors. This is not a change, merely a clarification. 2) CVS tags have been added to display the file name and last modification information. Note that the "author" listed in this section is the cvs username of the author of the most recent change, not the authors listed in (1). This is who to yell at if the file is broken ;-) Everything else is unchanged. Please check to make sure that you're given credit in files you originated or contributed to. Note that this header is only used in files developed as part of OpenGC. Other code included in OpenGC but which comes from other sources should retain whatever header was found in the source material. What defines a "contribution" to a file? I'll leave that up to everyone's discretion. I would suggest that minor bug fixes do not warrant inclusion in the header. However, I want to avoid hard feelings about credit, so feedback is welcome. This hasn't been a problem so far, and I don't anticipate it being one in the future. I'm nearly finished with a web CVS interface to the "new" repository, and plan to provide tarball access to the nightly source tree via a cron job at some point in the not too distant future. Over the next few months, I'd like to get doxygen up and running, so if you notice the format of comments (primarily in the base classes) starting to change, that's why. Cheers, -Damion- _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx |
|
From: Damion S. <dam...@ho...> - 2002-08-19 17:59:23
|
Hi, I assume the message is in German, but I'm afraid my one year in high = school is not enough to be able to understand the error message. I've = never run accross an error like this, perhaps someone else can offer = advice? -Damion- ----- Original Message -----=20 From: Thorsten Wolter=20 To: ope...@li...=20 Sent: Tuesday, August 13, 2002 1:11 PM Subject: [Opengc-devel] (no subject) Hello, I wanted to use OPENGC. But I can not start it, because I get the = message: Der Prozedureinsprung "_job_func" wurde in der DLL "MSVCR70.dll" nicht = gfunden. I have installed MSVCR70.dll in my windows/system. Can you help me? Thorstn |
|
From: <Tho...@t-...> - 2002-08-13 17:11:59
|
Hello, I wanted to use OPENGC. But I can not start it, because I get the = message: Der Prozedureinsprung "_job_func" wurde in der DLL "MSVCR70.dll" nicht = gfunden. I have installed MSVCR70.dll in my windows/system. Can you help me? Thorstn |
|
From: Alfred A. <alf...@co...> - 2002-07-23 00:38:05
|
How do I get the opengc0.2 source version of the june 0.2 binary release from the CVS site? Al Adkins |
|
From: Tim O. <wh...@ho...> - 2002-07-21 22:41:23
|
Hello all,
I am looking for download areas for the following libs:
libz.lib
net.lib
sg.lib
sl.lib
ssg.lib
ssgAux.lib
ul.lib
I have resolved the compiler issues with freetype and ftgl and now, I need
these libraries in order to compile, but have had little luck locating them
on the net
thank you,
tim
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
|
|
From: Damion S. <dam...@ho...> - 2002-03-24 19:48:28
|
Hi everyone... (apologies for duplicate messages) This is to inform you that we have completed our move from the Sourceforge cvs servers to a new machine, which will allow more flexible directory management. The new cvsroot is: cvs.opengc.org:/opengc Anonymous read-only access is availabe via: cvs -d :pserver:an...@cv...:/opengc login Respond with the password: opengccvs If you are a developer and would like write access to the repository please send email to da...@op... and I will create an account for you. The Sourceforge CVS site is now out-of-date, and will eventually be removed, although we will likely be hosting the mailing lists, forums, and web site through them for quite a while. Also, because of the number of people who are becoming interested in the project, I would like to switch primarily to the mailing lists rather than personal mailings (when the topic is of general interest). There are currently two mailing lists, opengc-devel and opengc-announce, which you can join through the web site. All future announcements will be made through one of the two opengc lists, so join now if you want to be notified of future changes. Thanks, -Damion- _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx |
|
From: Damion S. <dam...@ho...> - 2002-03-19 17:48:48
|
Hi, > to simulate the GC stuff. How easy is it to design a new instrument with > OpenGC? This is the point of OpenGC, so the answer is "fairly easy", provided you are comfortable working with C++ and OpenGL. Assuming you are using a supported Sim (Flightgear or FS200x currently), you'd only have to write the gauge/instrument itself. If you're using an unsupported sim or some other data source, you'd have to write a subclass of ogcDataSource in order to acquire data for the displays. As a reference, I've been able to prototype relatively simple gauges and get something working in a few hours. Obviously, the more complex your gauge is the longer it will take to write. As a programming strategy, you should think about breaking a gauge (instrument) down into "gauge components". For instance, a Boeing 777 PFD contains an artificial horizon, heading indicator, airspeed indicator, etc. It's very possible that your project could start with some of the existing components and modify size, color, and a few other details to achieve what you're looking for. Incidentally, the CVS repository has recently moved, I'll be posting a message to this list as soon as anonymous CVS is up and running. If you run into any snags writing a gauge or have more questions, let me know. Cheers, -Damion- ----- Original Message ----- From: "David Findlay" <dav...@ya...> To: <ope...@li...> Sent: Monday, March 18, 2002 6:47 AM Subject: [Opengc-devel] Custom Glass Cockpit > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'm fiddling with a bit of an aircraft design, and am looking to use OpenGC > to simulate the GC stuff. How easy is it to design a new instrument with > OpenGC? The instruments I'm looking to do are similiar to ones that would be > used on the Space Shuttle or other such vehicles. How suitable is OpenGC for > this role? BTW, it's not for a real aircraft :-). Thanks, > > David > > P.S. Could you please CC your reply to me. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE8ldO0F2H7v0XOYBIRAhlVAKC4y/q/49At/+oYxfeiG7mFv/5AqQCfZvmU > ii+xniBeGcBZh9Oigx1gS78= > =mvdP > -----END PGP SIGNATURE----- > > _______________________________________________ > Opengc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengc-devel > |
|
From: David F. <dav...@ya...> - 2002-03-18 11:47:06
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm fiddling with a bit of an aircraft design, and am looking to use OpenGC to simulate the GC stuff. How easy is it to design a new instrument with OpenGC? The instruments I'm looking to do are similiar to ones that would be used on the Space Shuttle or other such vehicles. How suitable is OpenGC for this role? BTW, it's not for a real aircraft :-). Thanks, David P.S. Could you please CC your reply to me. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8ldO0F2H7v0XOYBIRAhlVAKC4y/q/49At/+oYxfeiG7mFv/5AqQCfZvmU ii+xniBeGcBZh9Oigx1gS78= =mvdP -----END PGP SIGNATURE----- |
1 message has been excluded from this view by a project administrator.
