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
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
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
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
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
Check to make sure that your compiler understands
the standard template libraries (STL).
To summarize, a clean build of OpenGC will require
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.