Comments on: A Render/SamplerState Stack and Manager for XNA

By: Renaud Bédard

Renaud Bédard — Tue, 23 Feb 2010 16:29:44 +0000

I agree that a “delta” system is more efficient and probably simpler, but I wouldn’t say a state stack is entirely irrelevant.
In a hierarchical component system, it can be a useful tool. Not even render “leaf” knows or needs to know the full render state, it could only push some additions, and pop them. The upper nodes dictate the general state, the leaves work with specifics.

By: Mr Reply

Mr Reply — Tue, 23 Feb 2010 16:04:53 +0000

A stack is not relevant to render states

All that matters is:

- what are the current states
- what states do we require now

to achieve this you just need a shadow cache of the device render state and then calculate the delta

then do a write-through the shadow cache to the device

By: The Week in Code (XVII) « Sgt. Conker

The Week in Code (XVII) « Sgt. Conker — Wed, 28 Oct 2009 14:21:50 +0000

[...] A Render/SamplerState Stack and Manager for XNA Renaud introduces his KISS style state stack for the XNA FX [...]

By: The Week in Code XVII « Sgt. Conker

The Week in Code XVII « Sgt. Conker — Sun, 25 Oct 2009 22:32:16 +0000

[...] A Render/SamplerState Stack and Manager for XNA Renaud introduces his KISS style state stack for the XNA FX [...]

By: Pete

Pete — Wed, 21 Oct 2009 00:11:24 +0000

Nice article!

I’m working on a slightly different approach. Basically, every draw-call pass will have its own render state wrapper, but I won’t track changes to the initial or main state. Instead, I’ll compare the current state to the next one in the draw-call pass for changes, and thus only change what’s necessary “from current to next”.

In order to avoid cheking all render-state fields, I’ll pack them “by category” on a single value using bit-shifting. Say, all embed (almost) all booleans in one integer field. So, if two integers -the current and the next- are equal, no need for changes; but if they are different, then I check each bit to see which boolean values need to be updated.

Since I have a “material” system that controls each pass, and the latter specifies its render state, by not allowing changing render states within the shader itself -manual process though, I’ll avoid situations that force me to mark “dirty fields” and reset.

Again, great article. Thanks for sharing.