www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Reviving BulletD -- again

reply "BLM768" <blm768 gmail.com> writes:
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.
Mar 23 2013
next sibling parent reply JoeCoder <dnewsgroup2 yage3d.net> writes:
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?
Mar 23 2013
parent reply "BLM768" <blm768 gmail.com> writes:
 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.
Mar 23 2013
parent "BLM768" <blm768 gmail.com> writes:
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.
Apr 13 2013
prev sibling next sibling parent reply "Rob T" <alanb ucora.com> writes:
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
Apr 14 2013
parent reply "BLM768" <blm768 gmail.com> writes:
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.
Apr 14 2013
parent "BLM768" <blm768 gmail.com> writes:
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;
}
May 27 2013
prev sibling parent reply "F i L" <witte2008 gmail.com> writes:
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 

like Jitter (http://jitter-physics.com/wordpress/) over to D 
first (then possibly adapt some stuff from Bullet into the code 

of a struggle.


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).
May 28 2013
parent reply "BLM768" <blm768 gmail.com> writes:
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 

 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 

 struggle.


 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

collector.
May 28 2013
parent Faux Amis <faux amis.com> writes:
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

 (http://jitter-physics.com/wordpress/) over to D first (then possibly
 adapt some stuff from Bullet into the code once it's stable). Porting



 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

 collector.


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