Emil Dotchevski wrote:
On Fri, Mar 27, 2009 at 2:37 PM, Kornel Kisielewicz <kornel.kisielewicz@gmail.com> wrote:
On Fri, Mar 27, 2009 at 9:33 PM, troy d. straszheim <troy@resophonic.com> wrote:
One thing boost doesn't have is a fixed-size matrix class, which could be used with boost::array as a building block for a lot of the more game-specific tech involved. Seems to me a boost::matrix class (essentially a 2d boost::array) would be of reasonable scope/difficulty for a GSOC project. If there's time left over, one could investigate making optimized rotations, dot projects, reflections and the like as freestanding functions/operators in a special namespace somewhere. And this is definitively what I'd also like to do. As it seems an important topic, I'd make it the base of my proposal.
A 2D boost array is an overkill for a boost matrix class. In fact the whole point of a game-developer-centric matrix/vector support is to make the types simple and to the point.
Well I'd like to stop talking about games, I don't think we're getting anywhere. We're trying to find a project that fits into boost somewhere and is of appropriate scope for GSOC. I still maintain that a fixed-size matrix class could be one. This has a well-defined scope and a good chance of success. But maybe somebody can argue that we shouldn't have a fixed-size matrix class? If the student later uses in game code and finds out it isn't exactly what he wants, fine.
For any other application, you'd need a more generic and more abstract interface, but such interface will just get in the way for game development.
Let's talk about those. How about interface = "basically the same as boost::array?". -t