krippy2k8

Basically, no you can't do what you want. Though I admit I can not say that I am 100% of certain of that (though I AM sure that you can't do it all), I am pretty sure. Some food for thought, some of which will answer some of your questions, and some of which may be useful to help you in your quest if you continue to pursue it:

1) It's DWM (Desktop Window Manager) not WDM. Not being pedantic, just thought it might help your searches if you use the right terminology ;)

2) When you setup a swap chain in Direct3D windows mode, DirectX coordinates with DWM to provide the surface that you are rendering to, which is the DWM surface. This is a video memory surface that is owned by DWM.exe but which is shared across process boundaries by virtue of the WDDM (Windows Display Driver Model). When you Present, the DWM is notified that the surface is "dirty" so it can be recomposited on the primary surface.

3) Preserving the alpha values would not help you do what you want anyway, because you don't have control of the shaders that are used when compositing your window on the primary surface.

Personally I would argue that both approaches are bad practice for an entity system. An entity in a pure entity system should neither "be" nor "contain" a collection of components, it is merely an identifier that is used to associate components with each other. All of your components (which should just be data) should be stored in a database that is keyed by the entity identifier, then your various systems query the database for the required components. Using an entity class that contains the components makes it difficult to obtain the performance advantages of a pure entity system.

That being said, given only your 2 choices I would definitely go with composition. If anything just inherit from NetworkObject. It seems conceivable to me that NetworkObjects can also be property containers and also be serializable. If they are not already that is a big potential design complication that could raise it's head in the future.

An entity system by it's very nature is supposed to be all about composition and avoiding the rigidity of OOP, so making the system itself so heavily dependent on inheritance seems pretty backwards to me.

Generally speaking I think the bigger concern is the other way around. As a programmer who has spent many a day dealing with artists, the biggest barriers to communication have been when I didn't understand the content creation process well enough and was unable to effectively communicate the necessary constraints or requirements, or fully understand the implications of such from their perspective.

So I got myself a subscription to Digital Tutors and spent a couple of months learning what I could about developing game assets with Max, Maya, ZBrush and MotionBuilder, and typically now I spend at least a couple days a month doing the same, and the communication has become much, much easier.

This is probably not something that every programmer will be able to or want to do, but as somebody else mentioned, there should be one guy on the programming team that can act as liasion between the technical and artistic sides, and it would be a good idea for that person to have a reasonable understanding of the content creation process.

Am I the only one seeing the C# tag on this thread? (This is not a rhetorical question, I'm severely confused by the number of C++ specific responses here.)

There is no C# "prefix" so I guess most people - like me - don't really look at the tags and just assume that every question is C++ unless the OP mentions another language in their question, especially when the topic is something that is essentially the same in most languages anyway.

That would be a reasonable solution if it did not have such a dramatic impact on compilation time, and if it did not require major workarounds to apply to virtual functions.

There are definite advantages to the restrictions C# imposes on its generics.

That should have little impact on compile times. Certainly not "dramatic."

And yes, there are definite advantages to the restrictions C# imposes on it's generics. There are also definite disadvantages. A major design focus behind C# is in fact compile times and convenience, whereas C++ focuses more on flexibility and run-time performance. Template specialization is a big part of that. It's certainly not a design flaw. And the workarounds you're talking about in regards to virtual functions are typically only necessary if you use questionable design choices in your own code from the perspective of C++, with modern C++ absolutely favoring generics and generic algorithms over inheritance and virtual functions, especially when it comes to operating on template types.