Multimonitor Ruminations
 

Sorry to report Jim, that no background animation is moving on the secondary monitor. The purple Gorgonia is stationary until MA3 is shown only on the primary screen. The fan coral is also still stationary when viewed only on the secondary screen.
The bottom edge of the background wash when different resolutions are used, is now fixed, and no smearing is visible. But it is still necessary to have both screens at the same resolution or the smaller resolution image is stretched to cover the whole screen, and the images on the two monitors therefore do not then line up.

ie. The secondary monitor is not showing the whole image at a lower resolution, (when one is chosen), it is cropping the second screen's image down to the chosen resolution, and then stretching it across the whole screen. .... Same as was shown in this post.



Because of the above, I have not yet been able to study the fish changes in any detail.

Edit: I've had chance now to study those three fish with the added Specular etc. - It's really nice to watch the shading on the sides of the fish vary as they change direction. Particularly the Copperband! ... Great job, Jim! :) ... The same three in Beta8 now look quite boring...

Hey Jim, On my secondary monitor the background object does not animate but is fine on single screen

Found the non-primary-monitor problem. The vertices were being copied to the other render units, but not the matrices. Try Beta8b.


Someone had mentioned that it looked as though everything was being done separately for each monitor. Well, of course that's exactly the case (and why multimonitors are so hard to implement). Each monitor has its own Render Unit within the program, which includes its own textures, object models, shaders, matrices, and any other device-specific objects and code. So the entire rendering loop has to be executed separately for each monitor. Cards which use system RAM instead of having their own on-board RAM might be faster on multimonitor systems, since they can probably get away with just one copy of the program. Several people have mentioned a slowdown when an MA3 window is partially on each monitor. On my Vista system, which uses shared memory, the program runs at full speed no matter how the window is split.

Part success, - animation on both monitors now in full swing! (Pun untended!) ;) - But only if both monitors are on!
All background animation stationary on secondary, if primary is selected to display nothing.
The different resolutions problem, is still present.

Still have a small problem with the Purple Gorgonia here on a triple monitor setup. I'm still not getting any movement of it under certain conditions. Here's a list of what I'm seeing:

1) when in windowed mode the Gorgonia has motion regardless of which monitor the window is on.

2) when set to span across all three monitors, the Gorgonia does not have any detectable motion. Though panning is turned on in this mode, there is almost no panning motion either since the width of the screens is almost equal to the width of MA3. I don't know if that has any bearing on this.

3) with the leftmost monitor set to "Display nothing on this monitor" the Gorgonia has proper motion while MA3 is panning back and forth across just the rightmost two monitors.

4) with MA3 set to "Render same image on all monitors", the Gorgonia moves properly on the leftmost two monitors but has no motion on the rightmost one. It is interesting to note though that the Gorgonia does show a correct perspective shift while panning on the rightmost monitor, just no current induced movement ala the sea fans.

Cliff - I'm not quite sure how to handle that situation. The calculations are all done for the primary monitor, then copied to all the others. It's assumed that if any monitor is on, it would be the primary. But if it is physically possible to run a system without a primary monitor, I guess I'd better figure out how to cover it.

Rick - That's a lot to digest. I'll have to mull it over.

I wouldn't worry too much about it unless someone else happens to be seeing the same thing. I just did some more checking on things and I'm starting to think it is something pretty specific to my setup. I went into Windows display properties and shifted my monitors around into various configurations. The end result is that there is only one configuration where I have MA3 span across all three monitors and the Gorgonia doesn't move. It's just a sign of my luck that it happens to be the config I normally use. :lol:

Nor am I overly worried about it not working with MA3 set to show the same thing on all 3 monitors since that is a config that I would never use anyway. ;)

Is it always Monitor 3 which lacks the animation? The monitor # is shown in the Statisitcs text, just before "Beta8b". Monitor 3 would be shown as #2, since we start with 0.

Jim, I'm sorry, I can't help you there. All I can do is compare MA3 to how other similar 3D applications behave that span two or more monitors. As I understand it, only one monitor can ever be the 'Primary', the next one, wherever it is positioned relative to the first, will always be the 'Secondary monitor'.

Rick, - I don't think it's the position of the monitor that will determine what might happen, It's the one that is set to be the 'Primary monitor' that will decide which screen will show movement, and which will show stationary animation. - At least that is how it works on my system. - Any (one, but only one!), of your monitors can be set to be the 'Primary'! - The choice is yours.

No, it's #1 in your stats text, #2 in Windows. My normal setup is:

http://webpages.charter.net/rlsimon/monitors.jpg

