Re: [boost] boost::directx?

Subject: Re: [boost] boost::directx?
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-06-09 11:50:54

On Jun 9, 2009, at 7:19 AM, Christian Schladetsch wrote:

> Hi Carlos,
>
> Just to pick out one point:
>
> - Direct3D shaders and OpenGL ones have different, incompatible  
> approaches
>> (D3D knows no shader linking for example)
>
>
> I have a system that shows you that DX does indeed allow for shader  
> linkage,
> with an ANTLR (not Spirit!, sorry, but that's just silly and doesnt  
> suport
> AST or output string templates) grammar to back it up.
>
> Point being that it is silly to try and virtualise or abstract-away  
> hardware
> functionality on a display-card-level.
>
> We are going to be yelled-at by the powers-that-be for speaking about
> non-C++ issues, and correctly.

Not necessarily. This gives us insight into the intricacies of lower- 
level API's and the problem of either abstracting or picking out  
commonalities, for a (more proper) Boost proposal. A lot of people  
here are interested in graphics, and graphics programming, both 3D and  
2D. This is shown by the acceptance of Boost.GIL. And, we have  
discussed a UI library for ages. *If* somebody would provide an API  
for both DirectX and OpenGL with at least hooks proper for UI, well,  
you could have yourself a winner :-)

I heard you regarding the hardship of abstracting both these API's.  
But, that is not exactly what you would have to do if you use a lot of  
meta tricks, which you apparently are not afraid of. I.e., use  
policies, bound at compile-time, which differ between DirectX and  
OpenGL. I.e., do not try to create a common abstraction of all the  
features, but a common interface to the common features, at a high  
level, and then let various policies do the real work. There would be  
no need for those dreaded runtime conversions back and forth that  
Ogre3D does all the time. (A third i.e.,:) view your library as three  
things:

1. a high level framework for what *is* indeed common between at least  
DirectX and OpenGL, but preferably for any 3D rendering API (Ogre3D  
could serve as one of the inspirations for that kind of abstraction)

2 concrete and inline implementations of policies for DirectX

3. concrete and inline implementations of policies for OpenGL

Anyway, you get a lot of response to your enquiry/plead. That is good,  
and I am almost a bit jealous ;-) Maybe I should propose a more  
pragmatic Boost.Ruby next timeinstead of dusty, theoretical "hierarchy  
injection" libraries :-)

/David