Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Pyrorex]

Well, I run two monitors, and it is fucking win. Unfortunately, very few games support using both screens (To my utter confusion). One such game is Supreme Commander, which I own love and play often. You have your control screen on the left and your overview and status map on the right. It's intensely useful and utterly awesome. I think DF would be pretty fucking rad if it supported both screens. Maybe  right screen would be where all the menus like the jobs menu and etc pulled up, you could put the controls list and map on that side too, with the left screen devoted entirely to the visual interface. Shit would be so cash.

[JustOnePixel]

Unfortunately, the reason why a lot of games don't do dual screens is that they're a pain to construct: to get any sort of fast implementation going, they require multithreading, and I'm pretty sure Toady has said that multithreading = no.  So while this would be neat, it probably won't come to fruition.

[Random832]

Unfortunately, the reason why a lot of games don't do dual screens is that they're a pain to construct: to get any sort of fast implementation going, they require multithreading, and I'm pretty sure Toady has said that multithreading = no.  So while this would be neat, it probably won't come to fruition.

GL Rendering is already multithreaded (well, single-threaded in a separate thread from the game itself) - there's just no multithreaded core game calculation - surely another graphics thread could be added to handle the second screen's window with little difficulty.

[Pyrorex]

Hell, I'd be happy with a second fucking exe.

[JustOnePixel]

GL Rendering is already multithreaded (well, single-threaded in a separate thread from the game itself) - there's just no multithreaded core game calculation - surely another graphics thread could be added to handle the second screen's window with little difficulty.

It's true that the architecture is there, but using a multithreaded architecture is hardly a trivial task.  The problem is that there's no simple "dump these operations in this thread and dump those ops in that one" set of functions (and you really wouldn't want there to be, since there's really no generic usage of multithreading).  I use Python multithreading every now and again, and even though it's a fully realized toolkit, it still takes forever to figure out how to use it; the approach changes with each app.  Add that to the fact that you'd essentially be splitting up old code and reorganizing it, and you've got yourself a pretty daunting task.

[JustOnePixel]

This reply is the product of pressing the "quote" button instead of the "modify" button.  Oops.

[Draco18s]

Unfortunately, the reason why a lot of games don't do dual screens is that they're a pain to construct: to get any sort of fast implementation going, they require multithreading, and I'm pretty sure Toady has said that multithreading = no.  So while this would be neat, it probably won't come to fruition.

If that were true, then SupCom would support multiple screens.

Why?  Because SupCom is already multithreaded (in fact, if you attempt to play online with a single core machine, you'll get kicked).

[Random832]

GL Rendering is already multithreaded (well, single-threaded in a separate thread from the game itself) - there's just no multithreaded core game calculation - surely another graphics thread could be added to handle the second screen's window with little difficulty.

It's true that the architecture is there, but using a multithreaded architecture is hardly a trivial task.

Again, DF uses a second thread for rendering. It could use a third thread, if needed, for rendering to the other monitor. I'm not sure what else would "need" multithreading to be able to have what's essentially just two windows.

[Footkerchief]

Can't you just adjust grid size to make the DF window really wide, and then split your desktop across the monitors?  Then you could position the window such that the view panel would be on the left screen, and the interface panel on the right.

[JustOnePixel]

Again, DF uses a second thread for rendering. It could use a third thread, if needed, for rendering to the other monitor. I'm not sure what else would "need" multithreading to be able to have what's essentially just two windows.

How do we decide what gets pushed to the two monitors?
How do we enable communication between the two threads such that they can coordinate resource usage efficiently and, more importantly, without deadlock, starvation, etc?
How do we construct listeners so that the two threads know what and when to update?
How do we get the main program to communicate with those listeners?

You're right in thinking that the actual creation of a new window is a fairly easy task (well, relative to multithreading, at least.)  But again, it's all about how we use it.  I haven't used GL threads so I could be wrong, but those tasks above run along the usual train of thought for just about any multithreaded application.  And each one of those is quite a chore.  OpenGL is very low level, too, so I'd be really surprised if there was some sort of fire-and-forget thread architecture.

Are you familiar with GL threads?  Do you happen to know if it's as simple as you've described?

[Warlord255]

I just made my window huge. It helps.

[Align]

If that were true, then SupCom would support multiple screens.

Why?  Because SupCom is already multithreaded (in fact, if you attempt to play online with a single core machine, you'll get kicked).

Maybe it's just because it's past midnight here that I'm missing the point, but didn't he already say that it supports multiple screens?

[Draco18s]

If that were true, then SupCom would support multiple screens.

Why?  Because SupCom is already multithreaded (in fact, if you attempt to play online with a single core machine, you'll get kicked).

Maybe it's just because it's past midnight here that I'm missing the point, but didn't he already say that it supports multiple screens?

No, I misinterpreted what he said.

[Random832]

I'm not at all convinced that two threads are even needed to have two windows (which is really all that dual screens are - two full-screen windows)

Point is, no-one but toady knows how the code works, so no-one but toady can say how easy or hard it would be to make a given change.

[LegoLord]

Can't you just adjust grid size to make the DF window really wide, and then split your desktop across the monitors?  Then you could position the window such that the view panel would be on the left screen, and the interface panel on the right.

Has anyone else even noticed this?  Honestly, it's a short-term suggestion that merits attention.  Will it work?