Alundra, on 11 Apr 2014 - 03:04 AM, said:
On a renderer it's nice to have RenderState class with static variables + Init() to avoid Renderer.cpp of 4000 lines.

That doesn't follow. Nothing about static variables makes the rest of your code smaller. You've got a false equivalency going on here.

I was not clean on this view, but L. Spiro said the reason after.

It's to have a class who store all render state object needed for the render static to avoid to have monster function call with 10 parameters.

And one Init() in RenderState class to avoid Renderer Init() function to be large code.

But I have to say that I don't allow external render state, for example I have that in Material :

enum TBlendMode
{
  BM_OPAQUE   = 0, //!< Opaque blend mode.
  BM_ADDITIVE = 1, //!< Additive blend mode.
  BM_ALPHA    = 2  //!< Alpha blend mode.
};

ID3D11BlendState* m_OpaqueBlendState; //!< Opaque blend state.
ID3D11BlendState* m_AlphaBlendState; //!< Alpha blend state.
ID3D11BlendState* m_AdditiveBlendState; //!< Additive blend state.
ID3D11BlendState* m_AdditiveSrcAlphaBlendState; //!< AdditiveSrcAlpha blend state.

But it's not just that, it has too :

ID3D11DepthStencilState* m_DisabledDepthStencilState; //!< Disabled depth stencil state.
ID3D11DepthStencilState* m_LessEqualDepthStencilState; //!< Less-Equal depth stencil state.

ID3D11RasterizerState* m_NoneCullRasterizerState; //!< NoneCull rasterizer state.
ID3D11RasterizerState* m_ClockWiseCullRasterizerState; //!< ClockWiseCull rasterizer state.
ID3D11RasterizerState* m_CounterClockWiseCullRasterizerState; //!< CounterClockWiseCull rasterizer state.

ID3D11SamplerState* m_ClampLinearSamplerState; //!< ClampLinear sampler state.
ID3D11SamplerState* m_RepeatLinearSamplerState; //!< RepeatLinear sampler state.
ID3D11SamplerState* m_ClampPointSamplerState; //!< ClampPoint sampler state.
ID3D11SamplerState* m_RepeatPointSamplerState; //!< RepeatPoint sampler state.

I have a list of Vertex/Pixel/Hull/Geometry/Compute shader as well but inside renderer actually, but I would change to avoid monster params function call.

All that combined to give that : http://uppix.com/f-GameD3D11_135347f06e001605d7.png

The probleme is to have renderer cleaned about clustered renderer/shadow mapping.

CASE 1



test.h

extern int x;
void foo(void);

test.c

int x;
void foo(void) { x = 1; }

main.c

#include "test.h"
int main(void)
{
foo(); /* ok */
x = 6; /* ok */
return 0;
}

x and foo() are both visible in external modules.

But in this case if you were to declare x as static within test.c you could could redclare it in main and it would be a different variable.

Static is not a replacement for private in C. Declaring and defining them only in the .C file is.

Don't they need to be declared static inside the .C file so that they only visible from within that compilation unit.

No, each compilation unit is compiled individually, a variable has to be declared as extern to become accessible across compilation units.

If you declare and define the variable in global scope in the .C file, it's implicitly static anyway.

If you DON'T declare it static AND you DON'T declare it extern either BUT you have two variables in two C files both called x AND both files are in the same linker unit you WILL get a linker error because the linker WILL see them as the same object in global scope even though you haven't declared either of them extern. If you declare both variables as static then you will not get a linker error.

Alvaro got there before me.

As a side note, the actual use of C-style static in global space has really been replaced by anonymous namespaces now and static in global space in C++ is really only for backwards compatibility with legacy C code as far as I'm aware. I prefer anonymous namespaces because its too easy to forget to add static to the front of a new definition but easy to remember to include it in the namespace.

I don't use much, if any, static global state but I tend to put implementation functions in anonymous namespaces to avoid accidental linking and name clashes.