Eh, you can't entirely call it support, but updates breaking it aside, it was shown to be possible via a mod Colin made.
???? dude all cola colin did was give the windows the right dimensions and remove the border in windowed mode. the multiple pips came from another mod. that is not comparable to real multi-screen support. it wasn't reliable in a number of ways. nothing showed up correctly. and it was un-runable if you're talking performance. No. we NEED a professional take on this. mods won't cut it this time.
Didn't say it would. Just said someone did it so it's possible to be done in the game. Hopefully it is done, I fear later rather than sooner but one can hope not. It looks like it can be done eventually though.
Performance wise nothing would change in an implementation from Uber. Running multiple screens does kill performance. That's the nature of rendering multiple big views of the game. Also my mod was all about setting up pips in the matching size and making the UI work as it should. It didn't make PA have multiple windows, but tbh I don't think that is even necessary as long as you have multiple screens of the same size. Also it did work in the end before the UI stuff broke. It can still work even know if you hack it yourself in. Uber did fix the bugs with the icons it had afaik. Basically anybody could mod in a pretty well working multiscreen support at this point.
no. I'm quite certain clever ways that we can't think of yet can be be thought up by the uber team to optimize this. Is every drawn vector lost once it's drawn and useless to the second view? not necessarily, there may be parts that can be stored in memory and reused through an algorithm for the second view. Once again this is my inferior knowledge talking. Perhaps it is indeed impossible. or perhaps Uber can indeed think of a way.
Multiple monitor support was promised back in the day, including multiple PiPs. Haven't heard anything on it in a while...
Is it possible to steal the Alerts one and move it around yourself manually/keep it open permanently?
What did actually kill the performance when spanning the PiP fully over the second screen? In theory, it should only have doubled the load on the GPU, actually even slightly less than that. If your GPU has been below 50% load respectively your FPS around 50-60ish or more, then it should have been possible quite easily. Well, yes, possibly doubling the number of OpenGL API calls due to streaming two instead of one viewports could have caused some issues. But then again it should have had the very same impact even when the PiP was minimized. So it's really just a matter of trowing a faster GPU at the problem, either that or hoping that Uber manages to get the GPU utilization closer to 100% load. Latter one is actually going to be relevant in the context of another question: Will PA ever be ported from OpenGL to Vulkan? Given the rather low GPU utilization currently, that could easily yield twice the FPS on the very same graphics hardware. The baseline requirements chosen for the hardware were rather high either way, so, except for some Mac users (due to poor driver support on that platform, thanks Apple), not many users should get excluded by that move. Especially given that it's now another 3 years since the decision in favor of OpenGL was made, and back then nobody could have guessed that there would be a new graphics API which finally allows the type of direct and properly multithreaded access modern GPUs are built for.
As a normal user not. With code yes. The game only ever updates unit positions of units you can see. So if you add another view of another planet you not only add GPU load, you also add network load and cpu load for the additional handling of updating the unit infos. Last time I tried the performance wasn't a disaster though, it does drop and it does add some load, but it can work out for sure if you have a powerful computer and good internet.
A right, totally forgot that the netcode isn't exactly cheap or well compressed either. But then again, the load on the netcode exists regardless of what size the PiP has, since the LoD in the PiP completely disregards the size of the PiP window and only regards the zoom factor. So if you have a total of 3 Holodecks, that's a fixed amount of load on the CPU and network side. Scaling it only affects the GPU load, at least it should, unless there is some post processing performed on the CPU. Now what it probably suffers from, is that all 3 Holodecks must be rendered sequentially, when using the classic OpenGL API. So having 2 full sized Holodecks actually means twice the render time - while the GPU is never fully utilized. And that means reaching only about half the FPS. Or in other terms: It's actually neither GPU nor CPU bound, but instead limited by control flow of the current graphics API generation, which was never really built for massive parallel co processors (such as modern GPUs). I mean, all graphics hardware produced in the last 2-3 years is actually capable of executing multiple shaders in parallel. And I mean it like I say it, not thousands of instances of the same shader in lockstep, but actually a few dozen different shaders, and for each of these shaders then once again several thousand instances. It's just that the current APIs (neither DX11 nor OpenGL, but DX12 and Vulkan do) don't allow you to issue execution another shader before the first has finished. And then there are oversights, such as the API only allowing you to prepare one command buffer after another because the command buffer is assembeld inside the driver and it knows only one instance. All of them are tiny oversights, which prevent you from streamlining the process and utilizing the massive parallelism both your CPU and GPU are actually capable of, and where both CPU and GPU are capable of increasing their respective utilization by ensuring that there are always sufficient tasks in any of the pipelines to avoid idle times at all cost. Currently, PA reaches only about 70-90% GPU utilization - but even that's not actually the utilization in terms of "the GPU is running at full capacity", but only in terms of "the GPU has at least something to do". It doesn't tell you, that of all these components your GPU consists of, only a fraction is actually being active, due to all other components waiting for something to do, as they have not been provided with any meaningful tasks to perform while idle. So while the GPU is fetching something from memory, shaders halt since their pipeline runs dry. While it is copying data via PCIe, anything else is idle. Inside the shaders, computational power is wasted because only an odd number of shader instances could fit into the register set, and there were no smaller programs available which could have fitted in the gaps. There's a good reason why modern Nvidia GPUs appear to be so oddly power efficient: They are just much better at turning of components which are idle due to the driver being unable to provide enough work to keep ALL shader units busy. Avoid that trap, and even these modern Nvidia GPUs turn into red glowing monsters with screaming fans, quite easily reaching or even surpassing their specified TDP. But there isn't even much Uber could do - for know. As long as the Vulkan API isn't released, they are stuck with OpenGL, and all the related issues, caused by that purely sequential control flow of the OpenGL API. TL;DR: The performance problems can actually be leveraged, so that multi monitor support could be provided with acceptable framerates, even on todays hardware. It only requires to switch to a modern graphics API once it is available.
