Hi, I''m working on some code that blt''s from some offscreen surfaces to a back buffer and then flips it to the primary surface. I''m using D3D8.1 and using dual monitors (two devices). The problem is that I load all these offscreen surfaces using IDirect3DSurface8 objects, but they are tied to one device or the other. So when I go to CopyRect from the offscreen surface of one device to the back buffer of another device it fails and doesn''t blt anything. I want to be able to blt from one surface to both screens. Is there a way to get around this?? Maybe another function that could blt from surfaces regardless of what device thay are tied to? Any help would be greatly appreciated. D

Hmm, well I have to display the scene on two monitors, so there are two devices, one for each monitor. I beleive (and correct me if I''m wrong) that using CreateAdditionalSwapChain will only allow me to "split screen" the output to one monitor.

This is one executable that renders two scenes, one for each monitor.

To make your directx app run smoothly on two monitors
you really need to set up a completyly redundant
environment, that is:

1. Create 1 directx base component
2. Create 2 directx devices
3. For all your textures, vertexbuffers etc. etc,
create 2 of each (the same, only attached to its
own device). Make it all redundant. Operations (like
copyrects) between different devices, I think is not
very fast (if possible).
4. For every frame in your "game loop", do it all twice,
one time for each device/monitor.

You now can render all you want from device 1 to monitor 1
and from device 2 to monitor 2

To do this successfully, you of course need to calculate
correct viewports and viewmatrices for each monitor

If you use windowed mode, things become even trickier

I tried to use one window, rendering only to the part of
it that was on the right monitor. This didn''t work well
as speed dropped rapidly once part of the window was on the
wrong one, even though I rendered only to the correct part
of it. So I think you need to split the window into two
smaller windows at runtime as your user changes the mother
windows position.

" and so it shall be, upon having completed thy scene, you
will find it so much fun, you will do it once more!"

Was this of any help to you at all ?

Well, it seems like the wonderful folks who put D3D together didn''t use there noodles very effectively when making the IDirect3DSurface8 interface. It ties directly to a device but can only reside in system memory... wtf?? So I have to create two identical surfaces in the "reletively" same area of memory just to use it on two devices?!! That''s just stupid.

Sorry, that''s just my little rant. See the thing is I''m loading over 12megs of images to be used on the screens, I hate to double that just because I can''t make one device pull from the same part of system memory that another one does. They did it right with Direct Draw, why did they have to go an mess it up with D3D? Of course in direct draw you have the choice of where you want the surface to be stored.

I hope they fix this "seemingly" bad mistake in DX9.
D

I hate to disapoint you
But this is not a bad mistake from the dx-folks
And it won''t be fixed - ever !

Here is why:

Your two monitors are driven by two different adapters
Two adapters do not share lightning-speed resources
like on-board memory

you must duplicate it all !!

I myself have a matrox G550. This is one card / two monitors.
but I still have to treat them as separate cards when
setting up directx :-)

This is how it is
And it allways is how it is
If it wasn''t like this, it had to be like
something else ...

Yes, I am aware that each monitor is driven by one device each, and that each device has it''s own graphics DSP and memory. Maybe I''m not understanding you right or vice versa, but IDirect3DSurface8 is system memory only... we aren''t talking about moving data between video cards, we are talking about moving data from system memory to video card memory. Since both cards have to pull the data from system memory, why can''t they just share that memory a little?? GDI does it, DDraw does it. Granted they would have to take turns, but big deal, they have to take turns anyway. If the surfaces were left untied to a device, then any device could lock the surface, get it''s data, release it and be done, let another device access it.

Maybe I''m missing something, and I guess it doesn''t really matter at this point, just trying to understand the rational if there is any.
D