The image shows the monitor stats in the order that they are physically viewed.

Rick, - that #1 is your 'Secondary' monitor. And it is behaving the same as my secondary, - which is what I would expect,

I guess I need to somehow detect whether the primary monitor is shut down, and if so, to do the calculations on the first monitor I come across which IS turned on.

Yes, but whether it is turned on or not is determined by your MA3 Multimonitor Settings. The card's Display Settings is where the choice of which monitor will be primary is decided, - and that does not change even if you shut a monitor down.

Ah, if only it was my MA3 Multimonitor Settings. Then I might actually have a glimmer of an idea how it worked. It's a Microsoft thing - That's why those screens look so different. I just link to it, and it's supposed to handle everything else.

Oh!

Except that if I turn off my tertiary monitor and only run MA3 across 2 monitors, then it works just fine. It is only "broken" if I have MA3 spanning across all three or if I have MA3 set to "Render the same on all monitors".

Reading your posts 299 and 301, our primary and secondary monitors are/were behaving in a similar way. Things improved with 8b, - see my 297 post.

To be honest, with the sheer number of possible configurations, I don't tend to pay much attention to "primary" and "secondary" monitor names. It can mean a lot of different things on different systems. For instance, I happen to be running a PCIe Radeon 9550 which happens to be a dual output card and a PCI GeForce FX5200. In this case, the 9550 has "primary" and "secondary" outputs while the FX5200 has only a single output. Since PCIe happens to have the priority on this motherboard, the 9550's primary/secondary naming does happen to hold true. What if the situation was reversed though? What if I were running a PCIe GeForce MX400 which has only a single output and a PCI Radeon 9250 which has dual outputs? Since the MX400 is PCIe it would have priority and be the "primary" monitor for the system. Or perhaps I might be using a system with two video cards that each only support one output. Which one is "primary" and which one is "secondary" under that scenario?

Nor do the fun and games end there. I've run across quite a few motherboards that let you select in the BIOS which type of slot (AGP/PCI for instance) receives priority as the "primary" video output. How does that affect the "primary" and "secondary" display? There are also things like the Matrox Dualhead2Go to further complicate matters a bit. And then there is always the fun of Windows to be tossed into the mix. You can pretty much select any of your displays and assign it as the "primary" as far as Windows is concerned.

All in all, while the "primary" and "secondary" names can be meaningful in situations where you are only dealing with a single video card with dual outputs, or two single output cards where one of them is AGP/PCIe and the other is straight PCI, there are also a lot of other scenarios where it gets a lot murkier. That's why I tend not to pay much attention to those names.

I'm sure Jim will find that a great help.

Descending into Multimonitor Hell today. Got my flashlight and shotgun. If I'm not back in three days, carry on without me.

Ouch . Motrin pain . Is there any one group of settings that overides all others ? If not , it may be necessary to devise a set of connection standards for the program that users will have to follow in order to narrow things down a bit . Otherwise how on earth is this ever going to get sorted ? I bet it looks awesome when it's all working on multiple screens . So much of the detail is lost on a tiny little laptop .

Edit - sorry , Jim I wrote this before I saw your post . Good luck and godspeed .

Pack a good lunch..:D

:)

I'm willing to bet he already knows a great deal more than I do about such things. While I've been using multiple monitors for several years now with various configurations, I haven't had to access them via Windows API's. I shudder to think of having to deal with the way you can mix and match resolutions and physical screen positions under windows with a display output that needs to maintain a particular aspect ratio across the entire combined display area.

Well, that's actually the main problem here - I know almost nothing about multimonitors. I have always used just one monitor. I'm just an artist who has tried to pick up enough programming to display my artwork on a computer. Having never had any training in programming, Microsoft's multimonitor code is Greek to me. I get very depressed when I'm so bogged down by all these technical details that it looks like I'll never have time to actually create anything again.

It's like a painter who spends a year doing the perfect painting, then has to spend 10 years engineering the perfect hook to hang it on the wall.

Well one thing's for sure Jim, we all sure appreciate what you're doing and all the hard work you're putting into the SS. I know it's not fun to be bogged down with complicated computer crap.... Just keep remembering all the little kids who get such pleasure watching the fish.

If for any other reason... NO MORE PENUTBUTTER!

It looks like Edgar may be going into the multimonitor cave, instead of me. He says he might have an idea what's happening.

I just spent a couple of hours trying to set up a better system for testing multi-monitor stuff. My problem has always been that whenever I needed to test a new bit of code, I'd have to shut down my main development machine, drag the 24" monitor into the other room, hook it up to my multi-card machine, and fire up that system. Of course, the code experiment would never work, so I'd have to repeat the whole process hundreds of times.

