October 2002:

• Search GDA mailing list archives with this or this or this(if you use the second link, you have to replace "quaternion" with your own search query, you can link words with "+").
• There was an interesting discussion on the sweng gamedev mailing list about a C++ guru of the week article. What the article said was that writing class external functions that use only the class' public interface improve encapsultation and prevent the class from becoming a monolith. There were a lot of pros and cons discussed on the list, anyway I think the idea is pretty good.

July 2002:

• For stuff like 3D object input, correct texture display and so on that can't be covered by automatic unit tests I recommend writing visual unit tests. I use this term for a small application, that displays all features you want to check (e.g. a textured quad, an imported .obj file and so on) and you can go through those features by pressing a key. Thus you have a quick way of deciding whether you've broken something or not.

June 2002:

• I've done a little reading on template expressions. They enable you to write a math library that doesn't generate temporary objects when you write A = B*C*D*E (A, B,... being matrices). This works by generating temporary template classes that store the references to the matrices and the evaluation method for an expression at compile time and then evaluate the whole expresion at once during runtime. For an example click here.
• Not really a tip, but I got mentioned in this sofware pattern paper - after an email exchange on the subject - by J. Coplien who is a really good software designer and did a lot of groundbreaking work in patterns.

January 2002:

Some books I've read and would recommend:

• C++ and OO design:
  • Meyers: "Effective C++", "Even More Effective C++", "Effective STL". (Really good for getting a deeper understanding into C++ which is a quite overwhelming language for a beginner. The STL title does the same for using the STL, since proper usage of this library is no easy task. The books are structured around a collection of rules and are also quite entertaining to read)
  • Gamma and others: "Design Patterns". (A must read for everyone interested in object oriented design. It introduces into the wide field of design patterns, which can be described as design templates that apply to a variety of problems.)
  • Alexandrescu: "Modern C++ Design". (Gives examples for template usage I bet most people will have never thought about. He also implements design patterns using templates, so that you get a reusable pattern library. You'll see templates in a completely diferent way after reading this book).
  • Riel: "Object Oriented Design Heuristics". (Presents a list of dos and don'ts for OO design in a Scott Meyer's like way).
  • Herb Sutter: "Exceptional C++" (A collection of "C++ puzzles" and their solutions. This will definitely broaden your C++ horizon).
  • Langer, Kreft: "Standard C++ IOStreams and Locales". (The only book I know of that treats this topic in detail. If you want to know anything about the C++ concept of streams, you'll find it here).
  • Stroustroup: "The C++ Programming Language". (Well, the standard book for C++. I actually haven't read it as a whole, but use it as a reference everytime I have a question about any language feature. If you can't find the answer there then your last resort is the ISO/ANSI C++ standard).
• 3D graphics:
  • Papers: Siggraph, Nvidia, ATI, and many other sites on the internet provide a vast resource of 3D knowledge.
  • Eberly: "3D Game Engine Design" (A book that describes the design principles behind the NetImmerse and Magic Software engines. It's IMHO not so good for learning about engine design, but quite a good collection of several 3D algorithms and has plenty of source code on the accompanying CD).
  • Möller, Haines: "Real-Time Rendering" (A very good book with information about a variety of aspects of real time 3D graphics).
• Game programming:
  • Various authors: "Game Programming Gems" (A collection of different articles concerning a broad spectrum of game programming topics. Some are more useful than others, but that's to be expected by such a book. All in all it's a very good book for people interested in game programming).
  • "Game Programming Gems 2"
  • GD-Algporithms mailing list: Recommended for everyone into game programming. A lot of interesting topics are discussed there.

June 28th 2001:

• Ever wanted to use a function pointer to a virtual member function that calls the correct member function depending on the runtime type of a passed pointer/reference? (This might come in handy, if you want to traverse a tree or list of objects that holds pointers to a base class and you want to call a virtual function that you can specify at runtime.) Here is an example how this can be done.

June 9th 2001:

• Use inline functions as little as possible during development. You don't need the performance gain by inline functions when you are developing software, but you easily get annoyed by recompilation due to changes in their implementation (it is always easy to later inline them, when it makes sense to do so). The only exception is of course when working with templates.

June 7th 2001

• Refactoring is good (the book "Refactoring" by Martin Fowler influenced the way I work a lot): It gives you freedom to do rapid development, because you can always change code later.
  (Refactoring is a process that deals with controlled changing of existing code to improve its design).
  
• Don't try to arrive at the best possible design before you implement. You'll never achieve that. Just try to get a reasonable design.
  
• Never start implementing without a design at all. I tried that, but it didn't work out.
  
• Don't try to be too open for later demands and changes. Though an open design is good, trying to foresee all features possibly needed in the future distracts from the essential. You can always refactor later.
  
• Only put functions into an interface, that you actually use. Some of my interfaces might seem rather incomplete, but the point for me is, that less functions generate less "noise". So every member in a class I have is used somewhere.
  
• Use templates as little as possible (at least with MSVisualC++). Though they are a powerful design instrument, they always caused me trouble and headaches when compiling more complex constructs. So I only use them, when I absolutely must. (Revision: I'm not so sure about that anymore. It should be rather: Use templates with care. Complex template structures might cause problems with different compilers, because compiler support is not mature enough yet).
  
• Write unit tests!!!! I started writing them, after reading the refactoring book. Now I rarely have to debug. (E.g. after I've added hierarchical bounding volume culling, the engine got a lot slower. So I optimised a lot of Math-code. Having unit tests I always knew, when something broke). You don't have to write unit tests for every feature. But in "Refactoring" they say: "having a few tests, is better than having none at all."
  (Unit tests are test functions that test a classes functionality automatically, where the emphasis is on automatically. Like that it is easy to spot changes that caused older code to stop working. Look at the code for details)
  
• Never write long functions. I try to keep functions at about 10-20 lines. This also reduced debugging for me a lot, because I think that is the size every person can grasp with a single glance without having to check, what is going on.
  
• Refactor your code always, so that it is in a clean state. If you look at the repository-history, then you'll see, that e.g. my Mesh class has completely changed from what it was in the beginning. I started with a Mesh, that was modeled after the DirectXMesh class (because I didn't know better) and ended up with something completely different (more like in the Magic Engine from Dave Eberly). So I never tried to continue working with a design, where I had a bad feeling, but I always refactored it until I thought, that the design is OK. This is quite a lot of work, when doing it, but is worth it, because the rest of the code using it becomes easier to understand.
  
• I sometimes write the code using a class (or many classes) before I design it. Thus I know which member functions I'll need in the public interface and also assure, that the design is comfortable to use.

ABOUT
DOWNLOAD
DIARY
FEATURES
TIPS
SCREENSHOTS