Remote SurfaceMFD - First Flight Test

Hielor

Defender of Truth
Donator
Beta Tester
Joined
May 30, 2008
Messages
5,580
Reaction score
2
Points
0
First flight test of my remote surface MFD. Apologies for the low quality and awkward angle; the only camera I have is attached to my (rather awkwardly large) desktop replacement laptop.

http://www.youtube.com/watch?v=Gbx2Ioz6dmA

Each computer's important specs:
Desktop:
Athlon 64 3400+
1 GB ram
GeForce 6800 GT (256 MB)
19" monitor running at 1280x1024
Windows XP

Laptop:
Thinkpad 600E 2645-4AU
Pentium II 366 MHz
128 MB ram
no graphics card
13.3" screen at 1024x768
Linux

Analysis: The setup performed better than I had anticipated, both on the laptop itself (in terms of graphics display rate and quality; it was keeping up with the 20Hz data rate without a hitch, with very little visible stuttering or lag) and in terms of the connection speed. My apartment complex's router is a PITA at times, and I suspect that I'll have no problems at all once I get my own to reduce the extra traffic floating around.
 
Very nice! It appeared to be smoother than the internal MFD.
 
Very nice! It appeared to be smoother than the internal MFD.

Thanks, and the only reason it was smoother in that video is because i had the internal one at only 4 Hz
 
That is great.
Are you planning to do the HUD as well?

Haha, well, I certainly have enough of the thinkpads to spare one as a HUD. I haven't thought about that too much, but I think the screens will be bright enough to pull it off.

Of course, before I even start thinking about a HUD I'll need to upgrade from a 19" monitor as my primary visualization...
 
I'm sorry, did someone say...

Awesomeness? :cheers:

EDIT: I'm sorry, did someone say...

What happened to the sound? :P

Haha thanks. I stripped the sound from the video because
a) I didn't have orbitersound running, so there'd be nothing to hear and
b) after the first barrel roll, I exclaimed "oh, that's cool" (which is why I was pointing to the screen at around 0:54, to explain to my roommate who was behind the camera) when I saw how closely the artificial horizon on the MFD was following the "real" one in the sim. I don't like the way my voice sounds in playback, so I cut it.
 
Haha thanks. I stripped the sound from the video because
a) I didn't have orbitersound running, so there'd be nothing to hear and
b) after the first barrel roll, I exclaimed "oh, that's cool" (which is why I was pointing to the screen at around 0:54, to explain to my roommate who was behind the camera) when I saw how closely the artificial horizon on the MFD was following the "real" one in the sim. I don't like the way my voice sounds in playback, so I cut it.

What? No orbitersound? What are you, mad? :P

And don't pay out your own voice... that lowers your self-esteem. Believe me, I've been there. ;)
 
What? No orbitersound? What are you, mad? :P
No, I just want as controlled a testing environment as possible. The thing isn't 100% stable yet, and if it crashes I don't want a bunch of mods running when I go through the stack / debugging info. What you didn't see was a packet sniffer running on the desktop, behind Orbiter, and a Visual Studio window already attached to the process just in case.

I suspect that most of the problems I've had are due to the heavy traffic on my apartment's network, and hopefully getting myself a router to isolate the computers will fix that.


And don't pay out your own voice... that lowers your self-esteem. Believe me, I've been there. ;)
Actually, I really don't care--i mean, heck, i'm an actor, if i had issues with people hearing me, getting on stage would kind of suck (Clear Creek Country Theatre in League City, btw, in case any of you in that area have been there); but since this was a demonstration of the MFD and not how surprised I am when my software works well, I didn't think it added anything of value ;)
 
No, I just want as controlled a testing environment as possible. The thing isn't 100% stable yet, and if it crashes I don't want a bunch of mods running when I go through the stack / debugging info. What you didn't see was a packet sniffer running on the desktop, behind Orbiter, and a Visual Studio window already attached to the process just in case.

That's a pretty good point. So I assume you were using the default DG for that flight.

I suspect that most of the problems I've had are due to the heavy traffic on my apartment's network, and hopefully getting myself a router to isolate the computers will fix that.

