2
\$\begingroup\$

I'm currently building an engine over SFML and Box2D.

The problem is that each of these use different types for things like Vector2, etc.

So to the question: is it a good idea to replace Box2D and SFML vectors with my own vector class (which is one of my better implementations)? My idea then was to have a separate .lib with all my classes that should be shared between all the projects in the solution.

\$\endgroup\$
  • 1
    \$\begingroup\$ Depends, is the current type fracturing causing problems? \$\endgroup\$ – Justin Skiles Oct 2 '12 at 15:52
4
\$\begingroup\$

That's a very good question, mismatches in utility classes (vectors, matrices or even containers) between libraries is often an overlooked issue.

I wouldn't try to modify SFML or Box2D:

  • Your own utilities classes might be missing a few features that those libraries rely on;
  • If you need to update your libs to integrate some new features or bugfixes, you'll have do re-do all that work again.

What you should do is wrap those libraries in classes of your own, so that other parts of your engine can manipulate them without "polluting" everything with external dependencies. E.g. if you need to use a function that requires a Box2D::Vector2, don't rewrite it, instead wrap it in a function that requires a hayer::Vector2:

// this is declared by Box2D
void Box2D::DoStuffWithVector2( Box2D::Vector2 foo )

// this is a wrapper function for your engine
void hayer::DoStuffWithVector2( hayer::Vector2 foo )
{
    Box2D::DoStuffWithVector2( hayer::ConvertToBox2D( foo ) );
}

You don't have to wrap everything though, just wrap what you need when you need it, iteratively. You won't need everything in the library interface, so that's the best way to limit the code size. I'd say that creating this kind of "glue code" is roughly the same amount of work than rewriting the libs, but it brings much more benefits:

  • Changing libs (e.g. from Box2D to another physics lib) will be easier, as you'll just have to modify this "glue code";
  • You'll be able to integrate new features or bugfixes from your external libs almost instantaneously.

Doing a separate .lib for your utility classes is a good idea, it'll keep a good modularity and can't do any harm. And it'll fit in that model as well.

\$\endgroup\$
  • \$\begingroup\$ After giving it some more thinkering this is(for me) obviousily the best way since I'm considering chaning out the physics engine, and renderer. \$\endgroup\$ – hayer Oct 3 '12 at 8:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.