Christer Ericson

You will get the same results by interpolating the positing and then computing the light direction in the pixel shader...this is because vertex positions can be linearly interpolated. So you don't have anything to worry about.

I don't think you meant to say "same results", Matt. Interpolating the vertex positions and computing a light direction in the pixel shader will not give the same result as computing a light direction at each vertex and interpolating these vectors over the triangle. The former is correct while the latter is incorrect, in the sense of the resulting vector accurately pointing at the light source. You might say "similar results" in that interpolating the direction vectors isn't grossly inaccurate (for some definition of grossly).

Quote:

Original post by Palidine Quote: Original post by frob Although they exist and we use them on our tools, I don't know of console projects that use the STL container classes or STL streams inside their console projects. Heh.  Again it breaks down along "religious" lines.  I haven't seen a single console title that _doesn't_ use the STL.  In the 3 titles i've shipped and in the one i'm about to ship we use STL with custom allocators.

In our games:

• we need to be 100% in control of memory
  
• we want code that is cache efficient (beyond just being algorithmically efficient)
  
• we want code that is straightforward and not overengineered
  
• we want code that you can read and step through
  
• we want code that gives clear error messages
  
• etc.

In my opinion, STL, in its default form, fails to deliver on all of these.  You can fix some issues by e.g. providing STL with custom allocators but that still leaves plenty of other issues.  Furthermore, the mere fact that you have to "fix" something before it even remotely begins to conform to your required usage mode should be a cause for concern.

Some people may not care about one or more of these issues or have other needs, which is fine; that's their choice after all.  However, none of the titles I've ever worked on (all console games, except one) has used STL for the aforementioned reasons. (This refers to STL in the game; we've used STL in the tools.) For us, our decision is commonsense, not religion, but to each his own.

Finally, I take objection to your claim that "No, there is no reason to avoid the STL on console development if you know what you're doing."  That's you claiming that the team of programmers that I work with don't know what we're doing, and it's total flamebait.  I won't rise to it, but I think the games we've done speak for themselves and I'll let others judge your statement in that light.

Quote:

Original post by MichaelWeber I am looking for a good book about Fuzzy logic in games.

Few games use fuzzy logic, so there's little to go by.  Those that do, hardly stray from the "standard" fuzzy logic, so you might as well go with a standard fuzzy logic book, IMO.  I'm not an expert on what fuzzy logic books are out there, but one book I have and like is:

Reznik, Leonid. Fuzzy Controllers

It's not a traditional (and stuffy) textbook, so it's quite readable.  As the title suggests, the focus is on controllers, i.e. control units of embedded systems, so while it doesn't cover games as such, the fact that it talks about controllers makes is particularly relevant to games-like applications.  It does lack the worked examples that you'd find in a textbook, but it's not a big flaw.