Re: Reviving BulletD -- again
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;
}
Re: Reviving BulletD -- again
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).
Re: dmd 2.063 beta 5
Leandro Lucarella wrote: That's completely FALSE. You might need some bugfixes! That view of if you want to be up to date you have to be willing to update a lot of code is really hurting D's stability. Evolution was never pain-free. The idea that D can thrive without adapting to it's changing environment will really hurt D's popularity now and in the future. Isn't the feature you folks are talking about technically a bug-fix? IMO it's better to use an older compiler if you really need your work-arounds to function (granted there is proper docs), and let the rest of people adapt with the language.
Re: Reviving BulletD -- again
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.
Re: Reviving BulletD -- again
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!