About a year ago I had installed an nVidia 5200 card in my main dev machine, which automatically uninstalled (not just disabled) the on-board Intel graphics chip. What I didn't know until today is that I could re-install that chip. The upshot is that I now have two monitors working on my dev machine, and can instantly see the results of any tests. This should speed things up at least 10x.

To not pay much attention to which is the "primary" and "secondary" monitor in a multi-screen system, is like burying your head in the sand.
Understanding the significance of how multi-monitors can/should be connected, can be key to avoiding and/or solving problems during testing.
.....This thread illustrated just one example.... https://www.feldoncentral.com/forums...ead.php?t=4388

Sorry... I guess I didn't make my point clear. The words primary and secondary have little meaning in and of themselves. For instance, on this system I have 3 monitors, 2 video cards and I'm running WinXP. I can configure it so that the NVidia is the "primary" monitor in the BIOS, the ATI card has one output that it considers the "primary" and I can configure Windows to use the other ATI card output as its "primary". In a case like that, which one is "primary"?

Calling something "primary" or "secondary" in a multimonitor system means nothing unless you give some further context. In the above example, the NVidia card is "primary" if we're talking about which monitor will show the initial bootup screen(s) and would be used for accessing the BIOS. At the same time, the ATI secondary output would be the "primary" screen if we're talking about Windows and displaying the desktop. If I understand you correctly though, you would consider the other ATI output to be the "primary" since it is considered so by the card itself and the hardware supporting it.

Anyway, I'll shut up on the subject and let it rest now. My apologies for getting off topic here!

For what it's worth, I have a multi-monitor system; running MA3 full-screen, I get about 24fps; running it in a window that is completely on the primary monitor, I get 41fps, and the rest of my system runs perfectly smoothly; if I move that window to the second monitor, it drops to 12fps, but the rest of my system runs *really* sluggishly. It seems to me that if it's in a window, the window determines your view of the tank, and the calculations should be the same, regardless of where that window is. (Which monitor it's on should be irrelevant.) Unless your code is trying to write directly to the monitors... and trying to determine which part of the window is on which monitor on every single drawing cycle. (That would explain the degradation in performance, as it "wastes" time trying to figure out what should be drawn on monitor 1, before finally deciding "nothing", and moving on to monitor 2.) If that's the case, you need to fix the code to only do those calculations when the window is moved or resized; then remember the values so they don't have to be recalculated on each drawing cycle.

Note: I'm just guessing at how the code works, based on watching it run. If my guess is wrong, then just ignore the above. :-)

~Ralph S.

I would imagine that you are getting Direct3D acceleration on the first monitor, but not the second. When the Aquarium is on the second display, the CPU is having to do all the rendering and calculations and transformations of the fish and 3D graphics. When the Aquarium is on the primary display, the Aquarium just sends that info to the graphics card and the on-board GPU does all that work.

The very large drop in FPS when even only a small part of the window is on the secondary monitor, is something I've reported on a number of times.

I think the last thing that Jim said about it, was that we will probably have to live with it.

The problem is in the Graphic card drivers. In window mode, we don't have access to separate surfaces unlike Full screen mode.

I've just gone multi-monitor
 

I recently hooked up my HDTV to my laptop via HDMI to play around with multi-monitor stuff. My config: (1) Dell XPS M1730 with NVidia GeForce 8700M GT running in 1920x1200x32 on 17" WUXGA flat panel display; (2) Toshiba Regza 32RV530U 60Hz running at 1920x1080p.

Prior to this setup, the only real hands-on experience I had working with multi-monitor stuff was used primarily in Clone mode (as opposed to DualView). So I want to start by getting my bearings straight on what all this is supposed to be able to do, and what it cannot do, before I start looking at whether or not MA is doing things properly.

So for starters, is it possible to actually run an app, like a video player or MA, in full screen on the secondary display only? Or can they only be run in window mode, and then the window resized to fill the screen? Because I'm having a hard time trying to accomplish the former with either a video player (VLC) or MA3, so I'm guessing my only option is dragging the application window to the secondary display and then resizing it larger, correct?

Of course, once I do that, that opens up a whole other can of worms, and I'm seeing behavior similar to what rps described above.

But before I expand further on that, let me just get the basics out of the way as I stated, and confirm what I asked in the first place... about attempting to run an app in full screen mode in the secondary display only (while driving it with the video card from the laptop).

Thanks! :)

