Jump to content
  • Advertisement
Sign in to follow this  
jbates

The Tuesday C++ Math and Template Library

This topic is 1132 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi GameDev.net!

I've been working on a math and template library on and off since January and it's gotten to a point where I'm comfortable sharing it.

 

https://github.com/Cincinesh/tue

 

The Tuesday C++ Math and Template Library ("Tuesday" for short) is a library of template classes and math functions with a focus on physics and graphics applications. It provides data types commonly used in games and other simulations such as vectors, quaternions, and matrices, operator overloads for combining and manipulating these types, as well as some other common mathematical functions. It was written to match the style of the C++ Standard Library and uses modern C++ features (i.e., C++14) extensively.

 

There's also some initial work on SIMD data types which exist as a conventient wrapper around not-so-friendly SIMD intrinsics (SSE bool32x4 and float32x4 only so far). It's written in such a way that you could easily have vectors or matricies of SIMD types (or any other type that has mathematical operators).

 

It's licensed under the Boost Software License so it's should be free to use in just about any project.

 

Please take a look and let me know what you think!

Share this post


Link to post
Share on other sites
Advertisement
You have an interesting naming convention for your projects. What happens when you have more than seven? :D

I've only glanced at it so far; what is the thing you think sets your library apart from others, such as GLM or CML?

Share this post


Link to post
Share on other sites

Haha, yeah, I felt pretty clever. It started with incrementing every letter in the name of the "std" namespace (s->t, t->u, d-e), and I decided to go from there. I'm planning to use the remaining days of the week only for really generic libraries, e.g., the types you'd find in the Standard Library or Boost, and I don't think I'll ever write more than 7.

I don't know anything about CML but here's some differences from GLM as I remember it:

  1. Different vec sizes are specializations of the single vec<T, N> template declaration. Same thing with mat<T, C, R> and simd<T, N>. This makes it possible to write template functions that operate on any size.
  2. It makes heavy use of decltype and auto return types. This makes it possible to write vec<T, N> and mat<T, C, R> operators with implicit type promotion, e.g. fvec3 + dvec3 results in a dvec3 just as float + double results in a double.
  3. It makes heavy use of constexpr. It's not all that useful in Visual Studio yet (VS2015 is lagging behind a little in this regard), but Clang and GCC can reap the benefits.
  4. simd<T, N> types and vec<T, N> types are totally separate. It may seem counter-intuitive to some, but SIMD vectors aren't all that useful as traditional 3D vectors. SIMD instructions are more useful when operating on totally independet things at the same time. For example, vec3<float32x4> would be used to perform the same math on four logically separate fvec3's in-parallel. Also, the simd<T, N> types make it intentionally difficult to access individual components, since this is a slow operation in most SIMD instruction sets.

There are probably others, but these are the big ones that come to mind immediately. I'll add something like this to my README. Thanks for asking.

Edited by Jo Bates

Share this post


Link to post
Share on other sites

It generally seems to do what it says on the tin, which is good. There's nothing particularly glaringly bad or anything.

 

The oddest thing for me is your choice to implement operators like unary increment and decrement, bitwise XOR, shifts and the like for vectors as component-wise operations. These significantly increase the API surface area you need to test and maintain (although they are otherwise harmless), and are vanishingly rare in practical applications in my experience. I could see a rationale for including them for integer vector (as-in-SIMD) types, but as you note those are distinct entities in your library. But in the general case they just seem to be included "for consistency," and I'm generally a fan of the "less is more" approach to API design.

 

To that end, though, the intentional difficulty in access to SIMD components is a good idea (as is your separation of those types in general from the non-SIMD types).

 

----

 

Unrelated: while I didn't look that hard, your Monday unit testing library does not seem to handle trapping tests that *crash*, only those that throw exceptions or fail through your assertion mechanism. You can do this via structured exception handling on Windows and signal handling (sigaction, sigsetjmp, siglongjmp) on Unix/Linux/Mac OS. It's pretty useful and something you may want to consider adding in the future.

Edited by Josh Petrie

Share this post


Link to post
Share on other sites

I'm big on uniformity when it comes to template libraries. If I'm implementing half the operators, why not just do them all? I agree they'll probably never be used, and usually less is more, but the overhead in implementing and maintaining them seems worth the effort in this case to me, especially considering their implementations and tests are almost identical to the corresponding arithmetic operators.

 

And thanks for the crashing test handler suggestions! I'll put it on my todo list.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!