Postie

Unless there's some matrix multiplication order difference between OpenGL and DirectX I'm not aware of, the construction of your MVP matrix seems backwards. Shouldn't it be mModel * mView * mProjection?

 

Similarly, to construct your mModel matrix, I believe the order of transforms should be (SRT) Scaling, Rotation, Translation. 

A bad programmer is unwilling to learn and develop their craft. An inexperienced programmer is new to the craft. These are not the same.

 

I disagree with the mentality that you should be an expert in your field before offering advice or tutorials. Sharing information, (even small snippets) to help others get started is a key way of distributing knowledge in communities. Though, if you're going to offer advice, its your responsibility to amend that information if you discover it is wrong or "not the done thing".

 

Trying to teach other people what you know (especially through some sort of peer-reviewed process), is the surest way of finding out what you *really* know about a topic, as opposed to what you *think* you know.

 

I cannot fault the OP's attempts to pass information on. Even experts get started by reading someone else's tutorials.

Remember that games studios are still businesses at the end of the day, and unless you're in some ridiculous high rent location and have token staff, the biggest cost by a long margin is going to be people's salaries.

Take a look at the middle section of the periodic table of elements. You'll find metals like Iron, Cobalt, Nickel, Tungsten, Mercury, as well as radioactive ones like Uranium, Plutonium...

 

Also, don't neglect your alloys. You don't dig them out of the ground as ore, but they can exist as ingots. Bronze and steel were already mentioned, but there's a lot more out there.

 

You've called the 3rd parameter passed to D3DXIntersect, "rayTo", which worries me slightly. The 3rd parameter is actually the direction of the ray, which is a vector, not a point in space. If rayTo is actually a point, you'll need to pass in (rayTo - rayFrom).

 

Also, you shouldn't need to scan through the faces after the initial test, the output value in pFaceIndex should contain the index of the face hit, if D3DXIntersect returns a hit.

Nice code, but did you have a question?

Hey guys,

So I'm a few years into my part-time game project and have been learning HLSL and DirectX as I go. I'm pretty confident in my ability to write HLSL shaders to do pretty much everything I need currently but have a question about the general architecture of shaders and how they should fit together.

For example, I have a terrain shader that handles some funky texture, tile-based lighting stuff and shadow mapping as well as some special effects, like highlighting an individual tile or drawing some special construction lines.

I also have an entity shader that I use for all the objects in my game and can also do Blinn-Phong shading.

I also have many other specific use shaders, such as a water shader, a fire shader.. etc etc...

I've realised that I now want to add the shadow mapping code to the entity shader, as I originally only implemented it in the terrain shader. But then it occurred to me that I'll probably want that feature in some of the other shaders down the track.

So my first question is, should I be implementing a given feature (eg shadow mapping) multiple times for every shader that needs it, or should I be trying to create a "it-does-everything" shader? And as a follow up, could I be writing my shaders to be more modular? I'm currently not using the ability to have multiple techniques or passes as I don't follow how they should be used.

Yeah, the after transformation positions aren't right at all. I'm not sure how multiplying by the orthogonal matrix to get the texels has worked for you in the past. I recommend using the technique described by Auskennfuchs. Just be aware that if in future you use a non-square texture, you'll have to use width and height as divisors, not size.

In my opinion its more important to know that other data structures and algorithms exist, and that using an array (or a list) will normally work, but there are often data structures much better for the task at hand. The trick is recognising those situations.

Be aware of data structures, but you don't need to go around implementing them until you actually have a use for it.

I like to think of creativity as thinking without boundaries. John Cleese did a good talk about the topic that you might consider checking out:

That said, in regard to your meeting, it sounds like the other 3 were on the same page about the idea, but it wasn't really your thing? I wouldn't call that a "lack of creativity", it's more a "lack of passion for the idea". One of the others probably should have done the idea development and it sounds like a cop out to say you're not creative and then kick you out to be honest.

Having written a loader for the 3ds format I heartily recommend avoiding it if possible. It's an old format with limitations that might cause you problems over a newer format.

For example: 1) All filenames are in 8.3 format, and saving a .max file into .3ds normally truncates the filenames if they are longer than 8.3, which can lead to loss of data if you have a prefix. (Learnt that one the hard way).
2) The maximum number of vertices per object is 65536, which might be a problem depending on how high resolution your meshes are.

My current project uses .obj files because they are easy to parse, pretty much every modeller can save them, and I'm still early in development. Pretty soon I'll have to start using a format with more features such as collada, since .obj doesn't support bones or keyframes etc. But my plan is to convert the collada files into my own format during a resource build phase as others have suggested.

I'm struggling to follow your reasoning as to why you have to look backwards to determine the cost of the path going forwards. If your weights are done correctly, getting to node D includes the cost of getting to any of the previous nodes that made up the path. Unless your movement along the terrain can cause a landslide that affects the path ahead I don't follow your line of thinking.

Are your weights taking into account the full cost of traversing the node, such as slope, softness of terrain etc or are they just taking into account the distance?

Your problem is likely when you convert your mouse position to your integer multiples of 32.

For values greater than 0, doing (int)value/32  will work ok. But for values less than 0 it will be a problem. For example, if value is -16, the division will give you -0.5, which is rounded down to 0. So all values between -31 and +31 will map to 0. What you really need is to use the floor() function instead of casting it as an int, this will cause -0.5 to be rounded to -1, which is correct.

Part of knowing what an equation means is recognising the notation and knowing what each of the symbols stands for. You don't necessarily have to be a calculus wizard to read and then implement an equation. The part where it gets difficult (and requires formal maths knowledge) is proper understanding of the equation and then taking that knowledge and extending it or adapting it for another purpose.

Also, I'm surprised no one has mentioned trigonometry. Even in 2D its used an awful lot.

Two months invested in something which is possibly going to be discontinued at some point in the future is hardly something to be concerned about. From two perspectives:

1) Two months in the grand scheme of things isn't very much time. After two months of intense study you're still barely scratching the surface.
2) In computer science every new thing is built on something old. Language syntax and API's may become obsolete, but the core concepts of programming and the skills associated with them don't. API knowledge isn't the mark of a good programmer, anyone can use google.

A related anecdote: 15 years ago the only programming languages I knew were C and QuickBASIC. I started a new job using visual basic. After 3 years I moved to a new job where the language of choice was Delphi. And then more recently I took up C#. I don't consider anything I learnt in any of the previous languages a wasted effort, even though arguably C, BASIC, Visual Basic and Delphi are "dead" - in terms of new project uptake. I'm a far better (and more adaptable) programmer now for having taken the journey through all those languages than if I've stuck with just one thing for 15 years.