Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

IFooBar

ignoring redundant renderstate->

This topic is 5675 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

hello Ive notices when in debug mode that i get butt loads of the message "ignoring redundant renderstate" this probably means that i''m setting states that are already set correct? how do I make sure im not setting states that are already state? I would guess Id need some sort of state manager? how do i go about it? thanks for any help
:::Al:::
[Triple Buffer V2.0] - Resource leak imminent. Memory status: Fragile

Share this post


Link to post
Share on other sites
Advertisement
quote:
Original post by alfmga
hello

Ive notices when in debug mode that i get butt loads of the message "ignoring redundant renderstate" this probably means that i''m setting states that are already set correct?

how do I make sure im not setting states that are already state? I would guess Id need some sort of state manager? how do i go about it?

thanks for any help




Yep, that''s correct: You''re setting states that are already set to that value.

You can check if a state has already been set via m_pD3DDevice->GetRenderstate(). You pass the required renderstate (i.e. D3DRS_CULLMODE) and a pointer to a DWORD variable, which will receive the current value of the renderstate. So if counter-clockwise culling is currently on, m_pD3DDevice->GetRenderState(D3DRS_CULLMODE, &dwValue); would result in dmValue receiving the value D3DCULL_CCW.

Apparently, though, redundant renderstates are not a big deal, performance-wise. Anyone who wishes to comment on that, by the way, please do.
Anyway, I''m not sure about that, but I do know that those messages really mess up your debug output, so I prefer not to get any. Good design often gets you a long way in removing unnecessary renderstates. For instance, in a highly simplified example:

render loop:
- Turn Alpha off
- render a
- turn alpha on
- render b
- turn alpha off
- render c

this would cause alpha being set to off twice, everytime you call the render function again. You could best change it to:

Once, at startup: Turn alpha off

render loop:
- render a
- turn alpha on
- render b
- turn alpha off
- render c

And your redundant SetRenderState is gone. If there''s just no way of doing this, just check if it has already been set, either via GetRenderState or a manager of your own.


Share this post


Link to post
Share on other sites
I''d like to add a question here:

According to your example, the renderstates (at least the way I understand it) remain as they were even after the scene has ended, been displayed, and then began again.

Is this correct, or was your example only for rendering multiple objects on the same frame?

Thanks .

Share this post


Link to post
Share on other sites
thanks for the reply. So since redundant renderstates are no biggy performance wise then, One would''nt have to make some kind of renderstate manager that handles all the setting of render states right?
Does directX internally check if a renderstate has already been set? if yes then if you checked yourself too, then that would make it double checking which is a waste.


:::Al:::
[Triple Buffer V2.0] - Resource leak imminent. Memory status: Fragile

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
It''s best to have a ''default'' state where all the renderstates are set to their default values (the way they are when your app starts up). Then, whenever you render something, change the renderstates needed, then change them back when you''re through rendering that object.

There IS a performance hit for redundant renderstates, as changing a renderstate is quite costly. For most renderstates, it changes a value on your video card, which requires a change to be sent across the AGP port and data going in and out causes clashes that slow down your processor. Moral of the story: only change renderstates when you need to. The same goes for changing textures, but that''s another story.

The keeping-the-default-states method of rendering has been used in many games, such as Tribes 2, where the scripts have to revert to this default state, or the game will look funky. And you might want to look into render blocks (CaptureStateBlock(), BeginStateBlock(), etc.) that allow you to get a handle to a specified state-block, allowing you to set a whole lot of states with a single call (REALLY speeds up your app). Hope this helps.

Chris
<ctoan>

Share this post


Link to post
Share on other sites
yeah thanks that did help. So the way I understand it is implementing a renderstate manager as a singleton or something would be the best option. So that the whole app uses just one.

[Edited for concept corrections]


::: Al:::
[Triple Buffer V2.0] - Resource leak imminent. Memory status: Fragile

[edited by - alfmga on December 8, 2002 3:22:10 AM]

Share this post


Link to post
Share on other sites
I''m wondering... Which would be better? A singleton renderstate manager, or a function that simply calls GetRenderState and checks if it has already been set?

The GetRenderState call every time would cause some overhead, of course, but so would a manager.

Share this post


Link to post
Share on other sites
Nice topic . Actually , using GetRenderState() each time you want to set a render state would be very expensive for large levels , 30-100 times per second , not only due to the call itself , but due to the additional if statements that you would use to check the value and act respectivelly (Correct me if i am wrong).The best approach would be to render everything in such a way , tha RenderStates calls are reduced to minimum.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!