Multiple screen use?
by GarageGamer · in General Discussion · 04/19/2004 (5:54 am) · 29 replies
OK, so I wasn't sure where to post this. Hopefully someone here can help...
We are building a game which will be a permanent installation at the local science center, which visitors can interact and play with. Ultimately, we would like to keep our mission running on the main domed screen, and have a seperate touch screen to be used as a GUI.
So my questions are these...
1)How can I incorporate Torque on both screens and have them communicate effectively?
and
2)Is there something in Torque to utilize the touch screen, or does that need to be developed in C++?
Thanks for any help you can give.
We are building a game which will be a permanent installation at the local science center, which visitors can interact and play with. Ultimately, we would like to keep our mission running on the main domed screen, and have a seperate touch screen to be used as a GUI.
So my questions are these...
1)How can I incorporate Torque on both screens and have them communicate effectively?
and
2)Is there something in Torque to utilize the touch screen, or does that need to be developed in C++?
Thanks for any help you can give.
About the author
#22
For interface work with touch-screens, there are a few good books that have sections covering this type of design. Main suggestions are: Make your buttons big, large enough to touch with two fat fingers. Make all controls spaced far apart from other controls. Avoid "slider" controls. Avoid "double-click" controls. Avoid "hold and wait" (like on an up/down arrow on a spin control) controls. Avoid keyboard entry.
04/22/2004 (1:38 pm)
@GarageGamer: Certainly sounds like it. The touch screens being used on this project are basically mouse replacements that return absolute mouse coordinates. Just a simple drop-in replacement for the regular mouse (which it co-habits with quite happily for development work). The touch screen attaches to the front of a standard LCD panel with the bezel removed. I can get the brand details for the touch-screens if you want.For interface work with touch-screens, there are a few good books that have sections covering this type of design. Main suggestions are: Make your buttons big, large enough to touch with two fat fingers. Make all controls spaced far apart from other controls. Avoid "slider" controls. Avoid "double-click" controls. Avoid "hold and wait" (like on an up/down arrow on a spin control) controls. Avoid keyboard entry.
#23
04/22/2004 (1:46 pm)
@Jason Leigh: I think this is very do-able with Torque. Though your students may be rather disappointed to find that 99% of what they will want to do is mostly taken care of by a few lines of Torque script rather than any hardcore C++. That's not to say you couldn't do it in C++, just... what's the point? A script is worth 1,000 lines of C++. The C++ programming would be in the form of modifying the Torque engine to support dual monitor output.
#24
I'm going to back-pedal a bit on saying that TGE could not support multiple monitors "out-of-the-box".
It would be possible to create a very large display window that stretches across two monitors, as long as the physical orientation of the monitors is known, and then create two cameras that are slightly offset by the distance between both eyes of the viewer. The output from each camera would be placed at a specific screen location within the display window.
Now this is only really feasible on a graphics card whose driver is fully OpenGL compatible so that full acceleration is achieved on both screens.
What this "dual camera" setup will do to the framerate of your game I cannot say, I do remember that on Tribes that it could slow the frame rate to a crawl if there were a lot of players in the game, but that was on older graphics cards (TNT2). A decent high-end NV or ATI should not have any problems handling it.
So requisites are:
Dual head display
Fully OpenGL compatible graphics driver
Physical orientation of monitor setup is known
Torque having no upper limit on window size being created
04/22/2004 (1:55 pm)
Having thought about this problem some more, and having created some sniper scripts for the original Tribes that provided "picture-in-picture" support so that you could keep an eye on yourself from a 3rd person perspective when zoomed in on a target (those rascally players would sneak up on you and drop a mine and grenade at your feet while you were zoomed in on a target).I'm going to back-pedal a bit on saying that TGE could not support multiple monitors "out-of-the-box".
It would be possible to create a very large display window that stretches across two monitors, as long as the physical orientation of the monitors is known, and then create two cameras that are slightly offset by the distance between both eyes of the viewer. The output from each camera would be placed at a specific screen location within the display window.
Now this is only really feasible on a graphics card whose driver is fully OpenGL compatible so that full acceleration is achieved on both screens.
What this "dual camera" setup will do to the framerate of your game I cannot say, I do remember that on Tribes that it could slow the frame rate to a crawl if there were a lot of players in the game, but that was on older graphics cards (TNT2). A decent high-end NV or ATI should not have any problems handling it.
So requisites are:
Dual head display
Fully OpenGL compatible graphics driver
Physical orientation of monitor setup is known
Torque having no upper limit on window size being created
#25
We already have the touch screen, and I've been able to run windows on it, stretching the desktop across two screens, and everything there is fine. The question remains whether to try to incorporate the GUI onto this one screen as you suggested with the picture-in-picture idea or networking two machines.
First of all, if we point the second camera to an area of our world that never changes, and cover it with a GUI, how will it effect frame rate?
Secondly, how flexible are the torque windows? We have two screens with major dimension and configuration differences... one a small rectangular touch screen, the other a large projectile dome.
I think if a GUI is to be used, a second computer is the way to go... so the question becomes this:
can we script a solution for running the GUI on one computer, and the mission on another?
The other approach we were considering was using a web page to display the player status (in this case, mostly a series of photos in a book) set up on a webpage. I believe the work to send a file to the webpage is already complete. My question in this direction would be could we put buttons on this webpage to act as a GUI, and send messages back to TGE to activate different tools? Otherwise, we'd be keeping the GUI within the mission and controlled by the joystick. I would like to see the touch screen implemented more in the GUI-end.
So, Orakunozoku, what is your approach? are you using multiple computers?
04/22/2004 (6:37 pm)
Orakunozoku (et al):We already have the touch screen, and I've been able to run windows on it, stretching the desktop across two screens, and everything there is fine. The question remains whether to try to incorporate the GUI onto this one screen as you suggested with the picture-in-picture idea or networking two machines.
First of all, if we point the second camera to an area of our world that never changes, and cover it with a GUI, how will it effect frame rate?
Secondly, how flexible are the torque windows? We have two screens with major dimension and configuration differences... one a small rectangular touch screen, the other a large projectile dome.
I think if a GUI is to be used, a second computer is the way to go... so the question becomes this:
can we script a solution for running the GUI on one computer, and the mission on another?
The other approach we were considering was using a web page to display the player status (in this case, mostly a series of photos in a book) set up on a webpage. I believe the work to send a file to the webpage is already complete. My question in this direction would be could we put buttons on this webpage to act as a GUI, and send messages back to TGE to activate different tools? Otherwise, we'd be keeping the GUI within the mission and controlled by the joystick. I would like to see the touch screen implemented more in the GUI-end.
So, Orakunozoku, what is your approach? are you using multiple computers?
#26
No need for another machine, no need to worry about stretching windows, different screen resolutions, or speed issues. Windows GUI controls are more of a pain to program than Torque's, but this solution is far more elegant than using 2 computers.
04/23/2004 (12:28 pm)
Since you are talking about stretching windows across muliple monitors, I assume it doesn't have to be in fullscreen mode? If this is the case, the easiest thing to do would probably be to run the TGE on the fast head output and on the other monitor simply create and use standard Windows GUI controls. No need for another machine, no need to worry about stretching windows, different screen resolutions, or speed issues. Windows GUI controls are more of a pain to program than Torque's, but this solution is far more elegant than using 2 computers.
#27
I think what you are doing with the picture-in-picture concept is exactly what I am looking for. We are fortunate in that all the folks who own Geowalls are required to use the same graphics cards- Quadro4 or QuadroFXs.
Do you have a short snippet of code in Torque to create 2 cameras and 2 viewpoints on 1 window?
I have done this in DB and Blitz3D, and if you believe this is possible in Torque I will definitely buy a copy rightaway! My students would greatly appreciate being able to at least code in a C/C++-like script rather than Basic.
Thanks!
04/24/2004 (8:28 am)
Orakunozoku:I think what you are doing with the picture-in-picture concept is exactly what I am looking for. We are fortunate in that all the folks who own Geowalls are required to use the same graphics cards- Quadro4 or QuadroFXs.
Do you have a short snippet of code in Torque to create 2 cameras and 2 viewpoints on 1 window?
I have done this in DB and Blitz3D, and if you believe this is possible in Torque I will definitely buy a copy rightaway! My students would greatly appreciate being able to at least code in a C/C++-like script rather than Basic.
Thanks!
#28
04/24/2004 (9:43 am)
You'd just get Torque running across the whole video wall, then use the gui editor to set up two GUITSControls. Might have to hack a bit to get it looking through two seperate camers but it wouldn't be impossible, depending on what you wanted.
#29
I did get this to work... as I mentioned earlier, I streched the desktop across two monitors using a horizontal span option offered with my Nvidia video card. I then had to reset the game resolution to (In this case) 1600 x 600, or 800 x 600 on each screen. Then I just organized the PlayGui.gui so it would fill both screens, with the touchscreen buttons on the touchscreen(obviously) and the mission display(TSCtrl) on the main screen. It's working great.
@Jason - this is probably exactly what you're looking for, and before I updated the touchscreen, I had a set up with multiple camera views. So what you want should be very doable. If you're interested in the changes, email me at klamers@earthlink.net
06/10/2004 (12:36 pm)
FYI-I did get this to work... as I mentioned earlier, I streched the desktop across two monitors using a horizontal span option offered with my Nvidia video card. I then had to reset the game resolution to (In this case) 1600 x 600, or 800 x 600 on each screen. Then I just organized the PlayGui.gui so it would fill both screens, with the touchscreen buttons on the touchscreen(obviously) and the mission display(TSCtrl) on the main screen. It's working great.
@Jason - this is probably exactly what you're looking for, and before I updated the touchscreen, I had a set up with multiple camera views. So what you want should be very doable. If you're interested in the changes, email me at klamers@earthlink.net
Torque Owner OtakuNoZoku