After a significant hiatus, I've decided that I need to get BulletD up and running again. I think that the main reason it died was just that I felt so overwhelmed with the sheer magnitude of the project, and I've realized that there's no way I can finish it myself in a reasonable amount of time, so I'm issuing an invitation to anyone who's interested in helping to get it to a functional state.

Here's the project's current status:

I've gotten about 7,000 lines of code ported (which, by my estimates, is under 10% of the codebase), but it needs to be revised to be up-to-date with the latest version of Bullet, and my earlier misguided attempts to make the memory allocators more "D-friendly" need to be reverted to the original form used in Bullet. I'm also probably missing some parts of the modules I've ported, so I'll need to get those fleshed out.

If anyone feels like participating, feel free to port a module or two and submit a pull request at github.com/blm768/bulletD. The current focus is getting the already-ported modules revised (and rewritten where necessary), especially in the linearMath subdirectory because so many modules depend on that code.

On 3/23/2013 5:22 PM, BLM768 wrote:
> I've gotten about 7,000 lines of code ported (which, by my estimates, is
> under 10% of the codebase), but it needs to be revised to be up-to-date
> with the latest version of Bullet

Why a port instead of a wrapper?

> Why a port instead of a wrapper?

I initially tried to generate a wrapper with SWIG, but Bullet uses nested classes, which cause SWIG to choke. I could write my own wrapper, but it would cause a loss of flexibility (especially with templates) and introduce a bit of overhead. Considering the size of Bullet's interface, a port doesn't seem that much harder than a wrapper when both languages use a similar syntax.

That being said, if anyone has an idea for a wrapper system that would expose all or most of what can be done with the C++ interface and be significantly easier to maintain than a port, I'm completely open to the idea.

After re-analyzing the magnitude of the project in light of the rather lukewarm response I've gotten so far, I think that I may indeed have to move to a wrapper system. I'm currently weighing my options:

extern(C++) interfaces: From what I understand, these are not well-supported outside of DMD, so I think that's out.

A C layer: This seems like the most practical option. I'm thinking about using pragma(msg) to generate C code directly from the D sources and just redirect the output into C source files. Hacky, but probably not too difficult to implement.

Using some sort of magic to directly work with the C++ mangling and ABI: Probably the most difficult option, but it would be kind of nifty and would get rid of the overhead of a C layer. Probably not worth the effort right now, especially considering that it would be heavily compiler-specific.

There was a fair amount of talk in the general discussion forum about automatically converting the dmd C sources into D, so there may be some advice or ideas in there that may apply, although perhaps the biggest difficulty is that the Bullet API is C++ not C.

Just a wild thought and probably not possible, but if there's a layer in Bullet that provides the core functionality and does not require classes, then you could create a C wrapper for it alone, then build the C++ layer up using D.

--rt

On Sunday, 14 April 2013 at 21:38:49 UTC, Rob T wrote:
> Just a wild thought and probably not possible, but if there's a layer in Bullet that provides the core functionality and does not require classes, then you could create a C wrapper for it alone, then build the C++ layer up using D.
>
> --rt

There's been an effort to create a Bullet C API, but it's rather limited at the moment, and I'm hoping to preserve as much of the original OO interface as possible.

If I can automate the generation of bindings to a satisfactory degree, expanding the bindings should be a very simple process, so I could just write bindings for the core functionality and have others expand the bindings as needed. That way, the bindings only contain things that someone will actually use. I think that I'll represent the C++ classes as structs that hold the actual C++ objects as void arrays and contain stub methods that just forward to the C layer. If I can figure out a way to do it, I'd like to alias those stub methods directly to their C counterparts so I can handle cases where inlining won't kick in.

On Monday, 15 April 2013 at 05:26:27 UTC, BLM768 wrote:
>
> If I can automate the generation of bindings to a satisfactory degree, expanding the bindings should be a very simple process, so I could just write bindings for the core functionality and have others expand the bindings as needed. That way, the bindings only contain things that someone will actually use. I think that I'll represent the C++ classes as structs that hold the actual C++ objects as void arrays and contain stub methods that just forward to the C layer. If I can figure out a way to do it, I'd like to alias those stub methods directly to their C counterparts so I can handle cases where inlining won't kick in.

I've recently made some breakthroughs in the area of binding generation, and the system has reached the point where I can instantiate and use a simple C++ class (namely btTypedObject, which is probably the simplest class in Bullet) from D using my generated bindings. The system is rather interesting, but it's also a bit messy, so explore the code at your own risk.

Here's a condensed version of the test code:

//bullet/linearMath/btScalar.d
//Support code omitted
struct btTypedObject {
	mixin classBinding!"btTypedObject";

	mixin constructor!(int);
	mixin method!(int, "getObjectType");
}

//test.d
module main;

import std.stdio;

import bullet.linearMath.btScalar;

int main(string[] args) {
	auto obj = btTypedObject(1);

	writeln(obj.getObjectType());

	return 0;
}

I know Bullet is the most noteworthy open-source physics library, but if you intent is to have a D-style physics lib for games/apps you might have a lot more success porting a C# physics engine like Jitter (http://jitter-physics.com/wordpress/) over to D first (then possibly adapt some stuff from Bullet into the code once it's stable). Porting a C# codebase to D should be much less of a struggle.

We use Jitter in our C# game libs, and in some cases we've experienced it even beating Bullet in terms of runtime performance in some test cases (granted I don't know near as much about performance tuning in Bullet).

On Tuesday, 28 May 2013 at 17:37:27 UTC, F i L wrote:
> I know Bullet is the most noteworthy open-source physics library, but if you intent is to have a D-style physics lib for games/apps you might have a lot more success porting a C# physics engine like Jitter (http://jitter-physics.com/wordpress/) over to D first (then possibly adapt some stuff from Bullet into the code once it's stable). Porting a C# codebase to D should be much less of a struggle.
>
> We use Jitter in our C# game libs, and in some cases we've experienced it even beating Bullet in terms of runtime performance in some test cases (granted I don't know near as much about performance tuning in Bullet).

That definitely looks like an interesting library; I might have
to research it more. However, I'll probably stick with Bullet for
now; it seems to be more mature, and since I'm leaning toward
using a binding rather than a port, Bullet is probably the easier
option because I don't have to fiddle with the C# garbage
collector.

On 28-5-2013 21:22, BLM768 wrote:
> On Tuesday, 28 May 2013 at 17:37:27 UTC, F i L wrote:
>> I know Bullet is the most noteworthy open-source physics library, but
>> if you intent is to have a D-style physics lib for games/apps you
>> might have a lot more success porting a C# physics engine like Jitter
>> (http://jitter-physics.com/wordpress/) over to D first (then possibly
>> adapt some stuff from Bullet into the code once it's stable). Porting
>> a C# codebase to D should be much less of a struggle.
>>
>> We use Jitter in our C# game libs, and in some cases we've experienced
>> it even beating Bullet in terms of runtime performance in some test
>> cases (granted I don't know near as much about performance tuning in
>> Bullet).
>
> That definitely looks like an interesting library; I might have
> to research it more. However, I'll probably stick with Bullet for
> now; it seems to be more mature, and since I'm leaning toward
> using a binding rather than a port, Bullet is probably the easier
> option because I don't have to fiddle with the C# garbage
> collector.

Really forward to the binding!
I would love to be able to do more than only the C-lib!