[REQUEST] Screen exports to other computer

[METEOP]

We already have DCS exporting instruments on the network. There is still no solution to exports screens the same way!

 

After many years of experimentation with glass cockpits (Helios, Ikarus and others) I am disapointed with the performance impact such setups have on DCS, running everything on the same computer.

 

It is not only a problem of raw computing power, or rendering power, it is also an issue of timing and fluidity. These complimentary softwares, glass cockpit, voice attack, headtracker, bassshakers etc interfere with the stellar performance of DCS itself. A rough 'Seat of the pants' estimate would be that I am losing at least 10% performance.

 

If we could have MFDs and other screen natively exporting to a client computer, we could offload all the cockpit functions to it. I believe that it would be very beneficial to pilots who build pits such as ourselves.

 

I have seen professionnal simulators where multiple computers are running separate parts of the simulation in a network topology, I hope it is the future of DCS to implement such a model.

 

So please devs, I am begging you on my knees to implement this feature. :worthy:

[matbog]

Amen!

 

And if the client could run on a Raspberry Pi it would be Heaven!!!

 

:thumbup:

Edited April 10, 2019 by matbog

[Guppy]

It is not only a problem of raw computing power, or rendering power, it is also an issue of timing and fluidity. These complimentary softwares, glass cockpit, voice attack, headtracker, bassshakers etc interfere with the stellar performance of DCS itself. A rough 'Seat of the pants' estimate would be that I am losing at least 10% performance.

 

There is a workaround I have figured out to this that makes timing almost seamless on the same PC:

1) Open Task Manager

2) Go to Details Tab

3) Right click DCS.exe (after its already launched) and set Priority (processing priority) to Realtime

4) Do the same for IKARUS

(Note: you'll have to do this every time you launch the game/IKARUS)

 

This will give both those applications the highest priority. This should help you. I run a very elaborate setup (check my signature) and my response time between exported instruments, touchscreen UFC and such have nearly no delay. FPS is also significantly better in DCS even in window mode for those MFDs.

[METEOP]

There is a workaround I have figured out to this that makes timing almost seamless on the same PC:

1) Open Task Manager

2) Go to Details Tab

3) Right click DCS.exe (after its already launched) and set Priority (processing priority) to Realtime

4) Do the same for IKARUS

(Note: you'll have to do this every time you launch the game/IKARUS)

 

This will give both those applications the highest priority. This should help you. I run a very elaborate setup (check my signature) and my response time between exported instruments, touchscreen UFC and such have nearly no delay. FPS is also significantly better in DCS even in window mode for those MFDs.

 

Yep tried this, you may want to look into Process Lasso for a better process control. Realtime is not good because it will bring down the whole computer in case of problems. Also it does not offload the processing on another computer which is the whole point.

[Guppy]

Yep tried this, you may want to look into Process Lasso for a better process control. Realtime is not good because it will bring down the whole computer in case of problems. Also it does not offload the processing on another computer which is the whole point.

 

I guess with my beastly system it's not an issue. 2080ti, 32gb ram, 8700@5.3ghz all liquid cooled. But I could see not as strong PCs encountering issues regardless of priority. Currently, this has made it perfect for me 50-60fps even on the most demanding of MP servers.

[bnepethomas]

Screen export across a network would be a beautiful thing - and, as noted about, being able to send it to a Pi would even be better :) Please - pretty please :)

[Ranma13]

I guess with my beastly system it's not an issue. 2080ti, 32gb ram, 8700@5.3ghz all liquid cooled. But I could see not as strong PCs encountering issues regardless of priority. Currently, this has made it perfect for me 50-60fps even on the most demanding of MP servers.

 

Humble brag aside, changing your process affinity to real-time will only have minimal impact:

 

https://superuser.com/a/752864

 

Summary: you largely won't see any effect of changing thread priorities unless your CPU is heavily loaded, and even then the effect will typically be minimal. If the process has to wait for I/O or it's not contending with other processes for CPU time, it is already running the fastest it can and changing priority isn't going to make it any faster.

 

Ikarus has very low system usage because all it's doing is reading the exported UDP messages, then updating its UI. The MFDs are rendered as part of the main game's render area, and should be updating at the same rate as the main game. There shouldn't be "nearly no delay", there should be no delay at all.

 

There are good reasons for wanting to export the viewports to something that's not tied to the main render area. If your main display is a G-Sync display with a high refresh rate but your secondary monitors are only standard 60 Hz monitors, it will lock your G-Sync monitor to 60 Hz. Perhaps you want to display a MFD on only part of a secondary monitor while leaving the rest uncovered so that you can, for example, look at Discord chat in-game. Maybe you want to be able to use a tablet to export the MFDs onto, of which the current "solutions" are essentially just screen sharing apps with a skin. Some people may want to export the data to a computer running a non-Windows OS for esoteric purposes, such as exporting the Ka-50 Shkval to a Linux box, applying some filters to it, and displaying it on a CRT monitor. The current "just make the render size larger and draw the MFDs at a certain position on it" is not really a good solution and really limits what can be done with it.

 

You're perhaps unaware, but at one time DCS either had, or planned to support exporting render targets to shared memory, which is exactly what we need. This comment can be found in Scripts\Export.lua:

 

-- you can export render targets via shared memory interface

-- using next functions

-- LoSetSharedTexture(name) -- register texture with name "name" to export

-- LoRemoveSharedTexture(name) -- copy texture with name "name" to named shared memory area "name"

-- LoUpdateSharedTexture(name) -- unregister texture

-- texture exported like Windows BMP file

-- --------------------------------

-- |BITMAPFILEHEADER |

-- |BITMAPINFOHEADER |

-- |bits |

