- Joined
- May 30, 2008
- Messages
- 5,580
- Reaction score
- 2
- Points
- 0
First off: THIS IS NOT A RELEASE. Many things need to be changed or worked on before this is ready to be used out-of-the-box. I ask that you please not fork this, since I'm not going to have the time to support several different versions floating around. You've been warned: if you fork it at this point, you're on your own.
The purpose of this (non-) release is to allow people who are intending to use the final product to begin looking into such issues as dependencies, compile process, and possible design decisions.
Primary things I'd like to know about
-The compile process and platform-specifics. I'm not going to be using this on any platform other than Linux. I don't know what will need to be changed in the source (in the form of #ifdef commands, i suppose) in terms of the Allegro library, networking, and possible other issues in order to get it working on all platforms. Right now I'd like to worry most about Linux and Windows, but if there are people who would like to use it on other platforms let me know.
-Usability. I'm probably going to be using this as one MFD per 13.3" screen running in 1024x768, with the screen vertical, and the primary MFD in the top square 768x768. The bottom 256 pixels will probably be some kind of secondary display, like engines or fuel. I know that some of you (ie, yagni) are planning on having two primary MFDs per screen. At this point I haven't spent much time making sure that everything looks good at other scalings. Most of the individual displays should scale correctly, but this is a chance for you to test it in your specific situation and find any scaling/readability issues. See the section on config files.
Where to get it:
Last updated 11/15/2008
tar format:
https://webspace.utexas.edu/btb289/Thinkpads/RemoteMFD.tar
Does not have a top-level directory.
zip format:
https://webspace.utexas.edu/btb289/Thinkpads/RemoteMFD.zip
Has everything in a top-level directory "RemoteMFD."
There is currently no readme.
Known dependencies:
All Platforms
Allegro Graphics Library, http://alleg.sourceforge.net/
Orb:Connect 1.0 running on the server (for non-test modes)
Compiling:
Linux
If you have the Allegro library installed, you should just need to run "make" in the directory you untarred to. You may need to modify the INCLUDE section in the Makefile to suit your system. You may also need to create an "obj" directory. In fact, you probably will need to do so.
Note that you will need to change the IP address and port of your server in include/Network.h before being able to run in non-test modes. In later versions this will be specified in a config file.
The result of compiling will be a single executable file in the same directory as the Makefile, named "test".
Windows
Known to work under MSVS Standard 2008 and MSVC 2005
Use these instructions to set up a project for Allegro:
http://csfinch.wordpress.com/2008/04/25/setting-up-allegro-422-in-visual-c-08/
Process for MSVC 2005 should be similar.
Note that it currently appears that the Allegro binary files only work with MSVC2005; although the program will compile in MSVS 2008, the resulting executable will crash on launch. I'm working on getting a MSVS 2008 version built.
Note that you will need to change the IP address and port of your server in include/Network.h before being able to run in non-test modes. In later versions this will be specified in a config file.
Running:
Linux
Command line:
>test <test> <config file>
Details: If you have the "test" command line statement specified, the MFD will not attempt to connect to an Orb:Connect server and will just show all displays with default (usually 0) values.
The config file specifies the name of a config file (from the config/ directory) to read. Currently this defaults to "surface." There are no other working options; however, "vtol" can be shown in test mode. Note that "vtol" is not complete and only has the central display.
Windows
The two .bmp files and the config/ directory need to be placed in the directory from which you will run the program. To use test modes, you will need to call it from a command line. Normal mode works just by double-clicking the executable in explorer. (Tested on WindowsXP 32-bit)
Config Files:
Currently, MFDs are specified as components (referred to as Displays) combined in specific ways as defined in a config file. Reading "surface" in the config/ directory should give you a pretty good idea of what components are available and what the various commands do.
Note that the LOCATION specification is as x,y,width,height. There is support in the code for rotating locations by arbitrary angles, but this cannot currently be specified in the config file.
Read Units.h and Units.cpp for what the valid UNITTYPEs and UNITCONVs are. METRIC is Orbiter-standard (with the exception of AUPascals, lol). AMERICAN is what would be used in a normal cockpit for everything except altitude. AMERICAN2 is what would be used for altitude (same as AMERICAN except doesn't switch to nautical miles until 400,000 feet). Specifying any of these in the config file will (should) apply a conversion from Orbiter-standard to the corresponding units. This feature is not fully tested.
-----------------------------------
Well, it's late and I can't really think of anything else. Good luck.
The purpose of this (non-) release is to allow people who are intending to use the final product to begin looking into such issues as dependencies, compile process, and possible design decisions.
Primary things I'd like to know about
-The compile process and platform-specifics. I'm not going to be using this on any platform other than Linux. I don't know what will need to be changed in the source (in the form of #ifdef commands, i suppose) in terms of the Allegro library, networking, and possible other issues in order to get it working on all platforms. Right now I'd like to worry most about Linux and Windows, but if there are people who would like to use it on other platforms let me know.
-Usability. I'm probably going to be using this as one MFD per 13.3" screen running in 1024x768, with the screen vertical, and the primary MFD in the top square 768x768. The bottom 256 pixels will probably be some kind of secondary display, like engines or fuel. I know that some of you (ie, yagni) are planning on having two primary MFDs per screen. At this point I haven't spent much time making sure that everything looks good at other scalings. Most of the individual displays should scale correctly, but this is a chance for you to test it in your specific situation and find any scaling/readability issues. See the section on config files.
Where to get it:
Last updated 11/15/2008
tar format:
https://webspace.utexas.edu/btb289/Thinkpads/RemoteMFD.tar
Does not have a top-level directory.
zip format:
https://webspace.utexas.edu/btb289/Thinkpads/RemoteMFD.zip
Has everything in a top-level directory "RemoteMFD."
There is currently no readme.
Known dependencies:
All Platforms
Allegro Graphics Library, http://alleg.sourceforge.net/
Orb:Connect 1.0 running on the server (for non-test modes)
Compiling:
Linux
If you have the Allegro library installed, you should just need to run "make" in the directory you untarred to. You may need to modify the INCLUDE section in the Makefile to suit your system. You may also need to create an "obj" directory. In fact, you probably will need to do so.
Note that you will need to change the IP address and port of your server in include/Network.h before being able to run in non-test modes. In later versions this will be specified in a config file.
The result of compiling will be a single executable file in the same directory as the Makefile, named "test".
Windows
Known to work under MSVS Standard 2008 and MSVC 2005
Use these instructions to set up a project for Allegro:
http://csfinch.wordpress.com/2008/04/25/setting-up-allegro-422-in-visual-c-08/
Process for MSVC 2005 should be similar.
Note that it currently appears that the Allegro binary files only work with MSVC2005; although the program will compile in MSVS 2008, the resulting executable will crash on launch. I'm working on getting a MSVS 2008 version built.
Note that you will need to change the IP address and port of your server in include/Network.h before being able to run in non-test modes. In later versions this will be specified in a config file.
Running:
Linux
Command line:
>test <test> <config file>
Details: If you have the "test" command line statement specified, the MFD will not attempt to connect to an Orb:Connect server and will just show all displays with default (usually 0) values.
The config file specifies the name of a config file (from the config/ directory) to read. Currently this defaults to "surface." There are no other working options; however, "vtol" can be shown in test mode. Note that "vtol" is not complete and only has the central display.
Windows
The two .bmp files and the config/ directory need to be placed in the directory from which you will run the program. To use test modes, you will need to call it from a command line. Normal mode works just by double-clicking the executable in explorer. (Tested on WindowsXP 32-bit)
Config Files:
Currently, MFDs are specified as components (referred to as Displays) combined in specific ways as defined in a config file. Reading "surface" in the config/ directory should give you a pretty good idea of what components are available and what the various commands do.
Note that the LOCATION specification is as x,y,width,height. There is support in the code for rotating locations by arbitrary angles, but this cannot currently be specified in the config file.
Read Units.h and Units.cpp for what the valid UNITTYPEs and UNITCONVs are. METRIC is Orbiter-standard (with the exception of AUPascals, lol). AMERICAN is what would be used in a normal cockpit for everything except altitude. AMERICAN2 is what would be used for altitude (same as AMERICAN except doesn't switch to nautical miles until 400,000 feet). Specifying any of these in the config file will (should) apply a conversion from Orbiter-standard to the corresponding units. This feature is not fully tested.
-----------------------------------
Well, it's late and I can't really think of anything else. Good luck.
Last edited: