Hello, Is there a possibility of making submissions that use meta-C++ to assist with writing DirectX-based code? Obviously, DirectX is Microsoft-specific (but not necessarily platform specific!). So my question comes down to "is there a space in boost for MS-specific systems"? Perhaps in boost::microsoft or boost::directx or boost::microsoft::directx. I have a number of systems that are generally useful, and would like to support the use of boost in game development. It is hard enough to get gamedevs to use STL, let alone boost. But for example, creating vertex declarations is a royal PITA and can be assisted with some deft use of boost::mpl. Plus, we are already using boost::shared_ptr<> to make com_ptr<>, but it could be made more obvious and a lot of people don't know how to use it. There are two ways of looking at it. First, boost is about C++ and not about supporting specific API's. Fair enough - but then there are many boost libraries that use system-specific idioms such as threads and lock-free containers. It could be argued that boost doesn't want to tie itself to a proprietary API which itself will be versioned and modified externally to boost, but the same is already true in a lot of what boost does. Another way of looking at it is that boost is here to be used by real people solving real problems. In this case, it seems that there is room within a new namespace for domain-specific boost libraries. I realise this is a can of worms. What do you think? Should boost be more egalitarian and increase its possible audiance, or is introducing a dependancy on a 3rd party proprietary API an anathema to boost? Regards, Christian. ----- http://www.linkedin.com/in/christianschladetsch
Make this some kind of boost::graphics, target both dx and ogl or w/e in a seamless fashion, then you have something worthy. I'm not a fan to have boostified version of 3rd party things. What's netx, boost::qt ? -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
There are examples of boost+ogl+gui+ggl: https://svn.boost.org/svn/boost/sandbox-branches/andreo/guigl https://svn.boost.org/svn/boost/sandbox/guigl -- Regards, Andrey
I am referring to systems that are explicitly designed to assist with creation of DirectX-based applications. I am not interested, and nor are many other people, in (re-)virtualising virtual hardware. On Sun, Jun 7, 2009 at 9:07 PM, joel <joel.falcou@lri.fr> wrote:
Make this some kind of boost::graphics, target both dx and ogl or w/e in a seamless fashion, then you have something worthy.
I'm not a fan to have boostified version of 3rd party things. What's netx, boost::qt ?
-- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
joel wrote:
Make this some kind of boost::graphics, target both dx and ogl or w/e in a seamless fashion, then you have something worthy.
This is commonly found in 3D graphics engines. However, a low level ogl/dx abstraction is time-consuming, and ultimately not worth it, because both APIs, while roughly equal, differ in many details, which sums up in a low-level abstraction that covers the lowest common denominator. It is better to abstract in a higher semantic level, however this is hard to accomplish as a general 3D rendering library (and probably not very useful, since rendering applications vary wildly in their feature requirements and applied techniques). In short, even then we don't even have something useful for boost.
Hi Carlos, On Tue, Jun 9, 2009 at 8:59 PM, Carlos Rafael Giani < e0325834@student.tuwien.ac.at> wrote:
joel wrote:
Make this some kind of boost::graphics, target both dx and ogl or w/e in a seamless fashion, then you have something worthy.
This is commonly found in 3D graphics engines. However, a low level ogl/dx abstraction is time-consuming, and ultimately not worth it, because both APIs, while roughly equal, differ in many details, which sums up in a low-level abstraction that covers the lowest common denominator. It is better to abstract in a higher semantic level, however this is hard to accomplish as a general 3D rendering library (and probably not very useful, since rendering applications vary wildly in their feature requirements and applied techniques).
I have repeatedly stated my belief that it is futile, if not insane, to attempt to make a system that uses either DirectX or OpenGL. That is the reason that I explicitly suggested boost::directx, rather than boost::killmenow.
In short, even then we don't even have something useful for boost.
Perhaps. I only wished to raise the issue and provide some demo code. What happens after that is up to the boost community. Regards, Christian.
Hi Christian,
I have repeatedly stated my belief that it is futile, if not insane, to attempt to make a system that uses either DirectX or OpenGL.
That is the reason that I explicitly suggested boost::directx, rather than boost::killmenow.
My apologies if you understood this as being targeted against you. I was strictly commenting joel's remark. No offense.
In short, even then we don't even have something useful for boost.
Perhaps. I only wished to raise the issue and provide some demo code. What happens after that is up to the boost community.
Yes, indeed. This is what this thread is about. As for the actual thread topic, you have a flaw in your logic. Many people use WinAPI. Should boost include a WinAPI library? Many people use Qt for their C++ GUIs. Should boost include Qt support? Etc. Your proposal, while intriguing, is very domain specific. No problem there, which boost library isn't? However, the domain here is a library tied to a few platforms (PC, XBox360) instead of language constructs (lambda, phoenix, fusion), common tasks such as parsing (Xpressive, Spirit, regex), common functionality (bind, any, signals/signals2, threads)... At first glance, Boost.Python breaks this pattern. However, Python is a freely available language, and Boost.Python concerns itself with the *language* Python, not with a specific Python interpreter or similar. I strongly suggest you do the same as Adobe did (stlab.adobe.com). They have their own open source libraries. Many of them are very useful. Out of this codebase, GIL was added to Boost. Perhaps your library yields at least a subset that can be added to Boost. But for now, "let it grow". Regards, Carlos
Hi Carlos,
I strongly suggest you do the same as Adobe did (stlab.adobe.com).
I am a fan of Stepanov, who is behind the Adobe systems. I take your advice on-board, but I am just a guy. Making a site, positing some code, getting it used etc is a huge task; time-consuming, and expensive. Boost is/was a `platform` where you could get solid code sold. I know how it works. And sure, perhaps I will make my own libs and website and do all that, in the hope that it will be adopted. But as stated previously, I am not naive and I know that the shortest path to wide adoption is via boost. Does that mean that I am using boost? Sure, but everyone that ever contributed did so because they felt it was the best distribution path. If DirectX doesn't get introduced to boost, then of course I will try other methods. The code at Adobe is awesome, I agree. And it sets a good example for an alternative to boost that uses boost and STL and yet is not a 'part of' boost, that is also true. But that is also Adobe, with Stepanov. I am just a guy, so it makes sense for me to try boost first. Regards, Christian. --- http://www.linkedin.com/in/christianschladetsch
On Jun 9, 2009, at 6:10 AM, Christian Schladetsch wrote:
Hi Carlos,
I strongly suggest you do the same as Adobe did (stlab.adobe.com).
I am a fan of Stepanov, who is behind the Adobe systems.
I take your advice on-board, but I am just a guy. Making a site, positing some code, getting it used etc is a huge task; time-consuming, and expensive.
Upload it to GitHub, make a few Wiki pages there, promote it in fora. It is not hard to promote it to Boosters if you use Boost extensively, which you do. A lot of us would back an MPLish effort at cleaning up the minds of DirectX developers ;-) Create a blog, make a few entries about other API's and DirectX development., Then, Shabam!, your new helper library is revealed there, with two short samples showing the benefits, and a link to the GitHub repository.
Boost is/was a `platform` where you could get solid code sold. I know how it works. And sure, perhaps I will make my own libs and website and do all that, in the hope that it will be adopted.
Yes, please do!
But as stated previously, I am not naive and I know that the shortest path to wide adoption is via boost. Does that mean that I am using boost? Sure, but everyone that ever contributed did so because they felt it was the best distribution path.
I do not think that is the case. I.e., I do not think that most people "just" view it as a "code market." They see that their proposal is aligned with the (stated and implicit) goals and ideal of Boost and complements specific existing libraries well Some contributors might even just want to "complete the picture" without really thinking about the optimal distribution strategy for their proposal. I did so with two libraries that, in spite of hitting the core of extending the C++ language, received the massive response of utter and complete silence ;-) I did so for the love of the ideal behind Boost, for the kind of succinctness and expressivity I would love to see from younger and more pragmatic resume-gathering developers.., PS: I will promote my helper libraries on my own :-)
If DirectX doesn't get introduced to boost, then of course I will try other methods. The code at Adobe is awesome, I agree. And it sets a good example for an alternative to boost that uses boost and STL and yet is not a 'part of' boost, that is also true.
But that is also Adobe, with Stepanov. I am just a guy, so it makes sense for me to try boost first.
Stepanov is also just a guy. :-) And, it is not completely unlikely that you might get Boosters who do code for DirectX behind your effort quite early. /David
On Jun 9, 2009, at 5:47 AM, Carlos Rafael Giani wrote:
Hi Christian,
I have repeatedly stated my belief that it is futile, if not insane, to attempt to make a system that uses either DirectX or OpenGL. That is the reason that I explicitly suggested boost::directx, rather than boost::killmenow.
My apologies if you understood this as being targeted against you. I was strictly commenting joel's remark. No offense.
In short, even then we don't even have something useful for boost. Perhaps. I only wished to raise the issue and provide some demo code. What happens after that is up to the boost community.
Yes, indeed. This is what this thread is about.
As for the actual thread topic, you have a flaw in your logic. Many people use WinAPI. Should boost include a WinAPI library? Many people use Qt for their C++ GUIs. Should boost include Qt support? Etc.
Your proposal, while intriguing, is very domain specific.
Actually, there is a problem there. Both w.r.t. the (expressed and implicit) goals of Boost and...
No problem there, which boost library isn't?
... as I showed, very few are. In fact, there is only one library that is domain-specific outside the domain of Scientific Computing, and that is GIL.
However, the domain here is a library tied to a few platforms (PC, XBox360) instead of language constructs (lambda, phoenix, fusion), common tasks such as parsing (Xpressive, Spirit, regex), common functionality (bind, any, signals/signals2, threads)... At first glance, Boost.Python breaks this pattern. However, Python is a freely available language, and Boost.Python concerns itself with the *language* Python, not with a specific Python interpreter or similar.
Nope, but it is definitely an outcast, and, as I said, I would not encourage anyone today to push for similar library, say Boost.Ruby...
I strongly suggest you do the same as Adobe did (stlab.adobe.com). They have their own open source libraries. Many of them are very useful. Out of this codebase, GIL was added to Boost. Perhaps your library yields at least a subset that can be added to Boost. But for now, "let it grow".
Terrific idea. /David
David Bergman wrote:
No problem there, which boost library isn't?
... as I showed, very few are. In fact, there is only one library that is domain-specific outside the domain of Scientific Computing, and that is GIL.
Yes, I found your comment after posting, unfortunately. It then occurred to me that "domain" was the wrong word. "Category" is better. As in: higher order programming, system abstraction etc. (in fact, just like the grouping already present on the Boost page).
On Tue, Jun 9, 2009 at 4:15 AM, Christian Schladetsch < christian.schladetsch@gmail.com> wrote:
Hi Carlos,
On Tue, Jun 9, 2009 at 8:59 PM, Carlos Rafael Giani < e0325834@student.tuwien.ac.at> wrote:
joel wrote:
Make this some kind of boost::graphics, target both dx and ogl or w/e in a seamless fashion, then you have something worthy.
This is commonly found in 3D graphics engines. However, a low level ogl/dx abstraction is time-consuming, and ultimately not worth it, because both APIs, while roughly equal, differ in many details, which sums up in a low-level abstraction that covers the lowest common denominator. It is better to abstract in a higher semantic level, however this is hard to accomplish as a general 3D rendering library (and probably not very useful, since rendering applications vary wildly in their feature requirements and applied techniques).
I have repeatedly stated my belief that it is futile, if not insane, to attempt to make a system that uses either DirectX or OpenGL.
Definitely not futile. Insane, maybe. Alot of commercial 3d graphics engines support both (or at least they used to). A lot of games support both. Even if these games / engines simply implement two completely separate engines with a switch statement to choose between them, there still must be some common interface. I also don't think that such a library would need to be complete, or even almost complete. Just allowing basic 3d functionality in a cross platform manner would be enough to warrant serious consideration. And just think, once it _is_ in Boost, with minimal opengl support and minimal directx support, a bunch of other developers would likely jump on board and do a lot of the things you don't want to do.
This is commonly found in 3D graphics engines. However, a low level ogl/dx abstraction is time-consuming, and ultimately not worth it, because both APIs, while roughly equal, differ in many details, which sums up in a low-level abstraction that covers the lowest common denominator. It is better to abstract in a higher semantic level, however this is hard to accomplish as a general 3D rendering library (and probably not very useful, since rendering applications vary wildly in their feature requirements and applied techniques). I know the problem for having stumbled upon it a few times. But I don't
Carlos Rafael Giani wrote: this as undoable as you may think. For me, ti's the same order of magnitude as boost.thread internals. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
Hi Joel, For me, ti's the same [complexity to make a common graphics layer for DX and
OGL] order of magnitude as boost.thread internals.
That simply isn't true, unfortunately. DirectX and OpenGL have different abstractions for the same hardware, and what's worse is that the hardware itself is changing even faster than the API's that access it. That is far different to the API's that deal with threads. To make matters worse, OpenGL is a few generations behind DirectX (sorry, but it's true), and the gap is only increasing with Geometry Shaders. The reality is that DirectX provides the best API to use hardware, OpenGL wont and can't compete at that level because unlike DirectX, OpenGL is not driving the hardware industry. Regards, Christian.
Christian Schladetsch wrote:
That simply isn't true, unfortunately. DirectX and OpenGL have different abstractions for the same hardware, and what's worse is that the hardware itself is changing even faster than the API's that access it.
That is far different to the API's that deal with threads. To make matters worse, OpenGL is a few generations behind DirectX (sorry, but it's true), and the gap is only increasing with Geometry Shaders.
The reality is that DirectX provides the best API to use hardware, OpenGL wont and can't compete at that level because unlike DirectX, OpenGL is not driving the hardware industry.
Wasn't that stuff like Ogre3d do somehow. That's ages i didn't dip into these so take this question as a real naive one for the sake of the argument. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
Hello,
Wasn't that stuff like Ogre3d do somehow. That's ages i didn't dip into these so take this question as a real naive one for the sake of the argument.
Yes there are systems like Ogre3D. They provide abstraction. As does SDL and others. But, the abstractions provided are not on a professional level. They are slow, the require conversion to and from what would otherwise be the same thing, and in general, these 3rd party systems are just... hokey. My original post was about the idea of providing support to developers that use DirectX and C++ to make performant applications. There exist libraries that abstract away DirectX or OpenGL. They are a different thing. Regards, Christian.
joel wrote:
Christian Schladetsch wrote:
That simply isn't true, unfortunately. DirectX and OpenGL have different abstractions for the same hardware, and what's worse is that the hardware itself is changing even faster than the API's that access it.
That is far different to the API's that deal with threads. To make matters worse, OpenGL is a few generations behind DirectX (sorry, but it's true), and the gap is only increasing with Geometry Shaders.
The reality is that DirectX provides the best API to use hardware, OpenGL wont and can't compete at that level because unlike DirectX, OpenGL is not driving the hardware industry.
Wasn't that stuff like Ogre3d do somehow. That's ages i didn't dip into these so take this question as a real naive one for the sake of the argument.
Examples are: - pixel formats supported by one API but not by the other (Direct3D: YUV textures, OpenGL: latc compression, at least I'm not aware of a D3D equivalent) - buffers: OpenGL Buffer Objects and Direct3D Buffers work differently, and allow for different semantics - render-to-texture differs significantly between the two (OpenGL FBOs allow have many more features than their D3D equivalents) - Direct3D10 unifies all types of buffers, OpenGL 3 doesnt - Render-To-Texture in D3D understands (0,0) as being the upper left corner, in D3D it is the lower left one - Direct3D shaders and OpenGL ones have different, incompatible approaches (D3D knows no shader linking for example) - Direct3D uses vertex declarations, OpenGL uses pointers (which actually are offsets when buffer objects are used) .... This is a small excerpt of the differences. There are more subtle ones, such as locking flags for memory mapping allowing more fine-grained data transfers in D3D. The problem is that the only feasible way is a lowest common denominator, both in terms of features and performance. To use the graphics hardware best, you must use API specific functions. regards carlos
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. Regards, Christian.
Christian Schladetsch wrote:
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
Wrong. or output string templates Wrong again. Please don't spread misinformation. ) grammar to back it up. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
I guess I am winning at not making friends. I don't want to get into an argument about ANTLR vs. Spirit. One is easier to use than the other. One has better errors than the other. One is faster than the other. Which is which, is up to you. Regards, Christian.
Christian Schladetsch wrote:
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.
The information you're posting about Spirit is plain wrong. Spirit supports both, AST creation during parsing and template based generation of character (byte) streams. Please don't write about things you don't know. Regards Hartmut
Hi Marmot,
The information you're posting about Spirit is plain wrong. Spirit supports both, AST creation during parsing and template based generation of character (byte) streams.
It is not true that Spirit has the same functionalty as ANTLR+StringTemplate Please don't write about things you don't know. I know full well of what I speak about. Indeed. Spirit does not have the same functionality that StringTemplate does. Regards, Christian.
Christian Schladetsch schrieb am Dienstag 09 Juni 2009 um 15:26:
Hi Maik,
To what version of spirit are you refer to, 1.x or 2.x?
Unless either version uses a runtime interpreter, it doesn't matter.
Regardless of having a "runtime interpreter"... What I get from your answer is you are not a user of either version, especially not spirit2.x which provides what you talked about. As Hartmut and Joel pointed out, do not spread false information about things you don't use/know. Christian, an attitude like yours is poison for a community. If you continue to attack before arguing you'll most likely not place any code, no matter how good it is. --Maik
Hi Maik, What I get from your answer is you are not a user of either version,
especially not spirit2.x which provides what you talked about.
I tried to use Spirit in 2002. I tried again in 2003, and 2005. In 2004 I found ANTLR. It solved my problems and gave me some half-decent errors. Spirit is not the be-all-end-all of parsers, just because it is clever. There is a lot to making a language-creation system, and being clever about it is just a part of it. Spirit is not the final answer to language tools. Sorry that I am not towing the party line, but someone has to say it. Using Spirit is hard and there are other systems that are better, for different metrics of "better". As Hartmut and Joel pointed out, do not spread false information about
things you don't use/know.
Also, don't claim authority from perceived experience. I know precisely of what I speak about. Have you ever tried to use ANTLR?
Christian, an attitude like yours is poison for a community. If you continue to attack before arguing you'll most likely not place any code, no matter how good it is.
Common threats like that show more poorly on you than on me. People will use what is best suited to a task; if that means DirectX, or ANTLR, or a monotonic allocator, that is up to them. I am not daunted by your perceived superiority, and I am not daunted by the "gods" on boost. Rather, I believe that what is better will win out in the end.
--Maik
Christian
Christian Schladetsch schrieb am Dienstag 09 Juni 2009 um 16:02: [stuff I don't care about any longer] Good luck Chuck, --Maik
Christian Schladetsch wrote:
Hi Maik,
What I get from your answer is you are not a user of either version,
especially not spirit2.x which provides what you talked about.
I tried to use Spirit in 2002. I tried again in 2003, and 2005. In 2004 I found ANTLR. It solved my problems and gave me some half-decent errors.
Spirit is not the be-all-end-all of parsers, just because it is clever. There is a lot to making a language-creation system, and being clever about it is just a part of it. Spirit is not the final answer to language tools.
Sorry that I am not towing the party line, but someone has to say it. Using Spirit is hard and there are other systems that are better, for different metrics of "better".
As Hartmut and Joel pointed out, do not spread false information about
things you don't use/know.
Also, don't claim authority from perceived experience. I know precisely of what I speak about.
Have you ever tried to use ANTLR?
I have. And I have a high respect for PCCTS/ANTLR. I've known Terrence Parr since the 90s and PCCTS was/is a major influence (among other parsers). Let's not start another X vs. Y war here, please. Spirit does not claim to be the final answer to language tools. All we are saying is that your information that Spirit does not have ASTs and does not support string templates is wrong. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Hi Joel, All we are saying is that your information that Spirit
does not have ASTs and does not support string templates is wrong.
While I am not making friends, it is also misleading to suggest that Spirit "supports StringTemplates". It doesn't; it doesn't have an interpreter. And it's support for "AST" is arguable at least; those that can understand and use AST as proposed by Spirit is reduced to you, it's creator and maybe 1 or 2 others. In any case, the errors it produces are largely meaningless. That actually means something to real people. I am well argued in the area of just because you can, doesnt mean you should. Regards, Christian
Christian Schladetsch wrote:
Hi Joel,
All we are saying is that your information that Spirit
does not have ASTs and does not support string templates is wrong.
While I am not making friends, [...]
Peace be with you, Christian. I've said enough. I'll remove myself from this discussion. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
Christian Schladetsch wrote:
Hi Joel,
All we are saying is that your information that Spirit
does not have ASTs and does not support string templates is wrong.
While I am not making friends, [...]
Peace be with you, Christian. I've said enough. I'll remove myself from this discussion.
Regards, Might I suggest that more of us follow the wisdom of Joel. Christian's disregard and disrespect is indeed sad. He may be a very intelligent young man; however, he will go nowhere in either the private or open source sectors with his belligerent attitude.
-- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On Tue, Jun 9, 2009 at 8:09 PM, Christian Schladetsch < christian.schladetsch@gmail.com> wrote:
Hi Joel,
All we are saying is that your information that Spirit
does not have ASTs and does not support string templates is wrong.
While I am not making friends, it is also misleading to suggest that Spirit "supports StringTemplates". It doesn't; it doesn't have an interpreter.
And it's support for "AST" is arguable at least; those that can understand and use AST as proposed by Spirit is reduced to you, it's creator and maybe 1 or 2 others. In any case, the errors it produces are largely meaningless. That actually means something to real people.
For me, Spirit supports both AST and StringTemplates and that too very elegantly. And again for me, the errors it(other metaprogramming libraries/applications) produces are not meaningless anytime(though it has been lengthier and this is better as it contains the complete information). Initially it was very daunting for me too, but as I learned C++ by spending more time with it, the errors seem to be very friendlier and many-a-times the errors contained the solutions too which I had been trying to solve. May be with concepts addition, the errors will be earlier and shorter than the present.
Christian,
The information you're posting about Spirit is plain wrong. Spirit supports both, AST creation during parsing and template based generation of character (byte) streams.
It is not true that Spirit has the same functionalty as ANTLR+StringTemplate
Please don't write about things you don't know.
I think I know what I'm talking about. I'm the one implementing and maintaining Spirit.Karma, the library for (compiletime-) template based generation of character (byte) streams.
I know full well of what I speak about. Indeed. Spirit does not have the same functionality that StringTemplate does.
It does have similar functionality. Please stop spreading FUD. Regards Hartmut
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
We are going to be yelled-at by the powers-that-be for speaking about
non-C++ issues, and correctly.
Not necessarily.
As it turns out, I should have worried more about the Spirit-Protectionists. Even so, back on thread there was this:
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 proper fDator UI, well, you could have yourself a winner :-)
That will never happen. I have stated, and I will say forever, that I am not interested in wrapping anything. DirectX is called DirectX because it is about direct access to "x" peripheral. It is not about abstractions and I am not about introducing them.
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...
No. No. No. Christian.
On Tue, Jun 9, 2009 at 6:02 AM, Carlos Rafael Giani < e0325834@student.tuwien.ac.at> wrote:
joel wrote:
Wasn't that stuff like Ogre3d do somehow. That's ages i didn't dip into these so take this question as a real naive one for the sake of the argument.
Examples are: - pixel formats supported by one API but not by the other (Direct3D: YUV textures, OpenGL: latc compression, at least I'm not aware of a D3D equivalent) - buffers: OpenGL Buffer Objects and Direct3D Buffers work differently, and allow for different semantics - render-to-texture differs significantly between the two (OpenGL FBOs allow have many more features than their D3D equivalents) - Direct3D10 unifies all types of buffers, OpenGL 3 doesnt - Render-To-Texture in D3D understands (0,0) as being the upper left corner, in D3D it is the lower left one - Direct3D shaders and OpenGL ones have different, incompatible approaches (D3D knows no shader linking for example) - Direct3D uses vertex declarations, OpenGL uses pointers (which actually are offsets when buffer objects are used) ....
This is a small excerpt of the differences. There are more subtle ones, such as locking flags for memory mapping allowing more fine-grained data transfers in D3D.
How about HLSL (High Level Shader Language)? This is a massive difference between the two.
On Jun 9, 2009, at 4:59 AM, Carlos Rafael Giani wrote:
joel wrote:
Make this some kind of boost::graphics, target both dx and ogl or w/ e in a seamless fashion, then you have something worthy.
This is commonly found in 3D graphics engines. However, a low level ogl/dx abstraction is time-consuming, and ultimately not worth it, because both APIs, while roughly equal, differ in many details, which sums up in a low-level abstraction that covers the lowest common denominator. It is better to abstract in a higher semantic level, however this is hard to accomplish as a general 3D rendering library (and probably not very useful, since rendering applications vary wildly in their feature requirements and applied techniques).
In short, even then we don't even have something useful for boost.
I agree. Do you think that targeting, say Ogre3D, would be more adequate? Or, is the targeting of a specific non-standard API - however cross-platform it might be - not proper for Boost? I know what I think, but would like to know what others think. /David
Hi Christian, 2009/6/7 Christian Schladetsch <christian.schladetsch@gmail.com>
Is there a possibility of making submissions that use meta-C++ to assist with writing DirectX-based code?
Obviously, DirectX is Microsoft-specific (but not necessarily platform specific!). So my question comes down to "is there a space in boost for MS-specific systems"? Perhaps in boost::microsoft or boost::directx or boost::microsoft::directx.
IIUC, any library submission should be tested on at least two platforms. If your code worked on both Windows and WINE, I'd be interested in it. Having a boost-style directx interface / utility library is probably a necessary stop-gap towards having a cross-platform graphics library. As you say, directx isn't going anywhere. Do you have any publicly-available code? Cheers, Darren
Hi Darren, I can only show: template <class Vec> struct MakeVertex : boost::mpl::fold<Vec, detail::Nothing, detail::AddBase>::type { typedef typename boost::mpl::fold<Vec, detail::Nothing, detail::AddDeclaration>::type MakeDecl; static Vertex::Declaration MakeDeclaration() { Vertex::Declaration decl; MakeDecl::AddDecl(decl); Vertex::Declaration::Element end = {0xFF,0,D3DDECLTYPE_UNUSED,0,0,0}; decl.Add(end); return decl; } }; Without more time, Cheers Christian
It is hard to tell what your library would provide.
Ok, wait. I am not doing that. My original post was about merely introducing the idea of a namespace. That namespace would be boost::microsoft for MS-specific things to support a boost::microsoft::directx or boost::directx namespace with DirectX specific code. At no point was this about me giving away DX code or DX libs or making boost::directx my own. Of course, I have my own, otherwise this would not be an issue.
participants (13)
-
Andrey Torba -
Carlos Rafael Giani -
Chandrashekhar Kumar -
Christian Schladetsch -
Darren Garvey -
David Bergman -
Hartmut Kaiser -
joel -
Joel de Guzman -
Maik Beckmann -
Mathias Gaunard -
Michael Caisse -
Zachary Turner