Jump to content
  • Advertisement
  • entries
    232
  • comments
    1463
  • views
    960670

Multimonitor support

Sign in to follow this  
Ysaneya

882 views

Multimonitor support

Finally, I have recently added multimonitor support.

If you've followed Infinity's development for a while, you'll probably go, "eh ? I thought it already supported multiple monitors !?", thinking to Kaboom22's triple-screen setup.

The trick here is that Kaboom's system used a special device, the Matrox Triple head 2 GO to make windows "believe" there's only one physical monitor instead of 2 or 3. It's completely transparent to the program; Windows just reports a single screen of a wide resolution ( like 3840x1024 ) instead of three.

But if you have a multimonitor setup ( 2 or 3 screens ) without this device, like me.. well.. you're out of luck.

A week ago I decided to have a look at adding support for multiple screens into the I-Novae engine.

Technically, it's not so hard. After all, all you need to do is to create two windows, one on each screen ( in case of a dual screen setup ), to create two cameras, and to render the scene twice.

Of course, you get a 2 times slow-down ( or 3 times in case of a triple config ).

Fortunately, I took a different approach. I'm still creating my 2 windows, but I now use the engine's pipeline to create one virtual off-screen buffer. The scene only has to be rendered once. Much better! Then in the final stage, the buffer is shared and split between the windows.

It's also a lot faster in case your second monitor doesn't have hardware acceleration, because technically, the rendering only happens off-screen on the first monitor's device.

To implement all of this I had to tweak many small bits everywhere in the engine, and add new concepts. A few subtle bugs when sharing textures between different GL contexts with the texture cache. A monitor lister. Management of virtual windows. Etc..

The result is pretty cool, and if properly set up, the images are perfectly seamless. For example, consider this one, taken on a dual monitor config, each screen being full-screen 1280x1024 (click for full-screen):



That pic was simply taken with the "Print Screen" key in Windows.

Now, in windowed mode, you can see better how the buffer is split in 2 windows:



Note that nothing forces the windows to get perfectly aligned or to "touch", and they can even be of different resolutions ( meaning that it'll work perfectly even if your monitors have different resolutions ).
Sign in to follow this  


17 Comments


Recommended Comments

Impressive! If you screens are different resolution, which do you pick for the offscreen buffer?

Share this comment


Link to comment
Quote:
Original post by swiftcoder
Impressive! If you screens are different resolution, which do you pick for the offscreen buffer?


One would assume you'd use the smallest rectangle that can contain all of the screens involved. :)

Share this comment


Link to comment
Quote:
Original post by swiftcoder
Impressive! If you screens are different resolution, which do you pick for the offscreen buffer?


For the offscreen buffer, you use the dimensions of the windows areas added together. If a window is smaller, it is stretched in the virtual buffer.

Share this comment


Link to comment
[wow] That shot looks amazing, regardless of how many monitors it spans. Bet the scale really comes out when it's spanning 2-3 displays though...

Question :- I assume you have some sort of render-target texture as your offscreen buffer, which is presumably limited in some form by the underlying hardware. Correct? If so, common texture limits are 2048 or 4096 which would surely screw up how many displays you can render into one buffer?!

Or is OpenGL different from Direct3D in this regard?

Keep up the good work,
Jack

Share this comment


Link to comment
Very, very cool. [smile]

This begs the question, though: if you're on a dual monitor setup and you're playing, would your centre of view be the edges between the monitors?

Share this comment


Link to comment
Quote:
Original post by jollyjeffers
Question :- I assume you have some sort of render-target texture as your offscreen buffer, which is presumably limited in some form by the underlying hardware. Correct? If so, common texture limits are 2048 or 4096 which would surely screw up how many displays you can render into one buffer?!

Or is OpenGL different from Direct3D in this regard?


You can easily render to rectangle textures, so it matches the windows sizes perfectly. It's however true that the maximum resolution is limited to 4096.

Share this comment


Link to comment
Quote:
Original post by LachlanL
This begs the question, though: if you're on a dual monitor setup and you're playing, would your centre of view be the edges between the monitors?


The million dollars question. At the moment, it does, yes :)

