Re: [boost] boost::directx?

Subject: Re: [boost] boost::directx?
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-06-09 00:52:28

On Jun 9, 2009, at 12:30 AM, Christian Schladetsch wrote:

> Some have asked what sort of thing would be in the proposed library.
>
> I put together a quick demo of the sort of thing I would like to see  
> in a
> boost::directx library, and it's in the vault at
> http://www.boostpro.com/vault/index.php?action=downloadfile&filename=make_vertex.zip&directory=&
> .
>
> This would be quite obscure to those without DX experience, but I will
> explain it in more detail to clarify my motives and goal. This is  
> just a
> single piece, but I'll go into some detail to demonstrate the sort  
> of things
> that I think would be helpful in boost::directx.

Ok, I could be a target for such a library, although it should not be  
*part* of Boost, just because it uses Boost. Being a DirectX developer  
(both Managed and native, but not XNA insofar...) now and then and a  
Boost fanatic, it could suit me.

> In DirectX (and any other low-level graphics system), there is a  
> need to
> reflect the vertex types. Typically, users will do something like  
> this:
>
> struct MyVertex
> {
>    float3 position;
>    float2 texture[2];
>    float3 normal;
> };
>
> VertexDescriptor MyVertexDesc[] =
> {
>   { SEMANTIC_POSITION, TYPE_FLOAT3, 0, 8 },
>   { SEMANTIC_TEXTURE, TYPE_FLOAT2, 12, 20 },
>   { SEMANTIC_NORMAL, TYPE_FLOAT3, 0, 24 },
>   { SEMANTIC_NONE, TYPE_END },
> };
>
> The descriptor is required to inform the hardware about both the  
> syntax and
> the semantics of your vertex layout.
>
> Clearly, the way this is currently done is error-prone. The vertex  
> layout is
> not type-related to the vertex description. This causes a lot of  
> problems,
> most obviously when they get out of sync, but even creating them at  
> all is a
> royal pain. And you need to do this sort of thing a lot these days  
> in modern
> renderers.
>
> The system in my proposal unites the two requirements:
>
>    using namespace boost::directx;
>    typedef make_vertex<vertex::Position<>, vertex::Normal<>,
> vertex::Texture<2> > MyVertex;
>    MyVertex vert;
>    vert.position = float3(1,2,3);
>    vert.texture[0] = float2(1,2);
>    vert.texture[1] = float2(3,4);
>    vert.normal = float3(4,5,6);
>    vertex::declaration decl = MyVertex::make_decl();

Hmm, some of these notions are at least cross-API for the specific  
domain of rendering library, and if you could implement them on top of  
either OpenGL or Ogre3D, you might stand a slightly greater chance of  
getting Boosters to nod their heads. Still unlikely, though,  
considering the fact I exposed that only two libraries insofar are  
outside language enhancements and general scientific computing: GIL  
(which is where you could fetch inspiration) and Python.

> This solves a real problem faced by DirectX developers every day. It  
> uses
> 'advanced' techniques, and is a demonstration of how to use
> boost::mpl::fold, and how type-traits are used to map C++ types to
> enumerated values.

That is pretty cool. Quite a bit of a hurdle to get DirectX developers  
to embrace MPL, I think, but I would love for you to succeed in that.

> Is it domain-specific? Yes, it is specific to the area of "attempt  
> at best
> practises for creating vertex types for DirectX applications in C++".
> Similarly, one assumes that boost.graph is specific to the area of  
> "best
> practises for creating and using graphs in C++".

Sort of, but the application of graphs is quite ubiquitous in complex  
problems and has nothing to do with any specific domain and, even  
worse, with a specific API for a specific target platform (the great  
Windows family.)

> I don't want to quabble over fine distinctions, but if a requirement  
> is that
> a library must be shown two work on two platforms, DirectX works on  
> the
> following platforms: Xbox360, Zune, and various Windows varieties (XP,
> Vista, Windows 7). I am unsure of the status of DirectX under WINE.  
> For what
> it's worth, it is also supported on the  Dreamcast which is not a MS
> product. Of course, you also can't buy one these days but I digress.

If something does not work on OS X, Windows (family...), Linux and at  
least most Unixes, it will have a hard time getting people's attention  
here, in my continuously humble opinion.

And, the "requirement" of a library working on two platforms is not  
sufficient per se. See above, and previous e-mail: only Boost.GIL is  
really domain-specific *outside* of scientific computing in the Boost  
libraries. And, great attention has been given to making it as cross- 
platform as possible.

> There are many other areas in the day-to-day life of a DirectX C++  
> developer
> that could be addressed with some "best-practise" attention.

I agree, and also wish that the regular COM developer would follow  
similar best practices. At least ATL is a tiny first step in that  
direction, and if you could provide a library and documentation to  
make them think more Boostish, that is a great win.

> Inclusion of
> those systems within boost would be beneficial to the DirectX and C++
> communities that use it, and make boost more relevant to the  
> requirements of
> performance-oriented C++ developers.

Yeah? I think it would make Boost less focused on core techniques and  
definitely steer it toward being a Bag Of Goodies, which I sometimes  
fear when just counting the number of libraries (90...)

I think your idea is great and that you should put the library up  
there somewhere, but still fail to see the benefit for you, and that  
library, to have this part of Boost and definitely view it as a  
hypothetical huge digression of the ideal of Boost.

/David