/* attempt to deal with prototype, bootstrap, jquery conflicts */ /* for dropdown menus */

\$30

### Image of the Day Submit

IOTD | Top Screenshots

## DirectX 9 and Multisampling

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

7 replies to this topic

### #1Paxi  Members

Posted 03 January 2013 - 07:45 AM

Hey guys,

Im currently looking for a good implementation for changing the multisampling rate at runtime. I would be fine if i can switch between the modes listed in here: http://www.nvidia.com/object/coverage-sampled-aa.html. (got a GTX680)
I thought about creating multiple render targets, with different mutlisampling mode/quality and depending on the desired AA mode set on of these as render target and finally copy its content to the backbuffer. I already started with this approach but atm im very unsure if thats a good solution respectively if its even possible to work.
I wanted to use

CreateRenderTarget(...)

and then either use either

UpdateSurface(...) StretchRect(...) GetRenderTargetData(...)

to copy the contents from the Rendertarget in the backbuffer.

Now after I spend some time with this approach, first I thougt that its not really good to copy the content from the rendertarget to the backbuffer at each frame. And secondly, more important: all this functions have listed under the remarks that the surface must not have a multisampling type or it wont work. (which would definately "kill" this approach for me)

Another idea of mine was, just resetting/recreating the device every time the user wants to change the AA mode and fill in the new device parameter with the new multisampling type. But I guess, this is a very bad solution.

Now is it possible to do something like with my first apprach with different render targets to get this working? Or if not, how would one in general do something like this? I unfortunately havent found any code samples on this. Im using HLSL by the way, probably i can also control the Mulisampling rate within my shader. Performance in general is no issue for me, its just a little techdemo.

Regards

### #2MJP  Moderators

Posted 03 January 2013 - 03:53 PM

Standard use of multisampling always involves a "copy", where the the MSAA surface is "resolved" to a non-MSAA surface. For render target textures this process is performed by using StretchRect, where the destination surface has the same dimensions and format as the source surface (which has MSAA enabled). If you create a backbuffer with MSAA enabled this process will happen transparently behind the scenes, so you're not wasting any performance or resources by doing it manually.

### #3Paxi  Members

Posted 03 January 2013 - 04:24 PM

Thanks your for the explonation first.
But I´m not sure if I understood this correctly:
If i enable MSAA at my backbuffer (i only got one in my current application), I can only choose one mode of MSAA and than copy the content to a render target with no MSAA. But still I cannot switch between different MSAA modes if i understood you correctly. Or do I have to create more than one backbuffer (swap chain) with different MSAA settings set? And because u said "render target textures" before: how exactly is a render target handled within DX? I thought about it in a more abstract way, that more things could belong to the term "render target", a backbuffer but also the top level surface of a texture for example, so i was thinking just about a region of memory on the GPU.

### #4mhagain  Members

Posted 04 January 2013 - 04:33 AM

Resetting the device is not such a big deal - you already have to do it if you wish to support resolution changing, fullscreen/windowed switches, and vsync, so adding multisampling to your existing code should be easy enough (if you don't have existing code for this then you're going to need it when you do get around to supporting these things).

Another option for you, if you just want some form of AA but are not too concerned about what specific form it takes, is to look at a shader-based solution (like FXAA) that works as a standard post-processing pass.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

### #5Paxi  Members

Posted 04 January 2013 - 10:21 AM

You are right. Resetting the device seems fine for my purpose. I just realized that i dont have to really recreate the device but rather just pass in the new d3dparameters when resetting. I already got some code for this, so the integration shouldn´t take much time with this approach in addition

I will still wait at a final answer from MJP regarding the render targets just because of interest.

Using the shader for AA looks very interesting as well but Im not that comfortable with HLSL so far so I prefer the solution with resetting/render target for now.

### #6Paxi  Members

Posted 06 January 2013 - 09:05 AM

In the meanwhile I already implemented some MSAA modes with resetting the device. This approach was quite easy, the only thing i had some issues with first, was releasing all  data so Reset didnt give me an INVALIDCALL error.

Although this is enough for me for now, I would still appreciate some more info about the approach with using multiple render targets, concerning post#3 from me

### #7MJP  Moderators

Posted 06 January 2013 - 02:32 PM

You wouldn't want to create a render target for every different MSAA mode, this would be a waste of memory since you'd only ever use one of them in a particular frame. Typically you would just create the render target with the currently-selected MSAA mode, and then re-create it if the user decides to switch modes.

### #8Paxi  Members

Posted 06 January 2013 - 03:38 PM

Thanks again. Sounds logical.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.