Dear Conitec,
I have an effect that begins to act very strange as soon as I use d3d_antialias.
The same effect works fine when I activate antialiasing on my graphic card settings.
I already posted this problem in the shader section:

Antialiasing problem

Do I something wrong? or is this a known feature errrr I mean bug?

cheers

zwecklos

Edit: Sorry forgot to mention, Im using A704 Pro.

I don't know, but this could be an issue of your 3D hardware or driver. Try the values 1 and 4 for antialiasing. 9 uses an average of 9 pixels for antialiasing, maybe this causes artifacts due to a video driver issue.

Thanks jcl,
I already tried all the possible values (1, 4, 9)without success. I also tried to set the aa on my card settings and this works fine.
It screws up as soon as I use the d3d_antialias instruction no matter what values I use.
I will test out this thing on a diffrent machine with an ATI card.
Maybe this is a nvidia problem

cheers and thanks

zwecklos

i was reading about this issue in the showcase post, and then I stumbled on a similar subject in the textbook im reading for my dx class. if the rtt is done by any other way than using IDirect3DDevice9::GetFrontBuffer, it will mess up, not sure if thats how a7 does it or not.

What is rtt and what has antialising to do with a frontbuffer?

rtt = render to texture, the frontbuffer contains the current screen and thus the texture is rendered from the frontbuffer when using rtt. What the relation is between rtt and AA I do not know

Antialiasing on a Render_target texture is not supported by directX. There are some workarounds for doing this, like creating a rendersurface with enabled aa and then copy this using stretchrect (or similar) to a second, normal texture. But i think these are really slow.

im not sure why it wont work with a different buffer, thats just what it says in the book, since the class text is written directly by the teacher I could ask him why if anyone is interested.

DirectX antialiasing, render-to-texture, and the frontbuffer are 3 totally different things and have nothing to do with each other. Maybe your teacher confused this with postprocessing?

oops i posted it in the wrong thread here:
well i did talk to him anyways and heres a quote of the convo:

Quote:

---

lostclimategames> well my question is, when talking about the buffers there is a note that you cant copy any buffer except the front buffer for a screenshot when AA is on
<lostclimategames> now the 3d game engine ive been using has issues with postprocessing when aa is turned on and i thought it might have something to do with it
<lostclimategames> i just wanted to know if i had read that right
<adam> Right, the rules on this have changed somewhat in later versions of the 9.0 SDK, but yes, antialiasing causes some pretty significant problems when you want access to the frame buffer contents
<adam> let me just grab the SDK docs a second, there is a pretty good quote if I recall...
<lostclimategames> since im not expirienced what should i tell the person making it
<lostclimategames> heres a link to the site
<lostclimategames> that is talking about it
<lostclimategames> http://www.coniserver.net/ubbthreads/showflat.php/Cat/0/Number/774857/an/0/page/0#Post774857
<adam> ok thanks, let me I'll take a quick look....
<adam> Sorry for the delay, Just bear with me a moment, I'm discussing your point with a colleague
<lostclimategames> alright thanks
<fuzzlog> hey lost, which book is this you are talking about in the game studio forum?
<lostclimategames> the textbook has a note about it when talking about buffers
<lostclimategames> i think near the text about the difference between swapping and blitting
<fuzzlog> is this the GP1 book(PDF)?
<lostclimategames> yeah
<adam> Ok, I think I have all the cases nailed down here.
<lostclimategames> cool
<adam> Yes, the only real way to do this is to copy it out of the texture into a non AA surface
<adam> the only method in D3D which supports downsampling of multisampled surfaces is StretchRect
<lostclimategames> so is that what i should tell them?
<adam> Realistically, you have to make a copy of the rendertarget surface (the one that has multisampling applied) using StretchRect -- which will downsample the data -- into a non multisample render target texture
<adam> from this point, it can then be applied via SetTexture and mapped to his screen space quad as usual, to run his post-processing pixel shader
<lostclimategames> all right ill probably directly quote that if you dont mind
<adam> In earlier versions of DX9, I don't believe (although I could be misremembering) that even StretchRect did not support the downsampling of multisampled render targets to non-multisampled, so you were ultimately stuck....
<adam> Sure, hopefully I'm covering all bases there It's a little difficult to tell without understanding all aspects of what it is they are trying to achieve
<adam> but I'm pretty certain that StretchRect is the only way to go here
<fuzzlog> other than taking a snapshot, what would be the purpose of accessing the FrontBuffer?
<lostclimategames> post processing effect
<lostclimategames> you take that surface and run it thru a pixel shader for bloom, hdr etc
<adam> although, these days you would just capture the contents of the frame buffer
<lostclimategames> also you can use it for reflections
<adam> (or at least the "current" render target, which does not necessarily have to be the buffer currently in the swap chain)
<adam> it's used primarily with pixel shaders fuzzlog
<adam> for accessing previously rendered data
<fuzzlog> oh, ok. I've seen that done on the latest DX SDK samples
<adam> as lostclimate mentioned, reflections, deferred rendering/lighting, post-processing, HDR etc.
<adam> no doubt someone will come out and directly contradict me on that thread with an approach I haven't thought of
<lostclimategames> lol, that is how it works
<lostclimategames> you seem to know how a forum works
<fuzzlog> speaking naively here.... if it's a buffer (Front buffer) it must mean that its an array of data (pixel i presume) so it should be able to be retrieved and messed with right?
<adam> Right, albeit one which exists purely on the graphics adapter
<adam> rather than in local memory
<fuzzlog> oh, ok...blah, blah, blah "reading data from video memory bad!!!!" I remember
<adam> yes The trick is trying to get the hardware to bend to your will without ever touching the CPU

---

edit: by request i removed the email address of the teacher, his name is adam,so that you know which one the teacher is.