# krippy2k8

Members

116

646 Good

• Rank
Member
1. ## Problem with orthographic projection

Grrr. I had already tried transposing the matrix and it didn't work. Somehow the Z of 0 didn't even occur to me. Transposing and using a Z of 1 works.   Thanks.
2. ## Problem with orthographic projection

Okay, so XMMatrixOrthographicOffCenterLH seems to work in a way that I don't quite understand. If I use XMMatrixOrthographicLH it works fine, or if I set the values of XMMatrixOrthographicOffCenterLH  to -300, 300, -200, 200, then it works exactly the same as XMMatrixOrthographicLH. If I set the values to 0, 600, 0, 400, I get some really funky results. I understand why the first one works the way it does, but it doesn't seem like the second one should give me the results that I am getting.
3. ## Problem with orthographic projection

Well I found that if I use D3DXMATRIX and D3DXMatrixOrthoLH instead, it works. I also have to change the vertices to use pixel values, which is what I expect, but which didn't work the other way either.   Perhaps some kind of alignment issue?
4. ## Problem with orthographic projection

So I'm looking into doing some 2D graphics with Direct3D 11. I am having a problem getting a simple orthographic projection to work right, and I am hoping that somebody can tell me what I may be doing wrong, or ideas of how to figure it out.   My vertex layout is a simple position/color layout, and the vertices are these:           {0.0f, 1.0f, 0.0f, 1.0f, 0.0f, 0.0f, 1.0f},         {1.0f, -1.0f, 0.0f, 0.0f, 1.0f, 0.0f, 1.0f},         {-1.0f, -1.0f, 0.0f, 0.0f, 0.0f, 1.0f, 1.0f}   This is my vertex shader: cbuffer cbChangesPerFrame : register( b0 ) {     matrix worldMatrix;     matrix viewMatrix;     matrix projectionMatrix; }; struct VS_Input {     float4 pos   : POSITION;      float4 color : COLOR; }; struct VS_Output {     float4 pos   : SV_POSITION;     float4 color : COLOR; }; VS_Output main( VS_Input vertex ) {     VS_Output vsOut = (VS_Output)0;     vsOut.pos = mul(vertex.pos, worldMatrix);     vsOut.pos = mul(vsOut.pos, viewMatrix);     vsOut.pos = mul(vsOut.pos, projectionMatrix);     vsOut.color = vertex.color;     return vsOut; } And this is my code to setup the constant buffer:     XMMATRIX all[3];     all[0] = XMMatrixIdentity();     all[1] = XMMatrixIdentity();     all[2] = XMMatrixOrthographicOffCenterLH( 0.0f, 600.0f, 0.0f, 400.0f, 0.1f, 100.0f );     ctx->UpdateSubresource( _constants, 0, 0, all, sizeof(XMMATRIX) * 3, 0 );     ctx->VSSetConstantBuffers( 0, 1, &_constants ); This results in a red single-pixel line being drawn from the top center of the screen, to about the center of the screen.   If I change my matrices to the following:     XMMATRIX all[3];     all[0] = XMMatrixIdentity();        all[1] = XMMatrixIdentity();     all[2] = XMMatrixIdentity(); Then the triangle renders as I expect; with one point at the top center, and the other 2 points at the bottom corners, with a red-green-blue gradient. So it would appear that the vertices are being correctly pushed to the shaders.   I have tried explicitly setting the .w position value to 1 in the vertex shader, I have tried using 4-element position values in the code, I have tried using a single matrix in the shader and multiplying them in code, and I have tried using a single matrix in the shader and just setting it to the projection matrix, all of which I figure should be the same since I'm using identity for the other 2 matrices anyway, and of course the result is the same in all cases.   What could I be missing here?   Thanks!

6. ## Multiple Inheritance vs. Composition

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.
7. ## Communicating with Programmers

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.
8. ## Still confused about "static"

[quote name='SiCrane' timestamp='1349639685' post='4987759'] 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.) [/quote] 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.
9. ## SFINAE equivalent in C#?

[quote name='Slavik81' timestamp='1349110169' post='4985793'] 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. [/quote] 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.
10. ## SFINAE equivalent in C#?

[quote name='Slavik81' timestamp='1348884726' post='4984931'] I could expect it, given that the two objects should have both identical code and data, and one has an interface that is a subset of the other. The fact that it's so difficult to use one in place of the other is just a limitation imposed by poor design choices in the C++ template system. [/quote] Actually it is the result of a powerful C++ design choice: template specializations. [quote name='Slavik81' timestamp='1348884726' post='4984931'] If it C++ disallowed atrocities like this, the types would be compatible: [CODE] struct MyObject{}; template struct MyTemplateClass { T x; }; template<> struct MyTemplateClass<const MyObject*>{}; int main() { MyObject obj; MyTemplateClass<MyObject*> i1; i1.x= &obj; MyTemplateClass<const MyObject*> i2; i2.x= &obj; // compile error } [/code] [/quote] It seems it would be a pretty silly tradeoff to disallow template specializations in order to allow implicit template type conversions, particularly when the solution to your original problem is so simple: [CODE] template<typename ContainerT> void function(const ContainerT&){} [/CODE]