www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dbox is a complete D2 port of the Box2D game physics library

reply Andrej Mitrovic via Digitalmars-d-announce writes:
https://github.com/d-gamedev-team/dbox

What is Box2D?
==============

Box2D[1] is an open source C++ physics engine used for simulating
rigid bodies in 2D. Box2D is developed by Erin Catto and is
zlib-licensed. Box2D is mainly used for game development and
interactive physics simulations.
Box2D is platform-independent and has no dependencies
other than its test-suite which requires the GLFW library.

[1] : http://box2d.org/about/

What is dbox?
==============

dbox[2] is a complete D2 port of the Box2D C++ library.
dbox targets the latest release of Box2D (currently at v2.3.1)
and includes a port of its GUI test-suite.
The test-suite includes over 50 unique and interactive examples
demonstrating the capabilities of the physics engine.

dbox is also a dub package which you can add to your build
dependencies right away. See the dub project page[3] for
more information.

[2] : https://github.com/d-gamedev-team/dbox
[3] : http://code.dlang.org/packages/dbox
May 23 2014
parent reply "Piotrek" <p nonexistent.pl> writes:
Hi,


nice one.
How does it compare to C++ version in terms of performance?

Piotrek
May 23 2014
parent reply Andrej Mitrovic via Digitalmars-d-announce writes:
On 5/24/14, Piotrek via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:
 nice one.
 How does it compare to C++ version in terms of performance?
I haven't tested the performance yet! I'm definitely interested, but as usual I assume LDC will probably beat DMD in this area.
May 23 2014
parent reply "Kiith-Sa" <kiithsacmp gmail.com> writes:
On Friday, 23 May 2014 at 22:52:53 UTC, Andrej Mitrovic via 
Digitalmars-d-announce wrote:
 On 5/24/14, Piotrek via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:
 nice one.
 How does it compare to C++ version in terms of performance?
I haven't tested the performance yet! I'm definitely interested, but as usual I assume LDC will probably beat DMD in this area.
Do you intend to keep this a straight port or will it be open to modifications? From a brief look at the source, it's possible I'll end up needing turning shapes from classes to structs and/or hooking it up with a custom allocator. I expect to need to spawn/destroy objects of varying shapes very often. (I do plan to try the current version first, though; it may be good enough) If I make such changes (which may affect the API, although the changes can probably be kept somewhat small), should I open a pull request or start a fork (ddbox? ;p)? (Same question applies to other of your ports)
May 24 2014
parent Andrej Mitrovic via Digitalmars-d-announce writes:
On 5/24/14, Kiith-Sa via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:
 Do you intend to keep this a straight port or will it be open to
 modifications?
I think we can create a new branch with API improvements and additions. I'm not sure what the state of dub support for this is, apparently branch-based dependencies are now deprecated? I hope we can do something like this: # Use the direct C++ Port "dependencies": { "dbox": ">=0.0.2", } # Use a new D-ified interface which has more features "dependencies": { "dbox": "d_api:>=0.0.2", } Can we do something like this already with dub? Andrei's allocators could come in very handy. I'm still unsure how we can actually hook up a custom allocator, you can't really do things like "$ dmd -alias allocator = mymodule.myallocator". As for actual behavioral changes, we better start adding unittests then. :) Btw, there's a Contributions folder in the Box2D distribution which I haven't ported, it has some cool features like fluids support. I'm not sure if it's the same as the following video, but the stuff is cool: https://www.youtube.com/watch?v=UKlkk3uCdJs
 From a brief look at the source, it's possible I'll end up
 needing turning shapes
 from classes to structs and/or hooking it up with a custom
 allocator.
I wanted to convert everything into structs, but the problem is the C++ library used inheritance and virtual methods even though in the end they end up using all of these objects as stack-allocated objects. I'm not sure whether we actually have to spawn a lot of shape objects though (AFAICT few of them ever get instantiated), but if that's true then converting these to structs might be beneficial.
I expect to need to spawn/destroy objects of varying
 shapes very often. (I do plan to try the current version first,
 though; it may be good enough)
Good luck!
 If I make such changes (which may affect the API, although the
 changes can probably be kept somewhat small), should I open a
 pull request or start a fork
 (ddbox? ;p)?
We could create a new branch, but for the moment you're probably better off not writing any pull requests since I will be MIA for a while (I'm moving very soon). I'll keep you updated.
 (Same question applies to other of your ports)
Same answer! :)
May 24 2014