Sorry your browser is not supported!

Hi,
I've been poking around for some time, trying to get DBPro to work with multiple windows, linked to different cameras.
Copying the backbuffer to an alternative DC is dead slow, and copying between the DCs is a tad bit complicated, since using sync followed by the 'copy' code winds up out of sync.

Consequently I was wondering if it'd be possible to have the Present function directly in DBPro write to another window?
Supposedly there should be a hDestWindowOverride structure that could do the trick - any possibility of such a modification?

It might be possible to set a camera to render to an image, then pass a pointer to that image's D3DTexture (or whatever the class name is) to another application that will display that image.

DBPro doesn't render to windows. It renders to a surface in a swap chain, then tells DirectX to display that surface. The problem is that you can only specify the window as you create the swap chain.

So basically, you need to create a new swapchain for each window you want to render to, switch to a surface in that swapchain to do the rendering, then instruct DirectX to display the surface.

Additionally, DBPro's SYNC process only knows about its own swap chain.

Basically, you need a plug-in to do this, along with some fancy juggling of swapchains and rendering surfaces. You'll need to get involved in quite a lot of low-level details of rendering too, at the DBPro level.

Does that mean there's something not included in yournmatrix utils Ian

I'm not sure what the purpose of your goal is, be it to do an update to a window on every loop, or just once every so often.

However, a long long time ago I was wondering about this for use in a level editor. I did some experimentation, but ended up making do with one window.

You can either use a plugin like BlueGui to produce a new Window, and you set a camera to use an image as a render target; then the interface plugin can draw the image to a window; I cannot remember how fast it worked.

Another way is to create your own window class, represented by camera views (SET CAMERA VIEW command) and mask the window based on any areas not occupied by the views. It would look like you have an MDI interface, but again, I can't remember how fast it worked. I believe it was either Matrix1, BlueGUI or Styx that could set a window mask; also there should be a Windows API command that allows you to set a mask colour key, or mask image.

Finally, if you are only transfering a small set of parameters, file mapping could do the trick between two executable processes. But if you are writing things on a per pixel basis then forget it.

I'm working on a project in C++ and PGDK. I know I'm stuck with just 1 window but that isn't bothering me at all. I am, as Chris Tate says, using my own GUI and transferring images over to that window for previews. The previews are only drawn once and scrolled through a list of images. Nothing spectacular. And I've still got a long way to go before I am even in a position to give out proper pointers.

As said before you would have to go so in depth to get another window like DBP's, it's just not worth considering the hassle. A GUI is your best bet. There's a number of them to choose from.

Either work around it and use the one window, or use a GUI...