Screenshots using FileNamer

Member Initialization Lists

#

Initializing members using the special syntax. Called “member initializer lists.”

class FileNamer {
  int index;
  std::string basePath;
  std::string prefix;
  std::string extension;

public:
  FileNamer(std::string basePath, std::string prefix, std::string extension) :
  basePath(basePath),
  prefix(prefix),
  extension(extension),
  index(getInitialIndex()) {}
}

There is a bug in the code above. Thankfully, I’d read enough about member initializer lists yesterday to know the problem immediately. getInitialIndex() depends on the values of basePath, prefix, and extension. However, these values will be initialized _after_ getInitialIndex() is called because of the order of the definition of the parameters on lines 2-5. The solution is to move int index to the bottom like so:

class FileNamer {
  std::string basePath;
  std::string prefix;
  std::string extension;
  int index;

  ...

This causes the path, prefix, and extension to be initialized first and then the index. This has something to do with maintaining a consistent order in which members are created and destroyed.

Member Initialization Lists are More Efficient

#

Side note: if you don’t use member initializer lists then the member is initialized with a default constructor, then initialized again in the constructor.

Member initialization:

Foo(int n) : bar(n) {}

Member assignment:

Foo(int n) {
  bar = n;
}

which is actually equivalent to:

Foo(int n) : bar() {
  bar = n;
}

Record Animations

#

For now I’m still saving each frame as a PNG which I need to convert into GIF images and then combine into an animation. Might try to include that in the class in the future but for now I just added the ability to capture 1 in every X frames to speed things up a bit. Another one for the future is saving to disk on a separate thread so the simulation doesn’t hang until it completes.

I also added a little arrow to each boid to indicate which direction it’s facing. I’ve implemented it using a transform (sf::Transformable) for the entire boid. That way I can add antennae or legs or what have you and have them all move and rotate with the rest of the boid.

I think next step is to have two antennae at the front of the boid which will detect food sources separately. Then I can tie each one to a neuron … maybe I’m overcomplicating it. I can have one neuron represent the distance to the food source and another represent the directional angle to the food source. Positive could be clockwise and negative counter clockwise. I guess that’d make it a little less obvious what the weights of the neurons are actually doing..?

With two antennae detecting food sources from different positions it will give a direction (although it’ll probably mess up when the food source is behind) and the weights will be really obvious. If the left antenna detects food activate the right propeller more and vice versa.

I guess since I called the project “BraitenBoids” I might as well implement it that way to see what it’s like. Then I can experiment with using distance and rotation neurons instead of activation levels of antennae.

There’s a question for the propellers, too. How do I translate left and right propellers to speed and rotation?