-- --------------------------------

-- sample textures : "mfd0" - full SHKVAL screen

-- "mfd1" - ABRIS map screen

-- "mfd2" - not used

-- "mfd3" - not used

-- "mirrors" - mirrors

Edited April 16, 2019 by Ranma13

[Guppy]

Humble brag aside, changing your process affinity to real-time will only have minimal impact:

 

https://superuser.com/a/752864

 

Fortunately this is false for me. The performance difference between DCS running in Window Mode and IKARUS responsiveness is night and day. I've gained an extra 10 fps every time I set DCS' Affinity level. Additionally, the responsiveness of buttons/switches I have on my UFC are immediate when I change IKARUS' Affinity level. (more on this below)

 

I know other users who have seen similar gains, too.

 

 

Ikarus has very low system usage because all it's doing is reading the exported UDP messages, then updating its UI. The MFDs are rendered as part of the main game's render area, and should be updating at the same rate as the main game. There shouldn't be "nearly no delay", there should be no delay at all.

 

I'm talking about the UI. The messages are sent immediately to the game the moment a button (read: touchscreen) is pushed. However, there is a image on/off process that occurs within IKARUS when a single button has been pushed - the actual UI in Ikarus. Setting the affinity level to the highest, solved the delay.

 

There are good reasons for wanting to export the viewports to something that's not tied to the main render area.

 

To be clear, I'm not arguing the good reasons. I'm just providing other ways of working around this stuff that has worked for me, while we perpetually wait for an update. I Do not disagree with the need/want...but having stumbled on this and experiencing these issues myself, it seemed like a great time to offer some workarounds, too. The suggestions are upgrading your PC and setting Affinity level. Admittedly though, your mileage may vary.

 

You're perhaps unaware, but at one time DCS either had, or planned to support exporting render targets to shared memory, which is exactly what we need. This comment can be found in Scripts\Export.lua:

 

I am aware and my assumption is that VR is prioritized in front of simpit builders, unfortunately.

Edited April 17, 2019 by Guppy

[Ozone42]

You're perhaps unaware, but at one time DCS either had, or planned to support exporting render targets to shared memory, which is exactly what we need. This comment can be found in Scripts\Export.lua:

So the SharedTexture() functions do not work? If not, it would be nice if ED removed those functions from the Exports.lua documentation so that developers don't spend time trying to get them to work, like I just did.

 

Does anybody know for sure, does the shared memory work or not?

[RightStuff]

Oh? Flight Data/ Textures possibly in Shared Memory?

Have heard about it anywhere else... But I forgot where. ;)

[Ozone42]

And if the client could run on a Raspberry Pi it would be Heaven!!!

 

You can use https://github.com/BlueFinBima/Iris-Screen-Exporter together with https://github.com/bjanders/wxpython-iris-client to get parts of the screen exported to a Raspberry Pi. I just made the simple client and verified that it works on a Pi.

 

Oh? Flight Data/ Textures possibly in Shared Memory?

Have heard about it anywhere else... But I forgot where.

 

Your reply is not constructive and only adds noise to the discussion. You are clearly hinting at something without giving any useful information. I'd appreciate if you can be helpful if you can.

Edited February 24, 2020 by Ozone42

[matbog]

You can use https://github.com/BlueFinBima/Iris-Screen-Exporter together with https://github.com/bjanders/wxpython-iris-client to get parts of the screen exported to a Raspberry Pi. I just made the simple client and verified that it works on a Pi.

 

Wow, that is great!!! I was not aware that you did a RasPi compatible client for Iris. I will try!

[RightStuff]

You are clearly hinting at something without giving any useful information. I'd appreciate if you can be helpful if you can.

 

For obvious reasons I cannot go into details here.

 

My comment should be seen as a headsup to take look around the (SIM-)corner, where this technique is used, it has an well documented header file and afaik there are coming some programming examples with it as well.

 

If you or anybody else is lost while searching these data, pls drop me a PN and I'll glady give a helping hand.

[Ozone42]

Wow, that is great!!! I was not aware that you did a RasPi compatible client for Iris. I will try!

You couldn't have been aware, since I had made it the same or the previous day :).

 

Another way is to use VLC, then you can stream to any device that supports VLC (tablets, Raspberry, or even an Apple Watch). To start streaming from the computer you play DCS and have the DDIs (or whatever you are streaming), run something like:

.\vlc.exe screen:// --screen-fps=20 --sout  '#transcode{vfilter=croppadd{cropleft=0,cropright=1320,croptop=0,cropbottom=600},vcodec=mjpg}:standard{access=http,mux=mpjpeg,dst=192.168.0.1:8080}'

Where 192.168.0.1 is the address of your DCS computer. Use the crop* to get the portion of the screen you want to stream. Then just connect your client to http://192.168.0.1:8080.

 

The video encoding and method in the example here is not ideal for this purpose, and is just an example. Better parameters needs to be determined.

Edited February 25, 2020 by Ozone42

[matbog]

Thanks for the tips!

[MONK Marco]

Has anything changed on the topic of Exporting Cockpit Instruments or MFD / DDI's to a second PC via NETWORK and render / display it there? Everything I tried was impacting perfromance.

[Ozone42]

I’m interested in this topic once again. I want to export the screens to a second computer. I tried Immersive LCD PRO, which was good for my triple display setup. Unfortunately I cannot use it, as it also warps the MFDs I have on external screens, in addition to the external views. To make it work, I’d apparently have to export the MFDs to a second computer (where I don’t run LCD PRO). What options do I have?

I don’t get RightStuff’s cryptic response and “obvious reasons”, unless it’s something against the EULA. I’m not interested in a solution that is against the EULA or violating any copyright.