Remote SurfaceMFD - Integration/Usability Test Source

[Hielor]

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.

 

[yagni01]

Trying to do windows build. Where is sys/*.h being included from? Don't see it in allegro or pthreads-win32. Or the platform sdk.

 

[Hielor]

Trying to do windows build. Where is sys/*.h being included from? Don't see it in allegro or pthreads-win32. Or the platform sdk.

I'll have a look when i get home and see what the windows equivalent is, then put it in a #define if necessary. I also have a few modifications to the subscription processing that need to be tested, which should a) not violate the OO paradigm quite as extensively and b) handle return types that aren't "double" from OrbConnect.


-----Posted Added-----


Version 081114:
Previous versions have been renamed to RemoteMFD-081113.xxx and remain in the same directory. The new versions are RemoteMFD.xxx .

Changes for this version:
-Received values are passed to a function on the display, and are no longer assigned directly to a double pointer. This allows other types (ie, string) to be read from the socket.
-Windows support added. Compiles OK, but doesn't yet run (I had it running before i added the above changes...grrr). Will work on it more tomorrow.


-----Posted Added-----


Update 11/15/2008 5:00 AM EST:
New version uploaded. Changes are very minor. It compiles and runs fine in MS VC++ 2005 Express, but not in MSVS Standard 2008. I suspect that this is a result of the Allegro binaries being incompatible, rather than my source, so I'm not going to worry about solving this at this point in time.

About threading: The way I did it currently, I just use #defines to allow the Windows compiler to convert the POSIX thread commands in the source to Windows API threads commands. Would pthreads-win32 be a better solution? I haven't used it, so don't know what it needs.

 

[yagni01]

New version uploaded. Changes are very minor. It compiles and runs fine in MS VC++ 2005 Express, but not in MSVS Standard 2008. I suspect that this is a result of the Allegro binaries being incompatible, rather than my source, so I'm not going to worry about solving this at this point in time.

I'm getting link errors for allegro in VS2008Express, so I'm assuming thats the same thing you're seeing in the full-up version. I tried rebuilding allegro, but that hasn't worked either. I'll keep trying.

 

[Hielor]

I'm getting link errors for allegro in VS2008Express, so I'm assuming thats the same thing you're seeing in the full-up version. I tried rebuilding allegro, but that hasn't worked either. I'll keep trying.

No actually I'm able to compile and link fine, but I can't run it.

Make sure you have alleg.lib and WS2_32.lib in your additional link thingies in VS.

 

[yagni01]

Got it built and running under VS2008Express. Now need to figure out how to get it in a window so it doesn't mess with my screen rez and that I can see Orbiter

 

[Hielor]

Got it built and running under VS2008Express. Now need to figure out how to get it in a window so it doesn't mess with my screen rez and that I can see Orbiter

test.cpp, line 39:

change:

set_gfx_mode(GFX_AUTODETECT, 1024,768,0,0)

to:

set_gfx_mode(GFX_AUTODETECT_WINDOWED, 1024,768,0,0)

and it might work. Source:
http://alleg.sourceforge.net/stabledocs/en/alleg037.html#GFX_*/Windows

 

[yagni01]

test.cpp, line 39:

change:

set_gfx_mode(GFX_AUTODETECT, 1024,768,0,0)

to:

set_gfx_mode(GFX_AUTODETECT_WINDOWED, 1024,768,0,0)

and it might work. Source:
http://alleg.sourceforge.net/stabledocs/en/alleg037.html#GFX_*/Windows

I'll give that a shot tonight.


-----Post Added-----


I saw that the MFD was configured for a landscape orientation even though you said it was going to be used in portrait mode. I reconfigured (reversed) the height/width and ran all my tests in portrait (that's what I'll be using as well).

I built the project using MSVS2008Express (the free one)

Pthreads. I tried to use the pthread-win32 lib, but kept getting errors. I suggest someone else try it as you may have more luck, but knowing how well Windows doesn't play well with others, I would be prepared to use native threads.

I used the allegro-msvc80-4.2.2 binary package downloaded from http://sourceforge.net/project/showfiles.php?group_id=5665&package_id=168871.

Additional linker dependencies were just WS2_32.lib and alleg.lib

The only unexpected setting was under linker >> system >> subsystem where I had to set it to Windows (/SUBSYSTEM:WINDOWS) to get rid of a winStartup linker error. This was opposite of what I found on the net as a solution.

With the above windowing change, it worked GREAT! Hope this helps.

 

[Hielor]

I saw that the MFD was configured for a landscape orientation even though you said it was going to be used in portrait mode. I reconfigured (reversed) the height/width and ran all my tests in portrait (that's what I'll be using as well).

If you actually have the monitor turned 90 degrees (as I will), you'll have to either rotate the screen through the OS (if your graphics card can handle it) or do it in Allegro. The DisplayLocation struct in RemoteMFD currently has (some) support for rotating displays. Specifically, if in ConfigFile.cpp you add ".rotate()" to the DisplayLocation before passing it to the Display, the display will come out sideways (as if the coordinate frame it was given were rotated).

My plan for supporting portrait was to use/extend this interface, so you can say how you want it oriented (indeed, any arbitrary angle *could* be supported, but I was planning on just using the cardinal ones).

The MFD display collection itself is square currently(768x768); the remainder of the space is currently just used for font/color testing. I'm thinking of having a secondary display (engine/fuel maybe) available to fill the edge.

The only reason it's currently in landscape instead of rotated to portrait is because it's easier to see it that way when i'm developing/testing

Pthreads. I tried to use the pthread-win32 lib, but kept getting errors. I suggest someone else try it as you may have more luck, but knowing how well Windows doesn't play well with others, I would be prepared to use native threads.

All right...I'm not planning on making it much more multi-threaded than it already is, so using native Windows threads on Win32 shouldn't be an issue.

I used the allegro-msvc80-4.2.2 binary package downloaded from http://sourceforge.net/project/showfiles.php?group_id=5665&package_id=168871.

Additional linker dependencies were just WS2_32.lib and alleg.lib

The only unexpected setting was under linker >> system >> subsystem where I had to set it to Windows (/SUBSYSTEM:WINDOWS) to get rid of a winStartup linker error. This was opposite of what I found on the net as a solution.

Next time I try it on Windows (not my major concern tbh) I'll give that a go, thanks.

With the above windowing change, it worked GREAT! Hope this helps.

Awesome, glad to hear it. How does the scaling work for you (window scaling, or also config-file modifications)?

 

[yagni01]

If you actually have the monitor turned 90 degrees (as I will), you'll have to either rotate the screen through the OS (if your graphics card can handle it) or do it in Allegro. The DisplayLocation struct in RemoteMFD currently has (some) support for rotating displays. Specifically, if in ConfigFile.cpp you add ".rotate()" to the DisplayLocation before passing it to the Display, the display will come out sideways (as if the coordinate frame it was given were rotated).

The only reason it's currently in landscape instead of rotated to portrait is because it's easier to see it that way when i'm developing/testing

Ah, but I'm using a 22" widescreen, which will give me two side-by-side - no rotation.

Awesome, glad to hear it. How does the scaling work for you (window scaling, or also config-file modifications)?

Haven't done any scaling yet, just narrowed it to 700 wide to get it 'centered' in the window. If you stay with 768 wide, you may have room for another tape to the right of vspeed (maybe vaccel). Or maybe two narrower ones left and right if you want to keep the ball centered.

Trust me, I'll keep playing with it. :speakcool:


-----Post Added-----


Resizable windows is a function of allegro 4.9 (I'm using 4.2). I've been unable to successfully build that so far, so until I do, I can't test that.