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:
Fernando Cacciola wrote:
Hi Kornel,
FWIW, after all this thread I still feel that it not sufficiently clear what you propose to work on, and how do you plan to manage to apparent or actual overlap between your proposal and related projects.
So, can you TOP POST a message with summary of your proposal but with sufficient detail so potential metors can evaluate it?
Make sure to contrast that very carefully with exiting libraries and proposals, inclusing Quaternions (which already exists), Boost.SIMD, Spatial Indexes from Federico Fernandez, GTl and GLL.
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. For that purpose, all you need is the following types: struct float2 { float x, y; }; struct float3 { float x, y, z; }; struct float4 { float x, y, z, w; }; struct float22 { float a11, a12, a21, a22; }; struct float33 { float a11, a12, a13, a21, a22, a23, a31, a32, a33; }; struct float44 { float a11, a12, a13, a14, a21, a22, a23, a24, a31, a32, a33, a34, a41, a42, a43, a44; }; And a bunch of namespace-scope functions that work with them, for example: float33 matrix( float a11, float a12, float a13, float a21, float a22, float a23, float a31, float a32, float a33 ); float33 float33_zero(); float33 float33_identity(); float33 float33_row_major( float const m[3][3] ); float33 float33_col_major( float const m[3][3] ); float33 float33_row_major( float const m[9] ); float33 float33_col_major( float const m[9] ); float33 float33_rotx( float angle ); float33 float33_roty( float angle ); float33 float33_rotz( float angle ); float33 operator*( float33 const & l, float33 const & r ); .....etc..... 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. Also, if your goal is to get a wide spectrum of APIs (engines, middleware, etc.) to talk through a common (boost) game development math interface, it has to be as basic as this. Otherwise you'll run into practical issues (ABI compatibility, etc.) as well as other excuses not to support it. Regardless, I'm skeptical. Chances are, the industry simply won't adopt a common interface for this stuff, no matter what. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode