multiple monitor support

#1 You can run muliple instances of the engine, and use each instance as a different type. Of course, more likely than not, you'd want this as a local network game. I'm working on setting up some dummy network stuff, as there isn't anything set up for the MIT version yet for it.
But it should be relatively simple if you want to set up your "server" screen as the updater and each "client" as a monitor.

#2 so right now with torque2d this is a no? Dang!

#3 Are you wanting it to be 3 different windows that can be moved around or just 1 large window running in fullscreen across 3 monitors? Neither is possible currently without source code changes, the latter would require fewer changes, on Windows at least.

You just need to make changes to the window creation code to enumerate the monitors, determine the left most monitor, create a borderless window, set the window's position to be the top left corner of that monitor and then set it's width and height to be the x and y extents of the right most monitor. That was the approach I used in T3D recently for a service contract (sorry I'm unable to share the code from that particular one).

#4 @Scott - Ok, but even if you can't share code you could point us to the right spots... ;p

Hey, do you think it would be easier to adapt the current rendering code to create a Linux render module or to build some sort of wrapper for SDL? (aside from opinions about SDL - there are many, I know).

#5 I want 3 different screens doing their own thing, if it is full screen or not I don't care. 2 screens rendering the players hands and the main screen managing the game information.

#6 @Eric - This seems a bit confusing to me. You are talking about one computer system controlling three separate monitors, correct? If so, aside from turning the physical monitors so that opposing players can not see each other's "hands", how would you manage the control of the game?

Would the two players pass the mouse/keyboard back and forth?

- Brian

#7 Also, if you simply want to have the entire T2D sceneWindow stretch across all three monitors (this is, of course, assuming that, and dependent upon, all three monitors are set at the same resolution [a BIG variable that sways any potential solution]), you can modify the defaultResolution and windowedRes preference variables to accommodate your whole usable desktop space.

Go to (assuming you have followed the Getting Started Guide and started a clean project) the file at yourProject\modules\AppCore\1\scripts\defaultPreferences.cs and modify $pref::Video::defaultResolution = "[COMBINED_WIDTH_OF_ALL_THREE_MONITORS HEIGHT_OF_MONITORS"; and modify accordingly. Also do the same for $pref::Video::windowedRes.

This should get you what you want (assuming MS Windows usage AND assuming you currently have your desktop stretched across all three monitors) and then just leaves you to work your layout/camera size/etc. to emulate the three separate spaces.

See if that works for your needs (understanding that this would only work on your system).


- Brian

#8 I think a local network game would be more idealistic to what has been described here. The hand screens would be your clients, and the actions would be your server. Depicting what is shown to happen on each would be the "key" here. It really would not be difficult at all to set up.
I should finish a simple network example by the weekend, but I believe that would be the way to go. Just for notation, T2D is an event-based network system, which means it is "ideal" for Turn-Based games, but not "limited" to them.

#9 so, here is what I want to do. I want to make a local only card game, but each person cannot see each others hands. So I have 3 monitors, 2 monitors that only need to render the hands of each player nothing else. I think this would make it easier to program. The main monitor will handle everything about the game and just update the players hands on their own monitor when each turn in over.

I hope that makes more sense.

#10 @Doc308

I would love to see your examples, I would be very appreciative! :)

#11 @Eric - Again, you have not addressed how the game will actually be played by two players on one system. I understand you have three monitors and that you want each monitor to display something different (#1 - Player1, #2 - Server, #3 - Player2). However, this is all being controlled by one system.

@Doc - A network layer would be nice for T2D MIT. However, I don't see what benefit that would bring to what Eric wants to accomplish. A LAN-party solution that runs on a single machine seems counterintuitive to me. You'd have three separate instances running (one server and two clients) chewing up resources on a single machine.

Also, it still begs the question that I asked earlier: How the control of the game will be managed using a single system.

#12 @Brian, I've done several tests using the Legacy TGB for Network, and it's all set up the same, instead of going through an open network, you are on your own LAN. The speed would probably be "better" than on a web network.

I believe this suits exactly what Eric wants, because each "player" has their own instance of the engine running, and connects to the server. In his instance, it's all local, but that's a trivial matter. It makes it easier for testing.

The server is always the controller, and each client communicates and receives communication from the server.

Now, yes a high demanding app might chew up resources on a single machine, but for what is being described here.. it's going to be very minimal.

#13 @ Doc - I completely understand the network layer logic--that makes complete sense. If Eric were running three separate systems on his own LAN, what you offer is, without a doubt, the logical solution. What I don't get is the reasoning for sending out network packets that simply get routed back to another process on the source system.

More importantly, I've noticed a considerable decrease in performance when a T2D window loses focus. I know we're talking about a simple card game here but I'm just being a forward thinker.

Thoughts?

#14 I can't say for certain what Eric's specific reasons may be, but to me it seemed a more logical maneuver. Maybe because my thought process went along the lines of, get a local test bed game working, then move on to a local LAN group, and then expand to internet testing. All of the processes utilize the same structure. The last one, of course, would require a server host preferably, rather than a local server host. But it could work either way.

Setting up the game environment without it is feasible, but it would require more thought effort in setup and layout. Whereas, the local network option allows you to create just one setup for the client side, and one for the server. It may seem "odd" for the communication to be routing through the single entity, but it would in my mind, be far less workload.

I'm not sure about the performance issue with focus loss, but with full screen setups, that shouldn't be an issue here.

#15

Quote:Maybe because my thought process went along the lines of, get a local test bed game working, then move on to a local LAN group, and then expand to internet testing.

Now that makes perfect sense. I never came to that line of reasoning as I was just going off of Eric's statement that he had one system with three monitors and wanted T2D to cover all three. For argument's sake, I'll side with you that this can make a logical progression feasible.

Of course, Eric chiming in again could clear that all right up.

Quote:I'm not sure about the performance issue with focus loss, but with full screen setups, that shouldn't be an issue here.

Well, with that, we'd be back at Scott's response. To create three separate full-screen instances would require a significant hack to the engine core as you would need handles to have each process run on its own monitor. I know it can be done as I use InnerSpace to accomplish this very thing when multi-boxing. However, it is dependent on DirectX.

#16 You got it, I wanted to test it locally with just one of my friends because I could not think of another way without knowing network code, since I am going to be learning from scratch and I am no means a professional programmer (maybe one day :) )

I could just test everything on my setup I currently have.

#17 I'm pretty sure that the performance decrease with focus loss is simply the application shifting into "background" priority - why does your game need to run at 1200 fps if you're browsing the web instead of playing the game?

SDL now supports multi-monitor configurations, so I think this is doable in OpenGL as well as DirectX - just have to modify the window and canvas handling code... a lot.

Personally, I'm a bigger fan of the networked option regardless of multi-monitor support (love that idea, too) - then we can play cards from the same room, the same state or anywhere on Earth....

#18 I think T3D purposely went into low priority mode so this should be able to be disabled. I know an app can use all processors to full extent if it wants to. Focus change only reduces cycles if the app is willing to run with fewer cycles. I have run stress test programs that peg to a flatline 100% all processors even if it is minimized on Windows 7.

#19 You can control the background sleep time (in ms) with the following variable:

$Pref::backgroundSleepTime

You can even control the foreground processing interval but I wouldn't recommend that, using:

$Pref::timeManagerProcessInterval

These are the defaults:

S32 sgBackgroundProcessSleepTime = 200;
S32 sgTimeManagerProcessInterval = 0;

... which can be found here in 'platform.cc'.

#20 @Richard - That would be neat if multi-monitor full screens could be accomplished with OpenGL.

Quote:...why does your game need to run at 1200 fps if you're browsing the web instead of playing the game?

The point is moot now but it was a question of there being three instances of an app running concurrently. As only one of three could have focus at any given moment, the other two instances would have suffered from a performance loss. However, as has been verified by the OP, this is only a stepping stone for development purposes in emulating a networked app.

@Demolishun - Thanks for your feedback.

@Melv - Though I don't see any reason for my purposes to utilize those prefs, it is nice to know we do have access to them.