Actually, based on my own Googling, I just discovered that support for full screen on the secondary monitor is application specific. So in the case of MA3, I'm going to assume at this point that it is not supported.

So what I'm finding right now is that CPU usage on MA3 increases considerably when it's run in a fully stretched window on the secondary monitor. Also, a frame rate right around 125 fps is what it runs at on the primary monitor, or when running full screen and spanned over both monitors. But when running as a window in the secondary display only, frame rate drops to around 20 fps or less. (Even when said window doesn't overlap in any way with any other monitor.) And CPU Usage consumed by MA3 spikes to about 50%.

Full screen on both monitors is the normal way of doing it in MA3. With many video cards, choosing Windowed mode, then stretching the window across both monitors will slow the program to a crawl. An exception to this seems to be nVidia Dual-View, which doesn't seem to slow down when part of the MA3 screen is on each monitor (at least on my system).

It's not possible for a program to run as a screensaver on just one monitor if more than one is available. It needs to at least blank out the other monitor. Otherwise, your sensitive data would be showing.

Okay, gotcha! ;) And I did manage to get the VLC player to play my movie in the secondary monitor (the HDTV) while leaving my primary monitor open for me to continue to work in. It appears the version I had was bugged, but the ability to do this is indeed application specific and many other video players support it including Windows Media Player and Winamp.

Actually, I didn't have the window stretched across both screens, only over the Secondary. What I was trying to accomplish was to be able to continue to work on my laptop's primary display, while having the fishies running as big as possible in the second display only. So in this case, I'm not so much trying to run it as a ScreenSaver as opposed to just something to soothe me and keep me focused and sedated while I'm trying to write.

I'm using nVidia's DualView here myself , and just updated my drivers from Dell the other day too, sticking with their Dell approved drivers as opposed to getting the latest Forceware drivers right from the nVidia site. They're sometimes a couple versions behind by the time Dell authenticates them for their systems, so unless it's necessary for what I'm doing, I usually stick with the Dell-approved versions.

So yeah, I've been unable to get this multi-monitor config working the way I"d like to use it. Perhaps you'll say the way I want to use it is non-standard, and not a lot of people would want to use it this way, though I'd find that kind of hard to believe. Aren't there several others here who work on one display while running the fishies as big as possible in the other?

Multimonitor setups are not all the same, nor do they all respond the same way (as you're finding out). The differences between the various video cards, drivers and configurations can result in widely different results.

As a for instance, I'm running a triple monitor setup here with two monitors being driven off of an ATI card and the third being driven by an NVidia card. With the current version of MA3 in windowed mode, the FPS rate is just fine on either of the ATI driven monitors while it drops to a horrible level when on the NVidia driven monitor or if the window touches more than one monitor simultaneously.

In the end, you'll need to experiment and find out what works best for you on your system.

Thanks for the additional input Rick!

So yeah, both my monitors are being driven by the nVidia GeForce 8700M GT residing in my laptop. I have the driver configured to use DualView, i.e. treating each monitor separately. Running MA3 in it's default multi-monitor configuration, which is full screen spanned across both monitors, appears to work fine. Frame rate is around 125 frames per second, and I can't tell what the CPU usage is since it's running dedicated on both monitors, but nothing looks slowed down in the animations at all as evidenced by the high frame rates on both displays.

But I've only met with failure in any attempts to run MA3 on my secondary monitor while continuing to use my primary monitor to work on. This is the environment I'd like to work in but I can't get it working with any kind of reliability. :( I'd like to try to contribute and find out what the devs might want from me so they can track down the problem, or if it's specific to my system, what I could change to get it working. Because it should be possible for me to continue to work in my primary monitor, while running MA only on my secondary, right? Or is MA designed to only be used when you're not using any of the systems it's connected to at all?

Have you tried other 3D apps and see if the slow down happens?
If it does then driver and/or the card has the limitation.

Again - there is no provision for running in fullscreen mode while allowing a second monitor to display the desktop. This is not a problem to be tracked down, it's the way the DirectX screensaver framework works. The second monitor can either duplicate the first monitor, stretch the scene across both, or be blank. It's a security issue: Microsoft doesn't want your data to be showing on any screen when a screenblanker is running.

In anticipation that some people might like to view the Aquarium while working on something else, I added the Windowed Mode. The combination of even having a Windowed mode, being able to resize it to fill the second screen, and have it remember that size and position is probably unique to this program. If the card were more powerful, it would deliver more FPS. If that screen is set to 32-bit, you might gain some performance by setting it to 16-bit.