BulletD needs your help!
BLM768 via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Mon Jul 4 13:03:45 PDT 2016
A couple of years ago, I started writing some bindings for the
Bullet Physics library (bulletphysics.org). This was well before
D's new C++ interop features, so I wrote a hacky little chain of
build scripts (which generated each other about 3 levels deep!).
The thing actually worked to a certain extent, and there seemed
to be some community interest in the project, but then life kept
me from spending any time on the project, and it basically died.
That brings me to the topic of this post: if the community still
has an interest in Bullet Physics bindings, I'm willing to revive
the project, but I'll need some input from the community in order
to figure out what direction to take the it.
As far as I can tell, D's C++ interop has improved to the point
where it should cover all the C++ features that Bullet uses. That
would make most of the binding generation code unnecessary
(although some glue to semi-automatically instantiate C++
templates could be useful). However, I've never used the C++
interop features, so I don't know how stable they are in a
cross-platform environment, especially with LDC and GDC.
The other option would be to clean up the binding generation
code. The advantage I see here is that the code may be useful for
creating bindings to other languages, i.e. Rust. However, the
solution I had wasn't very elegant, and a better solution is
unlikely to happen until PR 5290 gets merged.
To give an idea of how the binding generation would work, here's
a basic idea of how the code would look when binding to a simple
class hierarchy:
struct RayResultCallback
{
mixin classBasic!"btCollisionWorld::RayResultCallback";
mixin method!(void, "setCollisionFilterGroup", short);
mixin method!(void, "setCollisionFilterMask", short);
mixin method!(bool, "hasHit");
}
struct ClosestRayResultCallback
{
mixin classChild!("btCollisionWorld::ClosestRayResultCallback",
RayResultCallback);
mixin opNew!(ParamRefConst!btVector3, ParamRefConst!btVector3);
mixin method!(btVector3, "getHitPointWorld");
mixin method!(btVector3, "getHitNormalWorld");
mixin method!(ParamPtr!(btCollisionObject),
"getCollisionObject");
}
It's not quite as readable as plain D, but that's because it's
creating a whole C glue layer behind the scenes (with a little
external help to produce the C(++) source files).
Thoughts? Concerns? Tomatoes?
More information about the Digitalmars-d-announce
mailing list