Boring but important?

Screenshot of some Mat44 algorithm timings, because it's 0300 and I've only been working on the math library.

libhel 0.1.0
That 'boring but important' math library libhel has been getting a little love lately. I'm currently polishing up a unit test and profiling suite for it now. Not a whole lot has been reimplemented / refactored, yet much of the new design for optimization and correctness is already in place. I'll likely be pruning out more and more classes and functions before I commit to svn. This library just collected junk from my other projects and it's easily the most buggy code in the project. The best way to fix this is to reinstate the unit / regression test on build policy. Oh I know... "boo hoo my builds will take to long". You don't rebuild the math library that often, and incorrect math just leads to a snowball effect. I've already found and fixed several issues this far along. I may keep various similar algorithms in place for performance tweaking at higher levels.

Some items of note:

• API / ABI will break big time
  
• Proper 'hel' namespace and C exports
• Cleaner math type system
• Optimization!
• Physics system update
• Multiple choices for some algorithms
  

libfreyja/freyja
Libfreyja is designed for threading, so major speed improvements and new features will be coming along with the new backend. The CPU skinning/deforming/list ops/physics used in libfreyja is easy to parallelize so far. The problem of user thread tuning for certain machines will come up I expect -- tools and config options will be there. I have planned out several stages for bringing existing and new physics support from libhel to freyja, but I don't have any new details I care to share right now. I'm mostly focused on libhel at the moment. Then it's time to get FK more usable and IK animation released. Freyja itself needs an event overhaul, but nothing is scheduled for the next release as of now. At this point I think it'll be better to hold off. I have a network report/update and some other 'low hanging fruit' on the table as well. You could think of these as development 'mini-games' I could add in an hour or so with testing. Once these are out of the way it's back to a plugin and a new physics development focus. Phasing in physics support will start with the end of the libhel refactor/rewrite.

MSTL
MSTL is also getting some minor updates along with libhel, which are mainly for threading and higher precision stopwatches and timers. This only works on Linux and UNIX builds right now. I currently plan to use Windows native threads, however all other platforms use pthreads and there is a WIN32 pthreads port. If it ends up saving more time and effort and there isn't a huge performace difference that will change.

libmgtk
The library libmgtk is going to stay stable for a while so no changes for now. I looked into doing a C# port again, however OpenGL support crossplatform is still a failing point. All I really want is a Gtk# or Forms widget with an OpenGL context that works at least as well as my current one used in C++. Sadly it's still orders easier to implement a portable Gtk+ framework and use that for widgets and GL context. Also I don't think projects like Tao even support OS X last I checked.

OS X builds you say? Yes, I recovered my OS X Tiger VM, but I can't really do any development on it due to various issues. If you're thinking of throwing away our old mac mini or the like -- give it to me instead, so I can have a stable OS X platform and release some binaries.