My limited education tells me that you're right on the money with that idea. That is, if you consider the portion of the Yr 11 VCE curriculum that is devoted to networks as limited. ;)
 
That's a pretty good point. So I assume you were using the default DG for that flight.
Yup. The only mods I had enabled for that run were OrbConnect and the Scenario Editor.


My limited education tells me that you're right on the money with that idea. That is, if you consider the portion of the Yr 11 VCE curriculum that is devoted to networks as limited. ;)
Also, most of my crashes seem to occur when I'm trying to connect the client to the server--I'm getting a bunch of duplicate ACKs. Basically, from the server's point of view:

Client: "Hey, I'd like to connect."
Server: "Ok!"
Client: "Hey, I'd like to connect." (identical to last one)
Server: "Uh...dude, I already said 'ok.'"
Client: "Hey, I'd like to connect." (again, identical)
Server: "Damnit, go away!" (crashes out of frustration)
 
Also, most of my crashes seem to occur when I'm trying to connect the client to the server--I'm getting a bunch of duplicate ACKs. Basically, from the server's point of view:

Client: "Hey, I'd like to connect."
Server: "Ok!"
Client: "Hey, I'd like to connect." (identical to last one)
Server: "Uh...dude, I already said 'ok.'"
Client: "Hey, I'd like to connect." (again, identical)
Server: "Damnit, go away!" (crashes out of frustration)

Be careful using that as a pickup line. Women are harder to debug.:rofl:
 
Be careful using that as a pickup line. Women are harder to debug.:rofl:

ROFL. Yeah, it's annoying--they're completely non-deterministic, and most definitely not open-source.
 
Showing off, eh? :P
Actually, it's more that I couldn't even see the built-in surfaceMFD from where i was sitting, so I didn't particularly care about it. Okay...maybe a bit of it was showing off, lol...

Any idea what the framerate hit is?
Framerate hit on the sim of it spitting out all that data 20 times a second?
It wasn't a noticeable difference, but if you want when I get home I can put a timer up and get you a precise answer.
 
Framerate hit on the sim of it spitting out all that data 20 times a second?
It wasn't a noticeable difference, but if you want when I get home I can put a timer up and get you a precise answer.


You could probably balance that out with lower MFD refresh rates or turning them off completely...


That's one hell of a good job on the external MFD :)
 
Framerate testing
The test run was the first minute of the "Glider launch 1" default scenario in the tutorials folder. Average was determined by the total number of frames run divided by the sim time, at approximately the 1-minute mark.

Tests were run using Direct3D HAL with "try stencil buffer" checked. Full screen, 1280x1024x32, with vertical sync disabled (to allow higher values than 60). Only active module was OrbConnect. All visual effects were on, all "realism" parameters were on.

Run 1: External View (didn't touch the camera controls from default)
Frames: 7815
Time: 60.145s
Average FPS: 129.94

Run 2: Glass Cockpit, both MFDs off, HUD off
Frames: 8321
Time: 60.312s
Average FPS: 137.96

Run 3: Glass Cockpit, SurfaceMFD on left panel, default MFD refresh (4 Hz)
Frames: 8023
Time: 60.401s
Average FPS: 132.83

Run 4: Glass Cockpit, SurfaceMFD on left panel, MFD refresh 20 Hz

Frames: 7729
Time: 60.195s
Average FPS: 128.40

Run 5: Glass Cockpit, no built-in MFDs, remote surface MFD running at 4 Hz
Frames: 8232
Time: 60.233s
Average FPS: 136.67

Run 6: Glass cockpit, no built-in MFDs, remote surface MFD running at 20 Hz
Frames: 8178
Time: 60.205s
Average FPS: 135.84

So in answer to your question, yagni: the framerate hit for my MFD running at 20 Hz is less than the framerate hit for the built-in one running at 4, since the only additional load is in fetching the data and no additional drawing needs to be done on the server.
 
Anyting over 60fps is ideal. IMHO, I see no difference one way or the other between 128fps and 137fps. I'd be more interested in comparisions of the network data bandwidth used between 4hz and 20hz. :)
 
Back
Top