Re: [boost] boost::directx?
Hi guys, I have been following this thread but haven't really found the significance of boost::directx! If the purpose of the library is to create a comprehensive graphics library, choosing directx or infact any other API seems absurd. For example, ORGE is a graphics library that doesn't choose OpenGL over DirecX but provides a wrapping interface for a graphics library where this library's internal is OpenGL and DirectX depending on the platform. I just think if this library is going to established within boost, it requires a portable interface irrespective of the internals. With Best Regards --- Kasra Nassiri
Hi Kasra, I have been following this thread but haven't really found the significance
of boost::directx!
I apologise for not being clearer from the outset If the purpose of the library is to create a comprehensive graphics library,
choosing directx or infact any other API seems absurd.
I have repeatedly stated that the purpose of the proposed library is to help people make performant applications using DirectX and C++. I have repeatedly stated that I have no wish in (re-)virtualising hardware, providing a generalised API, or arguing about OpenGL. I proposed the name to be boost::directx because I am concerned about game developers that use C++, DirectX, and boost. I am not interested in boost::graphics or similar attempts at nightmare creation. For example, ORGE is a graphics library that doesn't choose OpenGL over
DirectX cannot be portable, outside of the muliple platforms that it already supports: Xbox360 (native and XNA) and Windows, and WINE. 360 and Win32/64 are different platforms with two different API and kernels.
With Best Regards
--- Kasra Nassiri
Regards, Christian
Hi Christian, 2009/6/8 Christian Schladetsch <christian.schladetsch@gmail.com>
DirectX cannot be portable, outside of the muliple platforms that it already
supports: Xbox360 (native and XNA) and Windows, and WINE.
I interpret the Boost rule on portability to have a basis of "the basics must be platform-independant and portable, and you must show this by implementing at least two platforms' worth of it". If you start off by stating your intent is to wrap DirectX it very strongly feels like a bad idea to add it to Boost, as it'll break the assumptions (valid or not) many people have about Boost. I'm interested in a cross-platform graphics base system and I don't care what it's based on. OpenGL is not as dead as you would like it to be, nor is OpenGL ES. Kind regards, Peter Bindels
On Mon, Jun 8, 2009 at 3:18 PM, Peter Bindels <dascandy@gmail.com> wrote:
I haven't followed the discussion and I apologize if I'm repeating something, but in my mind if three is a useful library A, and if we could provide a layer (wrapping?) which makes library A work better with Boost, the only question should be how popular library A is, and how many of library A's users would benefit from an easier Boost integration. Specifically, what platforms that library runs on is not important. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
AMDG Emil Dotchevski wrote:
That's perfectly true if the question is whether such a wrapper should be created, but...
Specifically, what platforms that library runs on is not important.
Portability is important for deciding whether to include such a wrapper in Boost. From the requirements: "A library's interface must portable.... If a portable implementation is not possible, non-portable constructions are acceptable /if reasonably easy to port to other environments/..." [emphasis mine] In Christ, Steven Watanabe
On Mon, Jun 8, 2009 at 3:52 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
In this context, the wrapper I was talking about would be the Boost library. The requirements simply state that that wrapper should be portable, that's fine. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Jun 8, 2009, at 6:58 PM, David Bergman wrote:
My response sounded harsh. What I think I meant is what is stopping someone from creating a Boost-compatible and Boostesque wrapper for DirectX? Why must it be part of the Boost libraries? As a side note, I think a better strategy would be to create a DirectX wrapper that is isomorphic to Managed DirectX (API), though, to ease the transition and porting from/to .NET and XNA. /David
On Mon, Jun 8, 2009 at 4:10 PM, David Bergman <David.Bergman@bergmangupta.com> wrote:
You can ask this question for any Boost library: why should it be part of Boost? Presumably the answer is "because many programmers (Boost users) would benefit from it." Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Jun 8, 2009, at 7:56 PM, Emil Dotchevski wrote:
Most libraries are integral to Boost, and constitute aspects that together bring the developer to another level of abstraction and solution terminology. Boost is not a random set of code happening to be compilable with C/C++ and somehow having a potentially big audience. I do not welcome domain-specific or target-specific code with open arms.
Presumably the answer is "because many programmers (Boost users) would benefit from it."
No. The answer is - or should be - because programmers can benefit from FOO on any platform and most types of applications, and FOO is in harmony with the goal of Boost and the existing libraries. I am not even super-happy about quite specific math libraries entering Boost now and then - ending up with a bunch of them. /David
On Mon, Jun 8, 2009 at 5:07 PM, David Bergman <David.Bergman@bergmangupta.com> wrote:
The question is, do we or do we not allow domain-specific libraries in Boost? I think that it is obvious that we do, there are quite a few of them. We could say "OK, no more domain-specific libraries in Boost!!!~!~1`~!!~111" but first we must formally define the domain of libraries that are acceptable in Boost. Good luck with that. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Jun 8, 2009, at 8:19 PM, Emil Dotchevski wrote:
On Mon, Jun 8, 2009 at 5:07 PM, David Bergman
[snip]
Yeah? I think you have the wrong idea about Boost - have you used Boost a lot, and in that case, what libraries? The bulk are generic language-lifting tools, basically giving the programmer a greater vocabulary. And, even if I bashed math libraries a bit, I would classify the current (as of 1.39.0) libraries as (and I did go through each library, and might have counted wrong with a few units here and there): 1. Language Extensions - 60 (including Statechart and BGL, which are applicable much more often than the developer realizes) 2. Common Types & Features (often part of newer languages standard libraries) - 8 (Accumulate, Numeric Conversion, Date, Format, Random, Regex, Serialization, Xpressive) 3. OS Abstraction Layer - 8 (Filesystem, Asio, Interprocess, Iostreams, Pool, System, Thread, Timer) 4. Math - 8 (Interval, various Math libraries, Rational) 5. Other Specialized - 7 (CRC, GIL, MPI, Proto, Python, Spirit, uBLAS, Units) The first two categories can be characterized as bringing the language of C++ up to (and beyond) that of newer creations, where the third category is often part of such a standard library. The number of libraries belonging to those three categories is 76. The latter two categories are clearly domain-specific, though. The number of such libraries is 15. If you disagree with these figures, I welcome a revised table, otherwise we can clearly state that domain- and target-*agnostic* libraries constitute the bulk of Boost, by far.
First of all, I do not understand why we would have to use profanity in stating that, but alright, I would definitely welcome such a decision, and it is quite easy; just see the table above. I would welcome exclusion of those 15 domain-specific libraries... /David
On Mon, Jun 8, 2009 at 5:47 PM, David Bergman <David.Bergman@bergmangupta.com> wrote:
Domain-specific Boost libraries are a fact, yet I have the wrong idea about Boost? :)
You still need to provide a formal definition of what is a domain-specific library and what isn't. You can't just say "These 15 libraries are domain-specific because I say so." Not to mention, this presumes that there is an agreement that we don't welcome domain-specific libraries in Boost, which (obviously?) isn't true. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Jun 8, 2009, at 8:47 PM, David Bergman wrote:
Looking even closer at the potentially domain-specific libraries (those 15; I actually moved Spirit up to #2, I see now), we see tthat 12 of them belong to the domain of Scientific Computing. So, if we state that "Boost is a set of language-enhancing libraries along with the slight exception of one domain, scientific computing" we are left with only three libraries. Three oucasts: CRC, Python and GIL. The first one can easily be transitioned into category #2, and then we are left with only two: Python and GIL. And the former one is not even specific to any business domain. Let me put it this way: if something like Boost.Python was suggested today, and by somebody fairly new to the Boost community, it would not stand a chance to be considered ;-) Going back to your challenge of formally defining the "admissible" domains, where you even wished me good luck: there is only *one* specific domain for which Boost includes support and that is scientific computing, and even in such cases, the libraries should be multi-platform as far as possible. This holds up to two tiny exceptions, GIL and Python. And even those clearly exceptional cases are multi-platform. /David
On Mon, Jun 8, 2009 at 6:18 PM, David Bergman <David.Bergman@bergmangupta.com> wrote:
Any library that is proposed for inclusion in Boost is considered. The only prerequisite is that someone volunteers as a review manager. After a review process, the review manager decides if the library is going to be included or not. Note that the review manager is not bound to base her decision purely on vote count, at least not formally. I am not saying that I like this process, all I'm saying is that this is how Boost works, AFAIK. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
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. 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(); 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. 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++". 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. 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. 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. Regards, Christian.
On Jun 9, 2009, at 12:30 AM, Christian Schladetsch wrote:
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.
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.
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.
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.)
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.
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.
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
2009/6/9 Emil Dotchevski <emildotchevski@gmail.com>:
We don't need formal boundaries, we determine what is suitable using the submission process. This thread suggests that a DirectX wrapper would be rejected. FC++ was rejected, but phoenix was accepted. We don't have a formal rule that divides the two but there was enough of a consensus that FC++ doesn't fit even though it is highly regarded within the boost community. The review process relies on considered judgement rather than a set of fixed rules. We're not lawyers. Daniel
Hi Daniel, This thread suggests that a DirectX wrapper
would be rejected.
I have gone to great lengths to make clear that I am not proposing a "DirectX wrapper". Providing systems that support DirectX development is a different thing to making a system that wraps DirectX. Cheers, Christian.
Hi Daniel, OK. This thread suggests that a 'system that supports DirectX
development' would be rejected.
It could be argued otherwise. This thread already has over 75 responses. If the case was automatically unianimous, it would be more like 5 responses. In any case, it is not clear that the consensus is that a system that supports DirectX is completely out of the question. I am not naive, I grok that the idea is an anathema to boost, and that I would face an uphill battle to get anything at all related to DirectX into boost. But, I am an idealog. The truth is that a lot of people that use C++ also use DirectX. A goal of boost is to provide support for the C++ community, and to guide best practise. Regards, Christian.
Christian Schladetsch schrieb am Dienstag 09 Juni 2009 um 11:50:
The length of this thread is more likely caused by your offending wording style, like rendering people unworthy responding to your posts because they don't know the characteristics of JVM and CLR well enough. However, here are my 2 cents... My impression is that you want to get more people to use boost in a directx context. This is a win-win situation, since this brings cleaner code into games and more code testing users to boost. But an important point about boost is: Write once, compile (and thus run) everywhere. This is a conflict you cannot resolve. Your lib would be AFAIK the first one that doesn't fit into this requirement. Given the fact you are a directx guy and not a OpenGL one makes it unpractical for you to do a good job on writing the same for OpenGL or even do an abstraction. So why not just start a project at sourceforge/code.google and post release notifications to the boost-users list? Aside from publicity, being part of the daily testing cycle is the most important benefit of getting your code into boost. If more projects like yours are around it maybe the time to think about domain/platform specific boost- extensions, which are hosted at boost.org and included in the automatic testing system. Live long and prosper, --Maik
Hi Mark, My impression is that you want to get more people to use boost in a directx
context. This is a win-win situation, since this brings cleaner code into games and more code testing users to boost.
Yes, that is my goal. I understand and appreciate the repeated advice that I should make a different repos, and a different site, to make my case. But it should also be clear that I had to try boost first. And I have not given up; there are many people that don't use boost that could and should. See my alternate thread on monotonic allocators. Regards, Christian
Hello, Christian. Tuesday, June 9, 2009 at 3:40:40 PM you wrote: CS> Hi Mark, CS> My impression is that you want to get more people to use boost in a directx
context. This is a win-win situation, since this brings cleaner code into games and more code testing users to boost.
CS> Yes, that is my goal. CS> I understand and appreciate the repeated advice that I should make a CS> different repos, and a different site, to make my case. But it should also CS> be clear that I had to try boost first. Another two cents. It think you clearly understand what structure of the game development sector is quite complex. Of course, DirectX is a most suitable for PC-Windows and Xbox platforms. But there are popular game consoles (PlayStation (2, 3), Wii), Mac OS descktops, many mobile platforms (iPhone, Windows CE, PalmOS etc) and others. This is a world of the OpenGL (ES). What could you offer for developers for such platforms? :) Another view to this sector is following. Big game development companies have they own libraries and engines (try this link http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html, for example). Small developer teams are using simplest tools usually. As far as I know some members of such teams don't like either boost or STL. These libraries are too difficult for them (for _some_ small game-dev teams members, I mean). So what kind of game development teams are aimed by such kind of tool? Also you could known what 'casual' games are becoming more and more popular. Such kind of games are quite easy for develop and can be played on the wide range of platforms (both desktop and mobile, especially mobile). So _portable_ game-development library could be asked-for but not only DirectX-tied. -- Best Regards, Sergey mailto:flex_ferrum@artberg.ru
Hi Sergey, What could you offer for developers for such [alternative] platforms? :) The first step is getting DX into boost. There are other platforms and targets sure, but each would have to be taken on their merit.
I fully grok that taht there are other platfforms and targets. But if i can't get DX into boost, the others are toast. This will be read by some that boost::directx is a trojan. I do not mean for this to be the case. boost::directx is proposed to be a space for best-practise for people using DirectX to make systems using C++. Regards, Christian
The first step is getting DX into boost. There are other platforms and targets sure, but each would have to be taken on their merit.
It seems unlikely to me that the library you are proposing would be considered for acceptance into the mainstream Boost distributions for the reasons previously discussed. Being antagonistic to maintainers certainly doesn't forward your cause, either. This doesn't mean, however, that the idea should be abandoned. There are some good examples of high-quality, domain-specific, Boost-like libraries that exist outside of the Boost umbrella and stand on their own merit (e.g., SOCI, CGAL, etc). I would encourage you to develop the library to maturity and then reevaluate whether or not submitting to Boost is a good fit for you. I fully grok that taht there are other platfforms and targets. But if i
A library doesn't need to be in Boost to demonstrate or encourage best practice. Andrew Sutton andrew.n.sutton@gmail.com
Hello, Christian. Tuesday, June 9, 2009 at 5:50:44 PM you wrote:
CS> I fully grok that taht there are other platfforms and targets. But if i CS> can't get DX into boost, the others are toast. CS> This will be read by some that boost::directx is a trojan. I do not mean for CS> this to be the case. boost::directx is proposed to be a space for CS> best-practise for people using DirectX to make systems using C++. You didn't understand my questions. I also wonder if such 3D-graphics library become the part of the boost. But... _Crossplatform_ 3D-graphics library. Not only DX or OGL. It will really useful library. -- Best Regards, Sergey mailto:flex_ferrum@artberg.ru
On Tue, Jun 9, 2009 at 4:50 AM, Christian Schladetsch < christian.schladetsch@gmail.com> wrote:
In any case, it is not clear that the consensus is that a system that supports DirectX is completely out of the question.
Well we're mingling words now, but I do think it's clear that the consensus is that a system that ONLY supports DirectX is out of the question.
2009/6/9 Thorsten Ottosen <thorsten.ottosen@dezide.com>:
Because most people seem to be against it? I deliberately said that this thread suggests that it would be rejected - not that it is 'against the rules' or that I would vote against it. I'm more interested in people's interpretation of how boost works. It also doesn't help that the proposer doesn't value diplomacy.
How many of those with negative comments are actually using direct x?
The negative comments are almost uniformly about the suitability of a library that's tied to a third party non-portable library. I don't recall anyone criticizing the quality of direct x.
I personally think it would be a ice addition to boost, if it adds true value.
The best way to show that would be to post an encouraging response to the original post. Daniel
Chris, I agree with you that a library supporting DirectX in C++ would be very useful, but I also agree that such a library wouldn't be appropriate for boost, as it wouldn't be portable at all. Don't let that put you off writing such a library though - there's no reason that a C++ utility library for DirectX that promotes good practices wouldn't be very useful for a number of people. It doesn't have to be in Boost to be useful. Joe.
Joseph Gauterin skrev:
I don't see that as a good reason for not having it in boost. We have libraries that are tied to third parti libs, and we have libraries with a very narrow use, far fewer people using them that would a DirectX library IMO. -Thorsten
On Thu, Jun 11, 2009 at 7:40 AM, Thorsten Ottosen < thorsten.ottosen@dezide.com> wrote:
Are the third party libraries portable? There's really no reason other than lack of motivation that basic 3d functionality cannot be implemented on top of both opengl and directx, or directx and ogre3d.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 11 June 2009, Zachary Turner wrote:
I suspect even if the boost library only supported opengl it would face less resistance, since opengl is portable (and not just in the windows and WINE sense). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoxB+wACgkQ5vihyNWuA4UxyQCdGx/+NEaeRjpQkR0ojZf4dn/2 ZrIAn2JCd1ZkdoUKvAIbEOJ1a7UccHZb =dCtj -----END PGP SIGNATURE-----
2009/6/11 Thorsten Ottosen <thorsten.ottosen@dezide.com>
What library? I haven't seen *any* proposal for a DirectX library. Correct me if I'm wrong, but all I've seen so far was a proposal to have a boost::directx namespace now as a dumping ground should somebody in the world possibly choose to write a C++ DirectX related library that they would wish to submit to Boost sometime in the future. Given that, there is nothing actually to implement, even if we as a community thought it was a good idea. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
Hi Niven, It may've been easy to miss in the scuffle, but I did actually provide a demonstration of an inidcative library for inclusion into the proposed directx namespace. It is in the vault at http://www.boostpro.com/vault/index.php?action=downloadfile&filename=make_vertex.zip&directory=& . Regards, Christian. On Fri, Jun 12, 2009 at 7:04 AM, Nevin ":-]" Liber <nevin@eviloverlord.com>wrote:
Christian Schladetsch skrev:
again, please make it online. I concur that it would make your library easier to get accepted if it was on a higher abstraction level, falling back internally on suboptimal open-gl for portability. That way the library would be usefull also for those not doing cutting edge game programming. -Thorsten
Hi Thorsten, So would it be OK to put this in sandbox/directx, with some docs? I don't want to start a trojan or inject 'tainted' code, even to the sandbox. However, some interest has been shown in at least reviewing this code and the sandbox is the place for that, no? Cheers, Christian. On Fri, Jun 12, 2009 at 10:42 PM, Thorsten Ottosen < thorsten.ottosen@dezide.com> wrote:
On Jun 8, 2009, at 6:18 PM, Peter Bindels wrote:
So you mean Windows XP and Windows Vista are not two platforms? ;-)
Agreed. I would rather see an SDL and OpenGL effort under the Boost umbrella. And if DirectX game developers want to use a special C++ wrapper but still want to use the name 'boost', they could always do namespace boost { namespace directx = MyCoolDirectXWrapper; } ;-) /David
participants (16)
-
Andrew Sutton -
Christian Schladetsch -
Daniel James -
David Bergman -
Emil Dotchevski -
Frank Mori Hess -
Hartmut Kaiser -
Joseph Gauterin -
Kasra -
Maik Beckmann -
Nevin ":-]" Liber -
Peter Bindels -
Sergey Sadovnikov -
Steven Watanabe -
Thorsten Ottosen -
Zachary Turner