On Sat, Mar 28, 2009 at 5:41 AM, troy d. straszheim <troy@resophonic.com> wrote:
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.
You can't just design some interface and then see if someone is going to use it. You have to address the specific needs of the client. Who and why would use the fixed size matrix class? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode