• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Paxi

DirectX 9 and Multisampling

7 posts in this topic

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

 

 

0

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites

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.

 

Thanks in advance

0

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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 :)

0

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0