Benchmark results

PyEigen is still fastest by far, which is promising. This time it was about 5-10x faster than cgkit1, which was again the second fastest. You might also notice that vectypes is missing. For this test, it was so slow that I had to leave it out; other results would have been invisible if I had fitted the vectypes results in the graph. In the worst case, it was over 1000x slower than PyEigen! Euclid is missing addition and scalar multiplication scores since it doesn’t support those operations. NumPy performed much better. There has to be a faster way to do vector cross product in NumPy, since matrix multiplication was much faster than cross product. But it’s not a big deal anymore since PyEiglet is so much faster than anything else.

Benchmark results

The immediately obvious surprise is the abysmal performance of NumPy especially in cross products. I don’t think NumPy optimizes for fixed-size arrays; I would have been better off with the pure-Python euclid and vectypes modules.

The other surprises were euclid vs vectypes and cgkit1 vs cgkit2. Euclid and vectypes are both by Alex Holkner of Pyglet fame. In both cases, the newer library (vectypes and cgkit2) was also slower.

Of course the most positive surprise for me was the performance of PyEigen. It’s only a trivial wrapping, but was about 2-8x faster than the best alternative, cgkit1. I’m very happy with the results and definitely going to continue development of the library / wrapper.

Update: Here’s the benchmark code. Also an interesting detail: PyEigen is 136x faster than NumPy with cross products.

The whole thing started when I profiled my shooter project and found that matrix calculations take up a huge amount of time. Apparently NumPy isn’t really fast enough for 3D games, and I couldn’t find any replacements. While otherwise looking good, euclid and vectypes are pure Python so they aren’t going to make performance any better. cgkit is C++ with a Python wrapper so looking better already, but… it’s using Boost.Python, which apparently isn’t very fast. Also, it’s lacking SSE instrumentation and other optimizations included in Eigen. So I decided to wrap Eigen.

As I already found out, Boost.Python is slow and looked too complex for such a simple library anyway. I tried Cython next, but its C++ support is (still) very limited and the lack of support for C++ references destroyed any hope of wrapping Eigen, which relies heavily on them. My final option before resorting to manual wrapping using the Python C API was SWIG, but I had problems getting even a simple wrapper to compile. Besides, I don’t really like how SWIG generates function wrappers and a separate Python module that calls those wrappers instead of generating a Python C module directly.

So I was left with only the final option: Python C API. I feared it at first because I’ve never worked with it and it seemed really complex. It is complex, but not nearly as bad as I though, especially as Eigen has such a simple API. For Bullet, I’m sure I’ll use Cython or some other wrapper generator, but for Eigen the Python C API is just fine.

Anyway, since there doesn’t seem to be anything like this out there, I decided to make it an open source project so hopefully other people in the same situation won’t have to jump through the same hoops as I did. I’ll post progress reports, releases and especially benchmarks against the other options as soon as I have them.

As for Artillery Brawl, the code became a mess and destroyed my motivation to continue the project, which is why I started the new game to begin with. I might start Artillery Brawl again based on this new codebase, but for now I’m working on the shooter.

I hope to write more about the new project and its progress again in the near future, but in the meantime, the best way to follow the project is my Twitter feed.

I should be hearing about the job next week.

If you want to check out the demo and some old stuff of mine, see http://www.brainfold.org/portfolio/. I’m releasing the code in public domain, but check copyright.txt for the font copyright. Apart from the demo, my time has been spent preparing for the move to Helsinki on Wednesday, so again, don’t expect any real updates for at least a week or two.

Anyway, about next week… I have a job interview at a game company (wish me luck!) and I’ll be moving back to Helsinki where I used to live four years ago before I moved here to Tampere. I also have a couple of deadlines looming for university courses, so I’ll be quite busy for the next week or two! At least I already have internet connection at the new apartment, so my connection to civilization won’t be severed. See you in a couple of weeks!

The bad news is, I don’t have a job anymore (yay for the economic situation).

I didn’t just freeze and panic though; instead, I called a friend at a game company I was applying to for the summer, and told I might be available for work a bit earlier after all… I hope to hear more from them next week, so wish me luck!

As for other news, I have been working on Artillery Brawl a lot, though still no particle effects… I think they might be cursed, since every time I get close to implementing them, I run into problems or some other thing I just have to fix. Anyway, the good thing about this is that the entity system and a lot of the code in general is starting to look really good and reusable. This is how I should have approached building a reusable codebase to begin with; writing a game, then generalizing the solutions that work.

Any number of triggers and payloads can be attached to entities. For now, they will only be used for projectiles (artillery shells), but later they could be used for many other gameplay applications. Triggers can react to collisions, height from ground, proximity to units, or they could activate after a delay. Almost anything is possible, really, but I’m starting with just collision triggers. Payloads are triggered, well, by triggers; they are the “meat” of the projectile system. Again, I’m starting simple with just kinetic (contact damage based on mass, velocity and an armor piercing multiplier) and explosive (yay, particle effects and shrapnel projectiles) payload, but almost anything would be possible. For example, it would be easy to make a cluster bomb that explodes above ground (height trigger attached to directed explosive payload) into many small bomblets (individual projectiles with contact triggers attached to explosive payloads).

More on the triggers and payloads when I get the system implemented.