Thanks for the reply, Hodgman. Memcpy does seem to work on non-POD types in this case. I'm interested in the alternate design you suggested using composition rather than inheritance. That looks like it work quite well for one level of inheritance, but I'm not sure about how you would extend this to multiple levels of inheritance. For this renderer design, I think you might need two levels of inheritance -- you mentioned that State inherits from Command, and then, in my understanding, you have multiple render-state structs derived from State. Would you just do something like this?

struct Command {
   u8 id;
};

struct State {
    Command baseClass;
    // other members...
};

struct BindShader {
    State baseClass;
    Shader* shader;
};

For this renderer design, I think you might need two levels of inheritance -- you mentioned that State inherits from Command, and then, in my understanding, you have multiple render-state structs derived from State. Would you just do something like this?

I'm pretty sure you just need a single level of inheritance

If you have a Command struct:

struct Command
{
        u8 id;
};

You can have as many commands structs as you need:

struct BindVSCommand
{
     Command cmd;
     VertexShader* pVS;
};

struct BindVSTexture0Command
{     Command cmd;
     Texture* pTexture;
};

struct BindVSTexture1Command
{
     Command cmd;
     Texture* pTexture;
};

In your State struct you don't need any other members so you can remove that structure.

In my renderer (which follows many of Hodgman ideas) I don't even use a command struct so no need for inheritance.

I simply store an int before each Command struct in the CommandGroup blob (in this topic called StateGroup).

When executing CommandGroups I get the int from the blob switch on it to the appropriate command based on it.

CommandGroup cmdGroup;

for(int i = 0; i < cmdGroup.numCommands; i++)
{
    int cmdID = cmdGroup.blob.next<int>();

    switch(cmdID)
    {
        case(BIND_VERTEX_SHADER):
            BindVertexShaderCommand cmd = cmdGroup.blob.next<BindVertexShaderCommand>();
            //all kinds of state check etc
            executeCommand(cmdID, cmd);
            break;
        //all other commands
    }
}

To Hodgman: is there any perfomance penalty in using template functions?

[quote name='TiagoCosta' timestamp='1358025244' post='5020848']
I'm pretty sure you just need a single level of inheritance
[/quote]

You're right, it does look like a single level of inheritance would be fine. I was wondering about the purpose of the State struct, as I can't think of what data members it would have.

About templates (sorry, not Hodgman!): I'm pretty sure templates are a purely compile-time feature, so it shouldn't have too much of a runtime-performance penalty. However, melbow has a good point: templates often do increase the size of the compiled code. I think there probably wouldn't be much benefit if you implemented exactly the same thing but without using templates (e.g. just copying and pasting your classes/structs/functions and changing the variable types). Templated functions could possibly cause cache-misses if the compiler hasn't placed the code for both implementations nearby. In your example, if the instructions for next<int> and next<BindVertexShaderCommand> aren't nearby, this might cause an i-cache miss. However, this only applies if they're not inlined, so if they are inlined, you should be fine. I've only started learning about how caches work recently, though, so someone should correct me if I'm wrong.

Yeah you could do this with a single level of inheritance. I do use two levels like you demonstrated, IncidentRay, but State (and DrawCall) don't have any other members.
I only have this second layer of inheritance so that elsewhere in the API I can say that StateGroups contain States (which are just Commands) and SubMeshes/RenderItems contain DrawCalls (which are also just Commands). It just ensures that the user can't put a DrawCall-derived command in a StateGroup, nor use a State-derived command to represent geometry in a SubMesh, without generating a compile-time error.

Moving the errors to compile time is definitely a good thing. So then the RenderItem struct can have a pointer to a DrawCall rather than just a pointer to a Command. I'm not quite sure how it would work for the state-group, however. I was thinking of having a StateGroup struct which actually just stores the header -- i.e. the number of states, the size in bytes, etc. Then the actual commands would be allocated contiguously after the header. For example,

struct StateGroup {
    u8 numStates;
    u32 sizeInBytes;
};

void Foo(StateGroup* group)
{
    State* states = (State*)((u8*)group + sizeof(StateGroup));
}

I can't see a way to stop the user from putting DrawCalls in the state group. Do you implement StateGroups differently, or is there something I'm missing?

If two different template functions happen to produce the same assembly code (e.g. vector and vector are likely exactly the same at the asm level) then your compile times will suffer, as the compiler will generate the same code multiple times, but then a modern linker will remove/merge the duplicates.
On old compilers (nothing you'll be using these days), the linker wouldn't perform this step, so if you had many different vector (with different T's) you'd end up with a ton of identical functions in your final executable... This is one reason why game developers didn't used to like using templates or the STL.

Yeah, I forgot that linkers can do that; thanks for the reminder. TiagoCosta's use of templates is probably completely fine then.

EDIT: This editor seems to keep messing up the angle brackets for templates, so I can't get the quote above right.

[quote name='Hodgman' timestamp='1358051934' post='5020960']
If you're going for memory efficiency, be aware of your compiler's padding behaviour when designing your header structures
[/quote]

Yeah, that StateGroup struct was just a quick example; I'd definitely worry about padding in real code.

[quote name='Hodgman' timestamp='1358051934' post='5020960']
e.g. I put state-groups directly in my engine's model, material and technique files
[/quote]

Putting the state groups in resources files is an intriguing idea. How do you deal with pointers in this case, as obviously they will have different values each time you run the engine? I suppose you could store some other data in the pointer field, and then fix the pointers at runtime -- e.g. maybe a hash of a filename. Or do you do something else?

[quote name='Hodgman' timestamp='1358051934' post='5020960']

I do pretty much the same thing that you've thought of here, except I also put a bitfield in the header, with one bit for each type of state.
[/quote]

Your recommendation of storing a state bitfield sounds good -- that looks like it would be quite useful. As I understand it, the bitfield can be used to quickly check whether a state group can be totally ignored, but if not, the next step is to check each state individually?

Thanks for the detailed example of how you might generate state groups; that answers several questions I had.