That's certainly a problem. I'm not sure how to solve it. I guess you could get used to it pretty quickly (#1), or "turn" the view a bit so that the direction you're traveling is in the center of the main screen (#2). Or, as it's been suggested, use the other screens as an area for the user interface (#3).

The problem with that last idea is that the UI is rarely big enough to cover one full screen. And anyway, it's transparent, blended over the 3D background, so you still have to render a 3D background. I think combining #2 and #3 is the best.

Another possibility is to render the front view in the first screen and the back view in the second screen, but it might give an unfair advantage in combat, and performance wise it would require rendering the scene twice, because it'd need 2 cameras with a different viewpoint/orientation.

Share this comment


Link to comment
Have you considered having a blind spot between the monitors? One thing that always annoys me is how things instantly transfer from one monitor to another.

The distance in real life between two pixels in the one monitor or across monitors doesn't have a one to one correspondance with the image on the screen. I'd like to be able to add an adjustable blind spot to correspond to the distance between my monitors' edges.

Edit - upon re-reading, that seems to be implied in the last phrase. Ignore, please :)

Share this comment


Link to comment
Nice, I like it.

BTW how did you get a SS when in fullscreen with GL on Vista? You are running Vista aren't you? Since GDI doesn't work with GL. So are you just copying the framebuffer out and saving it as a texture file?

Share this comment


Link to comment
Ysaneya, I believe one of the approaches discussed was to not have just the standard UI overlay in another window, but one of the ship control UIs or customizable XML mishmash in that other window. Things like energy and weapons controls, engineering features, inventory, those sorts of things. Larger interfaces that the player would normally switch on and through on a single, semi-transparent screen. It would just allow them to glance at the other screens to track, rather than flashing them up. Almost flight simulator, in a way.

Share this comment


Link to comment
You found a way to not let the performance slip away when using multiple monitors, leaving just one problem: the centre of focus, or screen-centre.

If multiple monitors no longer are a problem then why not 'simulate' an extra monitor (if that's possible at all). If it's possible you could give that monitor any desired size to make the centre of the scene be the exact centre of the monitor of choice.

I'm no specialist, I just came up with it..

Share this comment


Link to comment
Quote:
Original post by MARS_999
Nice, I like it.

BTW how did you get a SS when in fullscreen with GL on Vista? You are running Vista aren't you? Since GDI doesn't work with GL. So are you just copying the framebuffer out and saving it as a texture file?


Yes, it's Vista + GL. Well, as I explained, it's really nothing special. Just pressed the Print Screen button, and paste the image into photoshop or your equivalent software, and voila. It's exactly like on XP, except it works seamlessly between the two monitors.

Share this comment


Link to comment
Vileedge, with the current system it's possible to do that, if the GUI windows can be moved and resized you just throw all of them in the second monitor and there you have it :)

Share this comment


Link to comment
Quote:
Original post by Ysaneya
Quote:
Original post by MARS_999
Nice, I like it.

BTW how did you get a SS when in fullscreen with GL on Vista? You are running Vista aren't you? Since GDI doesn't work with GL. So are you just copying the framebuffer out and saving it as a texture file?


Yes, it's Vista + GL. Well, as I explained, it's really nothing special. Just pressed the Print Screen button, and paste the image into photoshop or your equivalent software, and voila. It's exactly like on XP, except it works seamlessly between the two monitors.


Really? I tried that an no luck. I am running Vista and GL myself an all I get is the desktop when running inside of VC++ while the app is running. I ended up just copying the framebuffer and saving it as a texture...

Share this comment


Link to comment
Do you intend to support multiple cameras as well as multiple monitors?

If each monitor had it's own camera, you get the very cool feature of being able to put a monitor to your side for a quick glance out the side window.

That would also enhance the immersion very much, since the periphery vision is essential for the spatial "sense". That's also exploited by commercial flight simulators.

The same feature could also be used for "rear mirror" monitors. I imagine that could be useful for dogfights.

As you mentioned would slow the rendering down by a factor of n, but a side view would need much lower resolution and rendering quality, so the performance hit might not be that bad. Maby a factor of 1+(n-1)/2?

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!