A renderstate manager implementation

Started by
11 comments, last by IFooBar 20 years, 11 months ago
I just want to ask if it''s worth controlling all the render-states and texture stage states manually. What I mean is this: Say I have a tree that holds a structure of type RENDERSTATE
  
struct RENDERSTATE
{
    D3DRENDERSTATETYPE state;
    unsigned long value;
    RENDERSTATE( const D3DRENDERSTATETYPE& st, const unsigned long& val )
    {
        state = st;
        value = val;
    }

    bool operator == ( const RENDERSTATE& rhs ) const { return state == rhs.state; }
    bool operator > ( const RENDERSTATE& rhs ) const { return state > rhs.state; }
    bool operator < ( const RENDERSTATE& rhs ) const { return state < rhs.state; }
};
  
Then I store all the possible renderstates that D3D supports in a tree with some default values...
  
// RenderStates is of type Tree<RENDERSTATE>.

RenderStates.InsertNode( RENDERSTATE( D3DRS_ALPHABLENDENABLE, FALSE ) );
RenderStates.InsertNode( RENDERSTATE( D3DRS_LIGHTINGENABLE, FALSE ) );
// Same for all the render states.

  
So now I have all my render states in a tree. Then I use the tree''s search method to find a renderstate and check if it''s value is the same as the one I want to set. If it''s the same I save a call to IDirect3DDevice::SetRenderStates(). My main concern is, will all the above be worth doing just to save on a call to SetRenderState() ? Or is there (there must be) a better way of doing this? :::: [ Triple Buffer V2.0 ] ::::
[size=2]aliak.net
Advertisement
Why are you using a tree for this? I''d think an array or maybe a hash table would be more suited to the problem.

You could replace your O(lg n) search with a O(1) hash.
If you want to track and eliminate redundant renderstates, perhaps the easiest and fastest way is just an array[number of renderstates] initially set to invalid values. The array will be sparse, but it won''t take up that much memory.

A bigger question is whether eliminating redundant renderstates is worth the effort.

From what I see, most apps have a lot bigger performance problems than just setting redundant states (renderstates or otherwise).



Development Lead
Windows Graphics & Gaming Technology
Development Lead, DirectXWindows Graphics & Gaming Technology
it is. especially if you''re targetting pure devices.

*sigh* as is my custom today....search the dxdev lists for a recent dicussion of this.

http://DISCUSS.MICROSOFT.COM/archives/DIRECTXDEV.html
find / -name "your base" -exec chown -R us:us {} ;
That''s not what I said.

What I said is that on the list of optimizations people need to worry about, redundant RS is far down the list of return-on-investment for 80% (or more) of the professional apps I see.


Development Lead
Windows Graphics & Gaming Technology
Development Lead, DirectXWindows Graphics & Gaming Technology
I wasn't disagreeing with you. If he has it and it does its job GOOD, it will help if even just a little bit.

I totally agree about this being a minimal performance issue but every little bit helps.

Oh yeah, and a hast table or array would be much more sensible in this situation as has been previously reccomended.

[edited by - null_vector on May 7, 2003 9:32:23 PM]
find / -name "your base" -exec chown -R us:us {} ;
Rockin

Development Lead
Windows Graphics & Gaming Technology
Development Lead, DirectXWindows Graphics & Gaming Technology
Thanks for the replys. So saving redundant renderstates is worth it then? Im still not quite clear on that.

And yes, using an array would be much more sensible . Dunno why I didnt think of that. Thanks

:::: [ Triple Buffer V2.0 ] ::::
[size=2]aliak.net
It''s potentially a good thing to do, but there are probably better optimization and performance wins you can get.



Development Lead
Windows Graphics & Gaming Technology
Development Lead, DirectXWindows Graphics & Gaming Technology
Render states are some of the slower things you can do to the video card, because it has to stop and "change" and if you have a lot of different stuff rendered in a particularly unordered manner the more different render states you use the more potential your application has to be just plain inneficient.

It''s definitely worth optimizing render states, if your application is targeted toward rendering lots of different stuff (a game), although, as the people here have gracefully been saying is that some things are slower, and they are right: For example:

-changing large textures,
-Lock & Loading vertex buffers (fruequently)

Although people shouldn''t critisize your decision to optimize the render states, perhaps they want to remind you that you should also take a look at your other potential slow-spots.

It is definitely worth otpimizing for render state changes.

-------
Homepage: http://students.washington.edu/andrey
-------Homepage: http://www.pclx.com

This topic is closed to new replies.

Advertisement