Hi all...
First off, I'd like to invite those of you who are interested in hearing about / working on OpenGC to join one or both of the mailing lists at www.opengc.org
Since there have been a few questions, I figured I'd outline the basic issues/challenges (from my perspective) of porting OpenGC to non-Windows machines.
First the good:
1) Right now there is only one class, ogcFSUIPCDataSource which is truly Windows-only. I don't see any way around this at the present time, since FSUIPC itself is a Windows application. However, aside from this class everything else is generic C++ (John, notes on typename syntax are below).
2) Translating Flightgear data to OpenGC format is simply a matter of writing a new ogcDataSource derived class.
And now for the challenges / things to do:
1) I use package called GLTT for rendering TrueType fonts. http://gltt.sourceforge.net/ You'll need to get this working under your target platform (it's been tested under Linux and OSX alreadly so shouldn't be any problem). In order to compile GLTT, you'll also need to build Freetype (http://www.freetype.org/) which has also been tested on a variety of systems. Unfortunately, I'm unable to offer any advice on non-windows platforms, but the GLTT folks have been very helpful in my experience.
At some point in the not-too-distant future, I'll be switching to GLTT's successor, FTGL, but this shouldn't affect existing gauges at all.
2) main.cpp contains some windows-specific code, namely creating an instance of ogcFSUIPCDataSource. You'll need to change the data source to something that's Linux compatible (presumably ogcFlightgearDataSource). Eventually, main.cpp will be replaced with more intelligent code that reads configuration files, and so forth, but for right now the creation of gauges and data sources is hard coded. It might be possible to get around the FSUIPC problem with IFDEFs, I'll look into it.
3) ogcFlightgearDataSource should be written in such a way that it can compile cleanly on any of the platforms supported by Flightgear itself. I don't know what this will imply in terms of networking code.
Also, in general non-synchronous networking (UDP) would be preferable to synchronous (TCP/IP) in order to achieve maximum possible frame rates and minimize the amount of networking code on OpenGC's end (but this decision is of course left up to whomever implements FlightGear networking).
4) To answer John's question: typename is an ANSI C++ reserved word. I would suspect there is something wrong with your compiler if it's refusing to accept it as valid syntax.
typename simply means that "the word following this statement is the name of some type, but I don't know what type it is". So, you can think of it as a placeholder if you have no idea what data type something is (but you do know that it is _something_). typename isn't commonly used outside of templated classes, which ogcOrderedPair is, but it's actually required on many non-windows platforms when using templates, which is why I added it in the first place (make sense? I don't know if that's a good explanation or not...)
Check to make sure that your compiler understands the standard template libraries (STL).
To summarize, a clean build of OpenGC will require the following:
1) FreeType library
2) GLTT library
3) glut library
4) a valid data source
5) modifications to main.cpp
Keep in mind that you can start with an "empty" ogcFlightgearDataSource for testing purposes. There's nothing that says that a data source _has_ to actually do something. Since ogcFlightgearDataSource will be derived from ogcDataSource, an "empty" derivation would be sufficient to permit compilation (use FSUIPCDataSource as a model).
Any other questions or problems, don't hesitate to ask. I hope to have the CVS repository synced with the current code on my machine either tonight or tommorrow, although there are very few fundamental changes between the two versions.