ideas for multiple windows

since PA will allow you to have multiple views of the battlefield in seperate windows.
I thought it would be nice if you could press a key and get all the windows equally arranged on your monitor and then select one for closer view while keeping the others on the screen in a smaller view.

http://i.imgur.com/YoOSQ.jpg

in this way you could change your view quickly to the place that needs attention, while using the maximum space of you monitor.

another idea would be that you can save certain arrangements of windows and switch them with hotkeys which I'd really love to have!

what do you guys think is needed to make the use of multiple views as easy as possible?

There are window managers for Linux that are exclusively tiling, meaning they lay out similarly to what you show in your diagrams. These would be a good to examine for hotkey and layout commands that may be useful in PA, as they are designed to be very fast and efficient.

Some examples include:
Awesome WM (somehow seems fitting)
Xmonad
dwm

Most of the features available in these wm's are far beyond the scope of PA, and the focus on keyboard control isn't really necessary, but they do provide a good reference for implementation.

thx for the replay, now i finally know what i was looking for XD
just downloaded winsplit because managing 2 monitors is kind of exhausting sometimes!

your probably right, if each windows of PA behaves like a normal windows window or linux windows you could use a tiling software!

I suspect the "windows" of PA will be implemented ingame, rather than as different windows on the system. If the latter were the case, it would be too specific to the system, whether it be Mac, Linux, or Windows. (As you'd need to use the windowing API specific to the platform.) It's much easier to define window widgets ingame, and your own method for managing them which is more cross-platform friendly.

My suggestion is only for how they might want to go about implementing their ingame widgets.

Actual I kind of want to do both. In game splits within a single viewport as well as allowing additional windows. We are looking at the engineering on this right now. It can be a bit tricky if we want to have shared GL contexts so there might be some perf implications.. we'll see how it works out.

thx for the reply neutrino.

This feature gonna make thinks so much easier,
and I think, I will need bigger monitors because I won't be able to fit enough AWESOME on 2 24".

I hope you have a fatty video card too then

I suppose I'll have to attach another monitor to this machine for testing this. Doing the dual screen dev during SupCom was a major pita.

for a good game, a new video card is nothing to shame... ^^

anyways I'm really excited about the multiple view solution, and orbital maneuvers

Wait you dev with a single monitor?? How do you get anything done?

Windows within windows? You've gone crazy mad with window lust! And I'm loving it!

With a big enough monitor, and a good enough text editor, it's generally not an issue.
(Also, multiple desktops/workspaces can be useful too.)

90% of the code I've written on PA so far has been on my Macbook pro which only has one screen.

At the office I have a 30" display which is plenty for coding/debugging. I also have a secondary 24" monitor that I use for a my xbox dev kit which I could easily hook up as a second monitor.

William who does a lot of the hardcore engine work runs dual displays, one 30" and one 24". His main display is hooked to a kvm switch that swtiched between his mac, his linux box and his windows box.

Our "standard" setup is dual 24" monitors. Quad core typically with 12GB, an SSD primar,y a terabyte secondary and a fairly run of the mill videocard to keep it real. The videocard in my main work machine is an Nvidia 9800 for example, which is ancient.

one question regarding video cards :

Regarding Nvidia CUDA / ATI stream, would it make sense to use these APIs with PA ? Have you planned to do so ?

obviously, I can't answer for them.
but my thoughts would be, that in a setting where your graphics card runs rel. heavy load client side, it doesn't makes sense to share the existing resource to offload cpu load. (with all the related memory transfers etc)
Server side, I think they mentioned somewhere, that they don't expect servers to have heavy cpu hardware to make gpu computation sensible.

as a side note, even with just one vendor optimal usage of a gpu for GPGPU tends to be a bit graphics card specific, which makes the use in the consumer environment, with a boatload of different variations, not that easy.

I haven't played a game supporting multiple monitors in a long time, so I'm probably not up-to-date on the performance of more or less current graphics cards in that setup.
It would be nice to know what the scaling factor for an additional viewport would be.

Assuming the two windows don't hold much shared data, which can be reused by either view, I would guess the load will probably double in the best case? In the worst case both rendering instances interfere with each other computation and memory transfer wise and the performance goes down the drain.

Are there any good opengl benchmarks out there to test the behaviour of your card in a dual window/monitor setup? Just running two instances of windowed benchmark seems a bit rough, even if it works in principle. I just hope the game is not as demanding as a benchmark .

I can play Supreme Commander FA and 2 in dual monitor mode with my gtx 560.
both monitors have a resolution of 1920x1080.

I think I read somewhere that when using two monitors you graphics card splits its computing power in half for both of them.
but I have always activated my second monitor and have no problems playing any games in highest settings on my primary.

No current plans to use either one.

Also as has been pointed out we are not assuming that the servers even have a GPU at all so things on the server side that might take advantage of this don't really make sense.

Ok, assuming servers not have gpus, unless i missed something, the client is also likely to have intensive workload, no ? Now of course if client side code is not massively multithreaded then it neither does make sense to use cuda. I guess client code will of course be multithreaded, but, and these is another question :

In which degree of magnitude such RTS client code can be efficiently multithreaded ? (scaling out on many cores instead of scaling up thanks to a higher frequency). I guess this is something you have to decide from the very beginning : taking advantage of a cpu frequency which will increase over years, or taking advantage of the number of cores which is also likely to increase over years (or both ?). This is related to what i think you state that you expected PA to be as scalable as TA is (larger armies).

When supcom went out i got one of the first quad core available on the market and there was not such a massive improvement compared to dual cores. Even dual core with higher frequency used to make supcom running faster than on my Quad core.

I know perfect scalability does not exist unless all tasks are independant from each other, but i don't have any idea about multithreading efficiency in games and especially in RTS when one could think the more unit you have the more threads you can have.

possibly there's no easy answer to this :?

As neutrino already said that it would be (probably) possible to make separate windows (which shouldn't much a problem), than you just let your WM do all the job for you. Problem solved. Actually, i believe that developing tiling WM into PA would be counter-productive, cause it's really hard to make WM good for everyone.

The clients workload is going to be quite small compared to the server. It will still be multi-threaded but not as much because it's mainly rendering and dealing with the UI. Since no simulation happens locally it's almost all going to be rendering load. In addition I'm working very hard to move as much rendering work to the GPU as possible.

The server code is where the heavy multithreading work is going to happen. The work is broken down across domains which can be run in parallel. For example units on different planets are completely separate so the first obvious thing is to run each planet on a thread. But we can go a lot further than that.

SupCom only really took advantage of 2 threads. One for the sim, one for the rendering. In PA the sim lives inside the server and so the client has a lot less to do. The goal here being that you don't get slowdowns based on how slow other players machines are.

No easy answer. It's an area of active research for us, mostly on the sim side. I've described our replication strategy elsewhere and there are several kinds of sim designs that could work with it.

Soon there gonna be 4-windows support and I still only have working CRT, with 1152x864 resolution :roll: for like 10 years. Why would I change stuff if it works? But specs of PC are enough to run all games with everything maxed out