Re: [boost] boost::directx?
Hi,
The hard reality is that a lot of people use C++ and DirectX. A lot of people use C++ *because* they use DirectX. Another group use DirectX because they use C++.
It is very good to have a good C++ library for DirectX/Direct3D... But it **does not** belong to Boost that is cross platform project. Project that helps writing good software without vendor lock-in. You can just create another library that may be tightly integrated with Boost. But it does not have place in Boost, like many other good C++ libraries that have no place in Boost.
That audience not only includes but primarily consists of game developers. And they all use DirectX.
You wrong. I can give you a list of great games that use OpenGL like: - IL-2 - Quake - Unreal Tournament - World of Warcraft And many others. Actually, any game that supports Mac OS X or other OSs uses OpenGL. The fact that most of games developed for MS Windows under MS Windows does not means that all of games use Direct3D. So... You can't claim that directX is only video gaming API, not talking about that not everything is video games, actually in Scientific and research project OpenGL has clear dominance. Best, Artyom
Greetings Arytom, It is very good to have a good C++ library for DirectX/Direct3D...
But it **does not** belong to Boost that is cross platform project. Project that helps writing good software without vendor lock-in.
Verily, you are not `boost`. I encourage others that are reading this to think for themselves and make their own opinions. Boost is about helping coders to make performant applications in C++.
You can just create another library that may be tightly integrated with Boost. But it does not have place in Boost, like many other good C++ libraries that have no place in Boost.
That is not your call.
That audience not only includes but primarily consists of game developers. And they all use DirectX.
You wrong. I can give you a list of great games that use OpenGL like:
This is not about OpenGL VS DirectX. I hope I will not get more tired of making this point: I want to help helping people make DirectX appications using C++ and boost. Regards, Christian.
Christian Schladetsch wrote:
Greetings Arytom,
It is very good to have a good C++ library for DirectX/Direct3D...
But it **does not** belong to Boost that is cross platform project. Project that helps writing good software without vendor lock-in.
Verily, you are not `boost`. I encourage others that are reading this to think for themselves and make their own opinions.
Well, I agree with him. I'm not "boost" either, though.
Boost is about helping coders to make performant applications in C++.
Boost is about helping coders to make expressive, clear, correct, and portable (note that those are all important) applications in C++. Performance is secondary. (See http://www.boost.org/development/requirements.html: "Aim first for clarity and correctness; optimization should be only a secondary concern in most Boost libraries."; "A library's interface must portable and not restricted to a particular compiler or operating system.")
You can just create another library that may be tightly integrated with Boost. But it does not have place in Boost, like many other good C++ libraries that have no place in Boost.
That is not your call.
It isn't your call either. It's the community's. My opinion is that libraries do not belong in Boost merely because they are useful.
That audience not only includes but primarily consists of game developers.
I am skeptical of this assertion. Perhaps most game developers use C++, but that does not imply that most C++ users are game developers.
And they all use DirectX. You wrong. I can give you a list of great games that use OpenGL like:
This is not about OpenGL VS DirectX. I hope I will not get more tired of making this point: I want to help helping people make DirectX appications using C++ and boost.
I don't believe the poster was arguing the merits of OpenGL vs. DirectX, merely pointing out that your assertion that "they all use DirectX" is misleading. As for helping people use DirectX, C++ and Boost together, nothing is stopping you from doing that. A library does not need to be part of Boost to play well with Boost. --Jeffrey Bosboom
Sorry, I didn't see the resolution of the discussion in one of the other threads. (Someone's e-mail/news client doesn't grok threads, although it may just be mine.) I don't mean to reopen this can of worms. I encourage you on any work you do on such a library, even if it is not a Boost library, since I agree it would be useful to the C++-using DirectX-using community. --Jeffrey Bosboom
Hello, I have decided to put my money where my mouth is, and have uploaded a proposal to the vault. It is at http://www.boostpro.com/vault/index.php?action=downloadfile&filename=make_vertex.zip&directory=& . The proposal is for a means to create DirectX vertex types, with the accompanying vertex declaration structure. I also added a simple com_ptr<T>, based on boost::shared_ptr<T>. If there is any interest in this, please let me know. Regards, Christian.
On Sun, Jun 7, 2009 at 10:16 PM, Christian Schladetsch < christian.schladetsch@gmail.com> wrote:
Hello,
I have decided to put my money where my mouth is, and have uploaded a proposal to the vault. It is at
http://www.boostpro.com/vault/index.php?action=downloadfile&filename=make_vertex.zip&directory=& .
The proposal is for a means to create DirectX vertex types, with the accompanying vertex declaration structure. I also added a simple com_ptr<T>, based on boost::shared_ptr<T>.
If there is any interest in this, please let me know.
I do think it would be interesting to see what things could evolve out of such a library, so hopefully there's other people on the list more experienced with DirectX than I that could help it mature and perhaps add some backend support for OpenGL. That being said, below is my own com_ptr class. Before posting the code though, here's how it can be used: d3d_ptr<IDirectInputDevice8> keyboard_; HR(direct_input_->CreateDevice(GUID_SysKeyboard, recv_d3d_ptr(keyboard_), NULL)); Basically solving the problem of having to first declare a raw pointer, then pass the address to a COM api, then initialize it in the constructor, this does it all in one shot. #define d3d_ptr boost::intrusive_ptr inline void intrusive_ptr_add_ref(IUnknown* punk) { punk->AddRef(); } inline void intrusive_ptr_release(IUnknown* punk) { punk->Release(); } template<typename T> d3d_ptr<T> take_ptr(T* t) { return d3d_ptr<T>(t, false); } template<typename T> class recv_d3d_ptr_t { public: recv_d3d_ptr_t(d3d_ptr<T>& r) : m_auto(r), m_raw(NULL) {} ~recv_d3d_ptr_t() {m_auto = take_ptr(m_raw);} operator T**() { return &m_raw; } operator void**() { return reinterpret_cast<void**>(&m_raw); } private: T* m_raw; d3d_ptr<T>& m_auto; }; template<typename T> recv_d3d_ptr_t<T> recv_d3d_ptr(d3d_ptr<T>& rptr) { return recv_d3d_ptr_t<T>(rptr); } template<typename Dest, typename Src> d3d_ptr<Dest> query_interface(Src p, const IID& iid = __uuidof(Dest)) { void* pv = NULL; p->QueryInterface(iid, &pv); Dest* p2 = static_cast<Dest*>(pv); return d3d_ptr<Dest>(p2, false); } Out of curiosity what was the motivation for deriving from shared_ptr instead of using intrusive_ptr?
Out of curiosity what was the motivation for deriving from shared_ptr instead of using intrusive_ptr?
shared_ptr simply fitted the bill. Your com_ptr uses IUnkown::AddRef() and IUnkown::Release(), which is arguably slower than using shared_ptr's own reference counting scheme, which mine does. However, I like the ability to construct objects in-place rather than having to first create a 'raw' COM object, then assigning it to a com_ptr<T> Regards, Christian.
participants (4)
-
Artyom -
Christian Schladetsch -
Jeffrey Bosboom -
Zachary Turner