MultibleDevices, Viewports, SwapChains ???
Hi everyone!
My question belongs to the topics headline:
Multible devices, Viewports and swap chains.
What is doing what? As far I could figure this out is that viewports for example uses the same backbuffer as specified in the PP structure. With this I can split the current rendet target in multible parts and then I can render to it, with different views and projections. I could imagine, this could become handy when I have to render the rear view mirror in a racing car, for example.
The same with swap chains. Except that I have to specify one or more HWND based windows, so I can get a separate back buffer surfaces out of it. And this could be useful for what? For effects?
The multible devices are still left. I have absolutely not idea for what they can be used of how they can be created. But there is a function;)
In what situation would the following example falls in?
Assume, I want to make a Material - Texture viewer, like in some 3d programs.
In my mind, that material-texture viewer displayed spheres with the materials and texturs on it.
Do I have to display every sphere in a separte window? And what mode do I have to use? I mean Vp, Sc or Md?
Right now, I have made something with swap chains.
It works greatly! I have four windows and with the keys 1, 2, 3, 4 I can swith between those. But when the app starts, the windows don´t gets drawn, except the activated. This means, a window just gets drawn, when I push the propper number, so the activation flag switches.
And what I´m asking myself is, how often may I update the windows, to draw?
That is it.
Thanks
Alex
I find multiple swap chains useful when developing authoring tools, like a map editor. Usually in applications like this, you want to mix direct 3-D rendering with using normal controls. With different viewports you can't put regular Windows controls between them, like you might do with scrollbars in a map editor, where you have a scroll bar for your map and then below the scrollbar you have a bunch of tiles you can click on. Of course you could draw your own scrollbar, but that's a lot of work.
I think you only want to use multiple devices when there really is more than one video card in the system, and you want to use both. IIRC, according to the documentation, textures and surfaces created on different devices can't be shared between them.
I think you only want to use multiple devices when there really is more than one video card in the system, and you want to use both. IIRC, according to the documentation, textures and surfaces created on different devices can't be shared between them.
Multiple Devices - Gives the ability to render information on different cards and monitors at a fast speed. Creating a device on one card and then presenting that to a window on a monitor controlled by a different card will run quite slow. Each device needs it's own copy of textures, vertices, etc, making it a pain to develop for. Flight Simulator likely supports this, as you often see FS setups with many monitors. Modelling tools are likely to support this to accomodate artists who like to work across multiple displays. Nobody else tends to bother.
Multihead devices - When a single card drives multiple monitors, it's driver may expose multihead mode. When the multihead flag is set, the presentation parameters pointer is assumed to be an array. A few games support this. A single device can be used to draw to multiple monitors. Documentation on this is scarce.
Multiple swap chains - Only available for windowed mode. Allows a single device to create extra swap chains with their own present parameters. Useful to draw to multiple differently sized windows (if the windows are the same size you can just Present to a different HWND). Can be used for "fast reset". When you resize the device backbuffer you must reset the device, which is slow. If you never use the real backbuffer, and do all rendering via swap chains, you don't need to reset the device, just destroy and recreate a swapchain. Useful to render to different panes of splitter windows, popup windows, "high quality" windows with AA enabled, etc.
Viewports - Selects a sub-region of render target. This can be part of the device backbuffer, part of a swapchain backbuffer, part of a render target texture (ie: an imposter atlas page).
So...
viewports = subrects of a render target
swapchains = multiple windows on a monitor, and/or fast reset
multihead = multiple monitors on a single card
multidevice = using multiple graphics cards
Multihead devices - When a single card drives multiple monitors, it's driver may expose multihead mode. When the multihead flag is set, the presentation parameters pointer is assumed to be an array. A few games support this. A single device can be used to draw to multiple monitors. Documentation on this is scarce.
Multiple swap chains - Only available for windowed mode. Allows a single device to create extra swap chains with their own present parameters. Useful to draw to multiple differently sized windows (if the windows are the same size you can just Present to a different HWND). Can be used for "fast reset". When you resize the device backbuffer you must reset the device, which is slow. If you never use the real backbuffer, and do all rendering via swap chains, you don't need to reset the device, just destroy and recreate a swapchain. Useful to render to different panes of splitter windows, popup windows, "high quality" windows with AA enabled, etc.
Viewports - Selects a sub-region of render target. This can be part of the device backbuffer, part of a swapchain backbuffer, part of a render target texture (ie: an imposter atlas page).
So...
viewports = subrects of a render target
swapchains = multiple windows on a monitor, and/or fast reset
multihead = multiple monitors on a single card
multidevice = using multiple graphics cards
Wow, many many thanks.
@Namethatnobodyelsetook:
Do you have some links for multihead programming tutorials or which are linking to the scarce documentation?
Still a question.
What if I want my app be able to switch between multible numbers of windows?
Example: When I right click on the screen, I could choose between one windowed mode or two windowed mode or three or four windowed mode.
When I do this, I mean, switching between the amount of presenetation windows, I have to recreate the swap chains?
Is that correct?
But once again, what about the update rate for the windows?
For example, when I alter the scene, when do I have to update the other three windows, if I have 4 windows and I´m altering the scene on the fourth...
Thanks
Alex
@Namethatnobodyelsetook:
Do you have some links for multihead programming tutorials or which are linking to the scarce documentation?
Still a question.
What if I want my app be able to switch between multible numbers of windows?
Example: When I right click on the screen, I could choose between one windowed mode or two windowed mode or three or four windowed mode.
When I do this, I mean, switching between the amount of presenetation windows, I have to recreate the swap chains?
Is that correct?
But once again, what about the update rate for the windows?
For example, when I alter the scene, when do I have to update the other three windows, if I have 4 windows and I´m altering the scene on the fourth...
Thanks
Alex
All I know about multihead is from the SDK, and it's not nearly enough to actually use it.
To change the size of, or number of windows, you will need to destroy your old swapchains and recreate new ones. You should also be destroying and creating depth surfaces of the appropriate sizes too.
The update rate for the windows is entirely up to you. For example, in a traditional 4 view modeller, when rotating a user view, you only need to update that one view. When the object is modified, or to indicate selection, all 4 views will need redrawing to show the new state. If you pop up a material editing window, only the sample preview of the material will need to be drawn, not the 4 views. If you receive a WM_PAINT message, you might want to force a redraw on all views as they might be corrupted otherwise.
To change the size of, or number of windows, you will need to destroy your old swapchains and recreate new ones. You should also be destroying and creating depth surfaces of the appropriate sizes too.
The update rate for the windows is entirely up to you. For example, in a traditional 4 view modeller, when rotating a user view, you only need to update that one view. When the object is modified, or to indicate selection, all 4 views will need redrawing to show the new state. If you pop up a material editing window, only the sample preview of the material will need to be drawn, not the 4 views. If you receive a WM_PAINT message, you might want to force a redraw on all views as they might be corrupted otherwise.
Hi and thanks.
According to the material texture preview, how do I have to render the preview samples?
I mean, do I need to copy the existing device when the material texture viewer is popping up? Should I then draw the spheres with that device into the new d3d windows of the mat tex viewer/editor ? With multible devices, can I have multible BeginScene() EndScene() - sections? For every device one?
Because this mat tex viewer/editor could run in an extra thread, if this was possible, I mean the extra BeginScene() EndScene() section.
If the mat tex viewer/editor opens, the new thread will be started and the viewer/editor gets started with its own BegScene() EndScene() section.
So I can render the mat tex shperes in the parallel running BegScene() EndScene() section.
I think further... What about objects, in an object viewer, comming straight from the object manager? Must be the same?!
Alex
According to the material texture preview, how do I have to render the preview samples?
I mean, do I need to copy the existing device when the material texture viewer is popping up? Should I then draw the spheres with that device into the new d3d windows of the mat tex viewer/editor ? With multible devices, can I have multible BeginScene() EndScene() - sections? For every device one?
Because this mat tex viewer/editor could run in an extra thread, if this was possible, I mean the extra BeginScene() EndScene() section.
If the mat tex viewer/editor opens, the new thread will be started and the viewer/editor gets started with its own BegScene() EndScene() section.
So I can render the mat tex shperes in the parallel running BegScene() EndScene() section.
I think further... What about objects, in an object viewer, comming straight from the object manager? Must be the same?!
Alex
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement