• Advertisement
Sign in to follow this  

anti-aliasing problem

This topic is 4403 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've got a DX9 app that I thought was working perfectly on a wide range of cards. However, if someone has nvidia hardware and uses that terrible "override app and force anti-aliasing on" feature in their control panel then the app gets a black screen. It doesn't seem to be one specific nvidia card either, i've reproduced it on FX5500, GF2 and GF3. The app does appear to be running and generates no errors, but the screen is black (back buffer clear colour). Strangley, if I force anti-aliasing on via the desktop control panel on any ATI card then everything works great. So I have what appears to be a perfectly functional game on all hardware except nvidia stuff when the user forces anti-aliasing on. Anyone ever seen anything like that before?

Share this post


Link to post
Share on other sites
Advertisement
I have seen strange behaviors with forced AA on an old DX7 application but so far not with a DX9 app. Do you have any operations that access the back buffer direct?

Share this post


Link to post
Share on other sites
Or do you use MRT at all? Since AA and MRT isn't supported at the same time - the calls might not be getting through at all.

Share this post


Link to post
Share on other sites
In the case you have the full code for this app you should try some things:
1. Change the clear color and check if the screen shows the color or still black.
2. Force AA inside the app and check what happened.
3. I assume you have already run it with the debug runtime and checked the output.

Share this post


Link to post
Share on other sites
1. done - it showed the colour I'd expect.
2. done - same behaviour as when it is forced on in the customer panel, no game errors reported.
3. yes, I get a few of the following warnings:

"Ignoring redundant SetTextureStageState"
"Ignoring redundant SetSamplerState"
"Ignoring redundant SetRenderState"

Which I assumed were unimportant, and one error:

"Unsupported independent write mask on device"

Not really sure what is causing that one or what it means.

Share this post


Link to post
Share on other sites
That is strange as independent write masks are only used together with MRTs or multi element textures.

Do you have any D3DRS_COLORWRITEENABLE, D3DRS_COLORWRITEENABLE1, D3DRS_COLORWRITEENABLE2 or D3DRS_COLORWRITEENABLE3 render state settings in your code?

Any SetRenderTargets? Maybe you have used a wrong index there.

Anyway you can try to set the “Break on Error” feature.

Share this post


Link to post
Share on other sites
Quote:
Do you have any D3DRS_COLORWRITEENABLE, D3DRS_COLORWRITEENABLE1, D3DRS_COLORWRITEENABLE2 or D3DRS_COLORWRITEENABLE3 render state settings in your code?


There is only the one reference to D3DRS_COLORWRITEENABLE which is to set it to the default 0x0f value.

Quote:
Any SetRenderTargets? Maybe you have used a wrong index there.


I do have a setRenderTarget call, but that only kicks in part way through the game when the player does something specific. Initially it just defaults to the current viewport and the anti-aliasing blackscreen bug is there right from the start.

Quote:
Anyway you can try to set the “Break on Error” feature.


I've tried using the "break on error" feature, which normally works ok, but in the case of the write mask error I don't get a full call stack, it stops inside ntdll.dll and I can only back up as far as d3d9d.dll.


I also tried downloading the latest DX sdk as I was still on the xmas release, but it made no difference.

Share this post


Link to post
Share on other sites
Quote:
Original post by Poo Bear
I've tried using the "break on error" feature, which normally works ok, but in the case of the write mask error I don't get a full call stack, it stops inside ntdll.dll and I can only back up as far as d3d9d.dll.


Have you tried it the other way? Stepping over the D3D instructions until the Error message is shown?

Share this post


Link to post
Share on other sites
Ah right, there was some other code trying to set default values on colourwriteenable, but they were setting it to 0x00 when it should have been 0x0f. Silly mistake.


Anyway...


I now have no DX reported errors whatsoever (which is nice). I still have the same anti-aliasing bug though - curses :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement