Digital Confectioners Team Blog

About a week or so, I was discussing about how I was pretty happy with Hexlo’s new component system. Unfortunately, as most designs go … this design didn’t quite work out that well.

The problem came when I had to do rather complex systems such as compound meshes. A mesh contains vertex data which define position data, texture coordinate data and color data; triangle data which define which triplets of vertices form each triangle and a texture id. Compound meshes are just when you have multiple meshes together. The reason why you need compound meshes is when you have meshes that require more than a single texture.

Why this became a problem was because the amount of data that was having to be transferred between the component, then to the register became very large per frame. This reduced my frame rate to a crawl. The system works wonderfully when you have small amounts of data which was the case for components such as sprites, lines and points, but once the components became very complex it became exponentially harder.

I had already predicted that data duplication would happen with this design, but I did under estimate the magnitude of that.

The other problem with this component design had to do with caching. Because components had to stay very generic, there was no way for them to store specific data for OpenGL or DirectX. Because OpenGL and DirectX manage and store objects such as textures differently to each other, I had to write a generic system in which then both OpenGL and DirectX would then override to implement their own specific methods. While this worked reasonably well to an extent, the worst case scenario had never been simulated. Since I would need to do look ups per frame, I can imagine that once I start hitting a certain number of objects on the screen it would probably slow the game down quite considerably.

So with those in mind, it’s back to the drawing board I think. I know the component system is achievable, but perhaps I am looking at this the wrong way.

I don’t believe I have announced Hexlo on this blog yet, but never the less it is one of the games that I am writing at the moment. The important aspect about Hexlo is that it mainly serves as my highly experimental projects in which I inject a lot of my new experimental methods into. I find it a little easier to inject new methodologies into projects like this because of their scale. Anyways, in Hexlo I wanted to rethink about my component system again.

A component system is one where entities in the world has a list of components which then define how that entities looks like, sounds like, behaves like and so forth. For example, for a rocket entity you may have a mesh component which renders a rocket projectile mesh onto the screen, a sound component which plays back a “fssssssssh!” sound during the rocket’s flight and perhaps a script component which contains the logic for when the rocket contacts something. Component systems like this are designed for the end user in mind. It also helps code reusability and extending current classes rather than having to copy/paste sections of code for different classes that aren’t able to extend similar classes.

My first initial stab at a component system involved using a lot of RTTI (Run Time Type Information) which was functional at the time but certainly an unsafe method of doing things. It is unsafe to me, because you assume a few things. For example, consider:

if (component_ptr->GetType() == Enum_Mesh_Component)
  ((MeshComponent*)component_ptr)->RenderMesh();

You assume a few things with this sort of code. First, you assume that GetType() will always return the correct value for each class definition you write.

• What happens if you forget to override the virtual function in your child class? Make it abstract you say?
• What happens if you return a conflicting identifier to another class?
• What happens if component_ptr is a child class of a child class of Component?

And lastly, your code will be littered with gigantic switch and if statements that may get out of control. Lastly, you simply assume that component_ptr is going to be MeshComponent. If it isn’t, then it is going to explode as you try to access a function from a class that doesn’t actually have it. There is simply no real fail-safe methods here. I suppose you may interject and suggest that I could have used dynamic_cast<> to provide fail safe methods. The main problem with using dynamic_cast<> is that it is rather slow in relative measures.

Certainly when everything is written correctly, everything would be fine. But that’s like saying that a program will never have bugs in it because everything will be written correctly.

My second attempt at a component system involved interfaces. This assumed that every component is just a component and that typing was unnecessary. The base class, Component, would essentially have a large list of virtual functions that were setters and getters for everything imaginable. While this was very fail-safe and anything error related was able to be caught during compile time, the base class became very bloated with one off virtual functions that would eventually create such a large virtual table for these classes that the amount of memory used per class would be huge. For example:

class Component
{
  virtual void Set(const unsigned int &id, const int &in)  { };
  virtual void Set(const unsigned int &id, const float &in) { };
  virtual void Set(const unsigned int &id, const short &in) { };
};

As you can imagine, not every component would require all of these virtual functions but they would still incur the penalty of having them within their virtual tables. I couldn’t make these into abstract functions because then every component would need to implement them anyways making every child class simple massive.

So with Hexlo, I wanted to avoid that sort of a setup because I knew it would be a horrible system to work with. While it was very safe, it was memory hogging and too bloated to be usable. So when I thought about it some more, I realized that most of the time it was the entities themselves that often needed to alter the properties of their own components. So with that in mind, since the owners of these class instances were the entities themselves, keeping a private pointer reference to the component would be fine. End users would also not have to care too much about the memory management of these pointers, since a pointer list would manage these class instances.

class Entity
{
public:
  void AddMesh()
  {
    m_mesh_component_ptr = new MeshComponent();
    m_components_ptr.push_back(m_mesh_component_ptr)
  };

private:
  std::vector<Component*> m_components;
  MeshComponent *m_mesh_component_ptr;
};

So, with that using m_mesh_component_ptr is used when the class itself wants to change any parameters within it, but I would suspect that the majority of the time this isn’t really required at all. So that’s nothing special just yet, but in this particular case, let’s use this within a rendering scenario.

class Viewport()
{
public:
  void Render(MeshComponent &mesh_component);
};

class Component()
{
public:
  void Render()
  {
    InternalRender();
  };

private:
  virtual void InternalRender() = 0;
};

class MeshComponent : public Component()
{
  virtual void InternalRender()
  {
    GetViewport().Render(*this);
  };
};

*GetViewport() returns the Viewport class instance as a reference

This sort of structure pretty much resolves most of the issues I came across with the top two methods. I don’t have huge banks of virtual functions that hardly ever get used by many child classes, I don’t require RTTI since C++ itself handles typing and it’s pretty darn fail safe at most areas. The only potential problem that could possible happen is that the amount of function calls that is required could be a little on the excessive side causing potential problems but I haven’t come across this yet in Hexlo. The only other ‘problem’ is that you have to write quite a lot of virtual functions within Viewport for all of the different component types you have. However, I don’t think that’s any different to having to write the actual rendering functions for handling the component anyways.

I’m feeling pretty good about this method right now. But perhaps in a few weeks, I might come up with an even better solution!