Beta Release: GPT (cockpit texture extraction, remote cockpit control, shm mirror)
-
Would it be possible to use OpenGL/D3D for rendering mfd’s on the slave pc?
That way, you would be able to use antialiasing…. -
@Vip:
Would it be possible to use OpenGL/D3D for rendering mfd’s on the slave pc?
That way, you would be able to use antialiasing….The DisplayReceiver uses D3D on windows and OpenGL on linux where these APIs are available. It is that the java JRE installed on that slave system is what decides exactly what implementation is used.
However that is actually not what decides the AA. AA is done at primitive drawing shapes level (in the sim itself).
- Are your MFDs in the sim rendered with better AA than GPT? (zoom so they are of the same size and have a look)
When GPT downloads the texture I am simply using “StretchRect” (http://msdn.microsoft.com/en-us/library/windows/desktop/bb174471(v=vs.85).aspx)) to copy the src surface into an extra vram surface and then I download it to system ram with “GetRenderTargetData” (http://msdn.microsoft.com/en-us/library/windows/desktop/bb174405(v=vs.85).aspx)).
But I do not really know how AA is managed on this level, but I would expect that either it’s all flattened instantly, or it’s not and I’m not downloading an AAed texture (which would require me to download multiple layers instead, or a higher virtual resolution?). Again, This is the first time I’ve done any real stuff with d9d so I don’t really know what to do about it :P.
-
In post #61, you said:
Also the extra thread spawned by GPT’s DisplaysTransmitter is currently locked to roughly 50 Hz (configurable in the ini file). Even though your game might slow down to below 50 (let’s say 20 in your case), the export still runs at 50 Hz, which is not very good. Perhaps in the future I will implement a solution which gets around this.For those of us who do dip below 50 FPS, do you have the opportunity to look into this?
Bst Rgds
Well, it’s doable. I will see if I can find some time to look into it this weekend. It’s a little bit more difficult than it sounds though due to Direct3d’s asyncronous nature.
-
The DisplayReceiver uses D3D on windows and OpenGL on linux where these APIs are available. It is that the java JRE installed on that slave system is what decides exactly what implementation is used.
However that is actually not what decides the AA. AA is done at primitive drawing shapes level (in the sim itself).
- Are your MFDs in the sim rendered with better AA than GPT? (zoom so they are of the same size and have a look)
When GPT downloads the texture I am simply using “StretchRect” (http://msdn.microsoft.com/en-us/library/windows/desktop/bb174471(v=vs.85).aspx)) to copy the src surface into an extra vram surface and then I download it to system ram with “GetRenderTargetData” (http://msdn.microsoft.com/en-us/library/windows/desktop/bb174405(v=vs.85).aspx)).
But I do not really know how AA is managed on this level, but I would expect that either it’s all flattened instantly, or it’s not and I’m not downloading an AAed texture (which would require me to download multiple layers instead, or a higher virtual resolution?). Again, This is the first time I’ve done any real stuff with d9d so I don’t really know what to do about it :P.
Cool - thanks!
No, the MFD’s on the slave PC are looking the same as in the jet; I was merely asking because some of the lines do contain a bit af “jagginess” and knowing my slave computer can do AA….well I just had to ask.
I’ll try and play around with it on the slave computer and see if turning AA on / off makes any difference. -
@Vip:
Cool - thanks!
No, the MFD’s on the slave PC are looking the same as in the jet; I was merely asking because some of the lines do contain a bit af “jagginess” and knowing my slave computer can do AA….well I just had to ask.
I’ll try and play around with it on the slave computer and see if turning AA on / off makes any difference.Nah it won’t make a difference with normal MSAA (though FXAA MAY help). This is because (MS)AA is done by knowing what primitive shapes (triangles, lines etc) were painted in the first place (they can be drawn at higher resolution for example and then sampled down), but once the graphics are copied to the slave PC, they are just 1 texture (block of pixels). So the slave PCs video card has no idea what to smooth, except you might try some image analysis technique like FXAA, that may work, or make things worse ^^.
-
Got it - 'makes sense. I can’t AA a JPEG image…DOH!
-
Some comparison performance numbers:
No GPT w/1PC: 33/22 fps (external view/internal view)
GPT w/2PCs: 22/16
GPT w/1PCs: 17/11
BMS Extract: 16/12Conditions:
Main PC = Q6600 2.4Ghz, 4GB DDR, WinVista 32bit, ATI HD 6770
Slave PC = DualCore 2.13Ghz, 3GB DDR, WinXPSP2 32bit, ATI x1900
FalconBMS 432U2, 1920x1200x60hz, Level 2 graphics, all options but VSync, One point from full on graphics sliders
test mission = saved missions/takeoff at runwayComments:
-
BMS extactor (BMSE) vs GPT w/1PC (med-low specs by todays standards, but runs BMS fine) perform almost the same, but the big difference is that BMSE does not support DisplayLink USB LCDs as does GPT. I have to use video card monitor(s) for the MFDs with BSME. On my system, it cost 1/2 my frame rate either way. For fast systems, im sure its less and running off one PC for GPT may be practical.
-
Running GPT in Master/Slave distributed processing mode, the frame rate hit was 1/3 instead of 1/2. The down side is that I have to connect the USB LCDs (or vga monitors) to the slave PC instead of the master/main game PC. This would require longer USB cables or even a powered USB Hub so I can place the LCD MFDs on my main gaming table. Regardless, there is a frame rate gain in using the distributed mode of GPT and that it supports DispayLinked USB monitors that makes GPT better than BSME, for me anyways.
-
I can make up the loss of frame rate in using GPT on two PCs if I lower my game resolution from 1920x1200 to 1680x1050 as the lower resolution raises the frame rate about 15-25%. FalconBMS stills looks OK at this setting, but it isnt as pretty. So its a trade off of frame rate quantity for visual quality.
Notes:
-
Tried changing the “DisplayTransmitter” config file’s “max_hz = 50” to 30, and it slowed the update to the slave PCs MFDs but no gain in
frame rate. So there was no advantage in changing it in my tests. -
One of the problems in using multiple monitors with FalconBMS is that when you move your cursor off the main screen while playing, when you click the mouse you are sent to the desktop. Not a good thing while flying! So the good ole boys of BMS did anticipate this and provided a means to keep the cursor on the main monitor. This is good for those that dont need to use the cursor on the secondary MFD monitors (ie using TM Cougar MFD bezels or touch screens), but no help for those that want to use the mouse to click virtual OSBs on secondary MFDs monitors (ie using Helios software MFD bezels off 1 PC). Using GPTs remote key program is a way around this due to the fact that the secondary slave PC is being used to make the MFD mouse clicks.
To capture the cursor to stay on the main game monitor:
edit: “falcon bms.cfg” file
find or add: set g_bEnableExclusiveMouseCapture 1 // value = 1 enables the capture of the mouse to main window, 0 disables capture -
-
Some comparison performance numbers:
No GPT w/1PC: 33/22 fps (external view/internal view)
GPT w/2PCs: 22/16
GPT w/1PCs: 17/11
BMS Extract: 16/12Conditions:
Main PC = Q6600 2.4Ghz, 4GB DDR, WinVista 32bit, ATI HD 6770
Slave PC = DualCore 2.13Ghz, 3GB DDR, WinXPSP2 32bit, ATI x1900
FalconBMS 432U2, 1920x1200x60hz, Level 2 graphics, all options but VSync, One point from full on graphics sliders
test mission = saved missions/takeoff at runwayComments:
-
BMS extactor (BMSE) vs GPT w/1PC (med-low specs by todays standards, but runs BMS fine) perform almost the same, but the big difference is that BMSE does not support DisplayLink USB LCDs as does GPT. I have to use video card monitor(s) for the MFDs with BSME. On my system, it cost 1/2 my frame rate either way. For fast systems, im sure its less and running off one PC for GPT may be practical.
-
Running GPT in Master/Slave distributed processing mode, the frame rate hit was 1/3 instead of 1/2. The down side is that I have to connect the USB LCDs (or vga monitors) to the slave PC instead of the master/main game PC. This would require longer USB cables or even a powered USB Hub so I can place the LCD MFDs on my main gaming table. Regardless, there is a frame rate gain in using the distributed mode of GPT and that it supports DispayLinked USB monitors that makes GPT better than BSME, for me anyways.
-
I can make up the loss of frame rate in using GPT on two PCs if I lower my game resolution from 1920x1200 to 1680x1050 as the lower resolution raises the frame rate about 15-25%. FalconBMS stills looks OK at this setting, but it isnt as pretty. So its a trade off of frame rate quantity for visual quality.
Notes:
-
Tried changing the “DisplayTransmitter” config file’s “max_hz = 50” to 30, and it slowed the update to the slave PCs MFDs but no gain in
frame rate. So there was no advantage in changing it in my tests. -
One of the problems in using multiple monitors with FalconBMS is that when you move your cursor off the main screen while playing, when you click the mouse you are sent to the desktop. Not a good thing while flying! So the good ole boys of BMS did anticipate this and provided a means to keep the cursor on the main monitor. This is good for those that dont need to use the cursor on the secondary MFD monitors (ie using TM Cougar MFD bezels or touch screens), but no help for those that want to use the mouse to click virtual OSBs on secondary MFDs monitors (ie using Helios software MFD bezels off 1 PC). Using GPTs remote key program is a way around this due to the fact that the secondary slave PC is being used to make the MFD mouse clicks.
To capture the cursor to stay on the main game monitor:
edit: “falcon bms.cfg” file
find or add: set g_bEnableExclusiveMouseCapture 1 // value = 1 enables the capture of the mouse to main window, 0 disables captureThanks for the tests AV8R!
In theory the BMS own extractor should be the fastest (by far) in all cases, especially the single PC case. For some reason it isn’t, maybe due to how Nvidia and Amd poorly implement multi surface rendering / 3d context resource sharing, maybe due to how windows doesn’t like multiple d3d render windows from the same process, maybe something else, who knows :P.Let me explain a bit more clearly about the GPT frame rate setting.
There are a few steps done by the displaystransmitter which is injected into BMS:Step 1: Downloading the raw cockpit displays texture through a set of buffers (to minimize performance impact)
Variant A (if using network transmissions)
Step 2: Compressing the downloaded cockpit texture to a JPG image
Step 3: Sending the compressed JPG image
Variant B (if just exposing the raw cockpit texture through local shared memory)
Step 2: Copying texture data to a shared memory section.Step 1 is always performed at the same framerate of the sim, because it is done on the same thread as the sim (I believe this is a requirement of BMS’ particular Direct3d9 use).
Steps 2 and 3 are run on a separate thread to minimize performance impact, and this thread runs at 50 Hz at most.USUALLY step 1 is the heavy step, and thus reducing the frame rate setting of GPT (which only affects steps 2 and 3) will have minimal or no performance impact. So after viewing this, I am now almost certain I will not implement any automatic frame rate controls of steps 2 and 3 - again step 1 already runs slow when the sim is slow.
MAKE SURE IF YOU ARE RUNNING GPT LOCALLY (same computer) THAT YOU CHOSE VARIANT B :).
This is done by setting
[falconhook_shm]
active = 1
[falconhook_socket]
active = 0Only one variant can be active. If both are set to 1 only 1 of them will work. I don’t recall which, sorry ^^.
-
-
There are some changes to shared memory functions with update 3 that I don’t pretend to understand. Will they have any positive/negative effect with your tool ?
-
There are some changes to shared memory functions with update 3 that I don’t pretend to understand. Will they have any positive/negative effect with your tool ?
CobaltUK beat me to the punch….
Apparently BMSU3 now makes the MFD (and other data: HUD/HMS/RWR/DED/PFL) available even without being set to the windowed BMSE (extraction) mode. Im guessing, but I think this was to open up more data for Lightning’s Falcon MFDE code to have access to the MFD info it did not have before.
Again, to echo CobaltUK, does these changes help/hurt or no effect on GPT?
Looks like they also gave us a memory refresh rate control, which might help with the frame rate hit. If so, could GPT make use of this?https://www.benchmarksims.org/forum/showthread.php?11272-Falcon-BMS-4-32-Update-3
_- Fixed exporting displays to shared texture memory area (will work again in the same way that it did for OpenFalcon and BMS 2): Setting g_bExportRTTTextures to 1 will create a shared texture memory area (even w/o external displays enabled), named “FalconTexturesSharedMemoryArea”. This does work as well with double RTT resolution! The shared mem area is not updated every frame, but every g_nRTTExportBatchSize frame (defaults to 2).- Added new options for the shared texture memory area to “Falcon BMS.cfg”:
– set g_bExportRTTTextures 0 // This enables the shared texture memory area for HUD/MFDs/HMS/RWR/DED/PFL. This is independent from BMS external window usage!
– set g_nRTTExportBatchSize 2 // This determines how often the shared texture memory area (if it is enabled) will be updated (every Nth frame, default is 2)._
- Added new options for the shared texture memory area to “Falcon BMS.cfg”:
-
CobaltUK beat me to the punch….
Apparently BMSU3 now makes the MFD (and other data: HUD/HMS/RWR/DED/PFL) available even without being set to the windowed BMSE (extraction) mode. Im guessing, but I think this was to open up more data for Lightning’s Falcon MFDE code to have access to the MFD info it did not have before.
Again, to echo CobaltUK, does these changes help/hurt or no effect on GPT?
Looks like they also gave us a memory refresh rate control, which might help with the frame rate hit. If so, could GPT make use of this?https://www.benchmarksims.org/forum/showthread.php?11272-Falcon-BMS-4-32-Update-3
_- Fixed exporting displays to shared texture memory area (will work again in the same way that it did for OpenFalcon and BMS 2): Setting g_bExportRTTTextures to 1 will create a shared texture memory area (even w/o external displays enabled), named “FalconTexturesSharedMemoryArea”. This does work as well with double RTT resolution! The shared mem area is not updated every frame, but every g_nRTTExportBatchSize frame (defaults to 2).- Added new options for the shared texture memory area to “Falcon BMS.cfg”:
– set g_bExportRTTTextures 0 // This enables the shared texture memory area for HUD/MFDs/HMS/RWR/DED/PFL. This is independent from BMS external window usage!
– set g_nRTTExportBatchSize 2 // This determines how often the shared texture memory area (if it is enabled) will be updated (every Nth frame, default is 2)._
I haven’t used U3, but I’d expect gpt’s displaystransmitter to be mariginally (though might not be much since the copy should be low cost) faster for filling SHM than the built in one, since from what I know the copying step is doing single-threadedly in bms, while the displaystransmitter is multithreaded (taken from discussions I’ve had with some of the bms guys). But again, I might be wrong. I see that the built in one has support for exporting displays frames at rates being sim fps / n ( n = integer) - Depending on how you view it, this might give you better performance. I like to have it every frame though hehe :). Especially if sim fps drops low.
Depending on how the data is exposed, it might be possible for the gpt displaysReceiver to run without the displaystransmitter by just reading the built in SHM.
set the DisplaysReceiver config.xml SHM to FalconTexturesSharedMemoryArea instead of GiGurraTexturesSharedMemoryArea.
WARNING: I have no idea if this will work :P. - Added new options for the shared texture memory area to “Falcon BMS.cfg”:
-
I was able to get Lightning’s MFDE to work with BMS432U3 today, but its problematic when using DisplayLinked USB LCDs as I do. I got MFDE to run off my LCDs, but not quite right yet. So its almost working there. When I just put all the MFD and other gauges and indicators onto a secondary VGA monitor, everything worked fine. The good part of MFDE, is that the frame rate hit even running off one system such as mine, was only a couple of FPS.
So now we have two methods, those that use USB LCDs are the ones that have the most hurdles to over come.
-
I guess we should do some performance tests to see how well the built in SHM exporter works. If it’s really fast maybe I could remove the injected dll solution and make the displaystransmitter a standalone application. This would make a lot of things significantly easier, like transmitting to multiple slaves for example. On the other hand, if it’s standalone it will be very hard to throttle its cpu load based on the sim fps.
-
Im just guessing here, but could the performance difference be like the difference between compiled (MFDE) and uncompiled (GPT) programs?
MFDE is an executable, where as GPT is a set of files and JAVA libraries. Or is this rephrasing what you’ve already said?Also, the jury is still out on how much frame rate hit there is for MFDE in master/slave distributed mode. So we don’t know yet if its faster there.
And, I have not tried your suggestion in targeting GPT onto the new BMS shared memory. Have you?
GiGurra,
To make the DisplayLink USB monitors able to work with MFDE, I had to place one or more MFDE objects (speedometer, altimeter, etc) onto a secondary VGA monitor before the MFDE driven USB monitors would update in real time. If I did not put some objects on a secondary VGA monitor, the USB data was displaying the MFD info that was present at the first seconds of going into the 3D world. That is to say they displayed, but never updated. Does that mean something to you? -
Im just guessing here, but could the performance difference be like the difference between compiled (MFDE) and uncompiled (GPT) programs?
MFDE is an executable, where as GPT is a set of files and JAVA libraries. Or is this rephrasing what you’ve already said?Also, the jury is still out on how much frame rate hit there is for MFDE in master/slave distributed mode. So we don’t know yet if its faster there.
And, I have not tried your suggestion in targeting GPT onto the new BMS shared memory. Have you?
GiGurra,
To make the DisplayLink USB monitors able to work with MFDE, I had to place one or more MFDE objects (speedometer, altimeter, etc) onto a secondary VGA monitor before the MFDE driven USB monitors would update in real time. If I did not put some objects on a secondary VGA monitor, the USB data was displaying the MFD info that was present at the first seconds of going into the 3D world. That is to say they displayed, but never updated. Does that mean something to you?Two things here. Nowadays java no longer is just “interpreted code”. Java byte code (essentially what’s inside the JAR files) is compiled down to native executable binary code just like any C/C++ application. It’s just done at a different phase. While with a C++ program this is done when you build your executable, with java this is instead done during execution (usually during the first few seconds). You can look up JIT compilers to get a better view of how it works, but essentially it finds the tough parts of your application and makes them native, plus adds a lot of optimizations (just like your favorite C/c++ compiler would).
The second thing is that GPT DisplaysTransmitter isn’t java at all, it’s written entirely in C++ with full optimizations (Microsofts VC 2010 compiler).
The other parts of GPT are java, but the performance heavy parts (drawing graphics and compressing/decompressing jpegs) are actually done with extremely performance dedicated external C/C++ libraries: Direct3D and TurboJpeg ;).But bottom line:
A competent C++ programmer will probably write applications that are faster than a competent java programmer. Though it isn’t certain. It depends a lot on what compiler you use and which JRE you run. Many of todays JREs will JIT down a lot of java byte code to native code which is actually faster than what older C++ compilers can optimize to for your average applications. Obviously C/C++ will have less memory footprint if that is something you worry about. For me personally it’s either C++ with boost or Java. I find I program a lot faster in java and produce more robust applications, and often also faster performing applications (Probably because I’m not exactly an expert C/C++ coder, though I do work with it professionally in embedded systems among other things). Wow, this turned into a java vs c++ thing ^^. Thing I don’t like about Java? It’s not a truly free language…About Lightning’s stuff not rendering on displaylink stuff? Hmm I honestly don’t know much about this stuff :). Well I assume he uses some gui toolkit/api for windows that hooks into direct3d or directdraw, and that somehow doesn’t work on those usb screens. GPT uses Direct3D (or OpenGL for linux) also for the mfd rendering, yes, but I believe it falls back on software rendering if no such api is available. In GPT’s case the JRE is really what decides.
WARNING: My Main ISP is down atm, no ETA when it is up so I’m on a slow (3/1 mbit) backup connection instead of my usual (1000/1000) so I cannot host the GPT download links atm. As soon as my normal ISP gets back up you can download GPT again, sry :P.
-
Hi GiGurra,
I’m trying to check out your source, but public/public isn’t working.
$ svn co –username public --password public https://www.gigurra.se/svn/GEAR/GPT/
svn: access to ‘https://www.gigurra.se/svn/GEAR/GPT’ forbiddenI want to try and port the display transmitter client to android, I have a couple of cheap and nasty android tablets that could be MFD displays.
-
Hi GiGurra,
I’m trying to check out your source, but public/public isn’t working.
$ svn co –username public --password public https://www.gigurra.se/svn/GEAR/GPT/
svn: access to ‘https://www.gigurra.se/svn/GEAR/GPT’ forbiddenI want to try and port the display transmitter client to android, I have a couple of cheap and nasty android tablets that could be MFD displays.
Hey.
Sorry you’re right Ive messed up the svn login. It’s fixed now!
DisplaysTransmitter is a dll hook for BMS, but you probably mean DisplaysReceiver.
I do not think it will run on android in the current shape, because 1# it’s too heavy in decompressing jpegs, 2# it uses x86 dlls for fast jpeg decompression.If you switch to a pure java based jpeg decompression I saw 2x the CPU load at least, and I simply don’t think the android unit can handle it. But you are free
to try ofc!If you want it to work on android we really need to change it to a real video stream instead at some point :).
-
Thanks, I’m grabbing the code now. Yep I meant the DisplaysReceiver.
I don’t know if I’ll actually produce anything, and I’m not confident that I’ll be able to get my cheap tablets working because they are VERY slow. Maybe by the time I have something to share there will be faster affordable tablets available
-
Hi GiGurra,
I’ve being trying to make MFD Extractor run for 2-3 days. Failed every time. Can’t do…
HELP !!!
Charly_1VFW.
Sistema operativo: Windows 7 Ultimate, 64-bit (Service Pack 1)
Versión DirectX: 11.0
Procesador GPU: GeForce GT 430
Versión del controlador: 267.85
Soporte de DirectX: 11
Núcleos de CUDA: 96
Reloj del núcleo: 700 MHz
Reloj de sombreado: 1400 MHz
Reloj de memoria: 600 MHz (1200 MHz, velocidad de datos)
Interfaz de memoria: 64-bits
Memoria total disponible para gráficos: 2806 MB
Memoria de vídeo dedicada: 1024 MB DDR3
Memoria de vídeo del sistema: 0 MB
Memoria compartida del sistema: 1782 MB
Versión de BIOS del vídeo: 70.08.29.00.01
IRQ: 16
Bus: PCI Express x16 Gen2(sorry is in spanish) jejeje….
-
Hello GiGurra!
Thank you for all of your awesome work with the GPT tools. I am replying because I am having a problem just getting the Display Extractor working. I installed everything on both the server and client computers, I start the DisplayReceiver, see the two white windows, and verify that the application is listening to port 8051 by running netstat from the command line. On the game machine, I changed the IP address in the config file to the IP address the of the slave machine “192.168.1.70”. I run the displaytransmitter.exe which then starts BMS and when I enter a flying session. I do not get any MFD display readings on the slave machine. I checked the status of the process via netstat and I see that the slave machine is still listening and has not established a connection. I already disabled Windows firewall from both computers and since they are running on my local lan, I do not think I need to enable port forwarding on the router that is connected to the lan (I will try enabling it just in case).Is there anything else I can do? I can enable port forwarding for port 8051, but I don’t know what else I can do. Help!