Bezel Code Suggestion
 

First, let me say that I'm a software developer my self, and I have a ton of respect and admiration for what you (Jim) have done with MA3! As I read the bug reports and feature requests being posted, you have my deepest sympathy as well - I've been there! (If only those pesky users would just go away... ;))

Anyway, I've been thinking about the bezel adjustment code, and I offer the following as a helpful suggestion:

I assume that the code works something like:
1) figure out where everything in the tank is
2) render it on a virtual display that is 3000 x 1024 (for a 1280 x 1024 monitor)
3) copy the portion starting at x0 to monitor1; x0 is adjusted from 0 to 600 (?) as the view pans.
4) copy the portion starting at (x0 + monitor1.width) to monitor2
5) repeat

If this IS the case, then it should be pretty simply to change the code in step 4 to:

4b) copy the portion starting at (x0 + monitor1.width + bx) to monitor2

where "bx" is an integer with a default value of 0, but read from the registry (eg: HKCU\software\SereneScreen\MarineAquarium3\Screen 2, BevelAdjustX)

That change won't (shouldn't) have any effect unless people manually change the value of BevelAdjustX; but those of us with dual monitors can tinker with that value and see how it affects the drawing code. If it works, we'll let you know, and we can figure out a good interface for adjusting this value later. If it doesn't work, we can reset the registry value to 0, and no harm done.

Does this make sense? (Is it helpful?)

Ralph S.

Step 2 is wrong, The whole scene is not rendered into a virtual display. That would cut the framerate way down. The scene is clipped so that only what is actually on the screens ever gets rendered.

Step 3 is also problematic, in that I don't really know which is Monitor 1, and the user can change this at will.

Unfortunately, Windows' multimonitor code and the drivers handle some of this behind the scenes, and that's what makes things difficult for me.

Ok, I understand. (Mind you, I'm making guesses as to how your code works.)

So how does Monitor 2 get rendered? Do you have code that specifically addresses each monitor individually? [e.g: for each monitor do render(monitor)] Or are you rendering the "visible part of the tank" to the windows desktop? (which in my case would be a single 2560 x 1024 window) The latter would make sense: in windowed mode, you write to the window's DC, in full-screen mode you write to the desktop DC. (Or define a window that's desktop-sized with no title or borders.) I'm beginning to understand the complexity here - since MA3 can be windowed, there is no concept of a "bezel" in windowed mode. (I think I may have answered my own questions.)

Is the output buffered before it's written to the window? I mean, do you render the tank directly to the window, or do you render it to a bitmap in memory, and then copy the bitmap to the window after each frame is completed?

~Ralph

To solve the issue of not knowing which monitor is number 1 and so on, why don't you have some options in your display dialogue like an "Identify Monitors" button to show numbers up on the screen like windows does and then make your own numbering system and then use that to do the bezel code adjustments? -

I hope the bezel gap fixer is not gonna be abandoned due to a failed attempt?

>>To solve the issue of not knowing which monitor is number 1 and so on

I think Jim meant that there's no [easy] way to identify monitor 1 vs monitor 2 from within the _code_. For instance, we generally assume that monitor 2 is immediately to the right of monitor 1, but that's not necessarily true. I've seen setups where monitor 2 is to the *left* of monitor 1 (and the desktop runs from -1280 to +1280). Also, the two monitors may not be the same size: I used to a have a 19" primary monitor, configured for 1280 x 1024, and next to it a 17" secondary monitor, configured at 1024 x 768. Also, what happens if a user has 3 monitors? or 4? (4 monitors could be all in a line, or they could be in a 2x2 layout.) Your suggestion helps the *user* identify a monitor, but that's not the issue here.

Anyway, hold that thought... right now I'm just trying to provide suggestions for how the drawing code might implement the bezel gap, without any thought as to how the user might specify or adjust such a gap. That's intentional - they're both tricky problems, and I'm trying to simplify the first part of that problem by setting aside the interface considerations. If there's a [relatively] easy way to implement the gap by introducing a few new variables/constants that can be set from the registry, then those of us with dual monitors can modify the registry and test the code, without affecting anyone else.

~Ralph S.

I'm trying to get the crystal into the tank today, so I haven't got time to go into the bezel gap issue right now. But at least I see that you guys understand some of the problems involved now.

My code experiment was actually fairly successful at adjusting the bezel gap of up to 4 monitors as long as the scene was somewhere in the middle of its travel - the problems came up when the scrolling got near the end and started to slow down, reverse and speed up again.