https://github.com/AndrejMitrovic/dchip

What is Chipmunk2D?
===================

Chipmunk2D[1] is a 2D rigid body physics library distributed under the MIT license. It is intended to be blazingly fast, portable, numerically stable, and easy to use. It’s been used in hundreds of games across just about every system you can name. This includes top quality titles such as Night Sky for the Wii and many #1 sellers on the iPhone App Store.

Chipmunk2D is platform-independent and has no dependencies, other than for its test-suite which requires the GLFW library.

[1] : http://chipmunk-physics.net/release/ChipmunkLatest-Docs/

What is DChip?
==============

DChip[1] is a direct D2 port of the C library without no API changes. This ensures the documentation and tutorials for Chipmunk2D can be used with DChip with very little to no changes in code. See more information and building instructions at its github[1] page.

Note: There was a previous effort at porting the Chipmunk2D library to D called Chipmunkd[2], which was implemented by Stephan Dilly. Chipmunkd targets an older v5.3.5 version of Chipmunk2D and can be found at its bitbucket[2] page.

[1] : https://github.com/AndrejMitrovic/dchip
[2] : https://bitbucket.org/Extrawurst/chipmunkd

DChip targets the latest Chipmunk2D version (currently v6.2.1) and includes its GLFW-based test-suite which was ported to D.

Why a port and not a binding?
=============================

There are a number of reasons why a port was made and why it can be beneficial:

- The C library is relatively small, clocking in at about ~11.000
lines, + ~8.000 lines of test-suite code.
- With a port there's no need to worry about exception propagation
across language barriers.
- Less dependencies on external binaries or the requirement to build C
code with another compiler.
- Potential inlining opportunity.
- A physics library could be a good test to benchmark the various D compilers.
- The D codebase can serve as starter code for someone wanting to
implement their own physics library in D. The permissive MIT license
allows anyone to use the code for whichever purpose they may have.

https://github.com/AndrejMitrovic/dchip

On Sunday, 3 November 2013 at 05:08:40 UTC, Andrej Mitrovic wrote:
(...)
> DChip[1] is a direct D2 port of the C library without no API changes.
(...)

Nothing I have the need for, but very cool nontheless. It would be interesting if you wrote about your experience on porting a C codebase this size.

On 11/3/13, simendsjo <simendsjo@gmail.com> wrote:
> Nothing I have the need for, but very cool nontheless. It would be interesting if you wrote about your experience on porting a C codebase this size.

Nothing much new compared to the last time I ported C, which I wrote about here: http://forum.dlang.org/thread/mailman.1069.1308629671.14074.digitalmars-d-announce@puremagic.com?page=2#post-mailman.1084.1308684922.14074.digitalmars-d-announce:40puremagic.com

Of course I know much more now than I did back then. Maybe you meant like a blog post? I'll add it to my todo list. :)

On Sunday, 3 November 2013 at 15:16:09 UTC, Andrej Mitrovic wrote:
> On 11/3/13, simendsjo <simendsjo@gmail.com> wrote:
>> Nothing I have the need for, but very cool nontheless. It would
>> be interesting if you wrote about your experience on porting a C
>> codebase this size.
>
> Nothing much new compared to the last time I ported C, which I wrote about here:
> http://forum.dlang.org/thread/mailman.1069.1308629671.14074.digitalmars-d-announce@puremagic.com?page=2#post-mailman.1084.1308684922.14074.digitalmars-d-announce:40puremagic.com
>
> Of course I know much more now than I did back then. Maybe you meant
> like a blog post? I'll add it to my todo list. :)

Here's a little bug report. Don't know if it's my bad.

I'm running Ubuntu 12.04 (64-bit), compiler - DMD v2.063.2, DUB v0.9.17-29-g2be278a

I cloned the git repo (sha1 96a870e) and ran dub.

First-off, it complained about several 'cannot cast ulong to int'. I've fixed that with explicit casts.

Second, it complained about undefined reference to dlopen and friends. I've fixed that by adding
"libs": [
        "dl"
    ]
to package.json

And finally, I've got
object.Exception@src/rt/minfo.d(243): Aborting: Cycle detected between modules with ctors/dtors:
dchip.cpPolyShape -> dchip.chipmunk_private -> dchip.cpArbiter -> dchip.cpSpace -> dchip.cpSpaceStep -> dchip.cpCollision -> dchip.cpPolyShape

Which I don't know how to fix. Hope it'll be useful.

On 11/5/13, Sergei Nosov <sergei.nosov@gmail.com> wrote:
> Here's a little bug report. Don't know if it's my bad.

It's not your fault. And thanks for the report!

> First-off, it complained about several 'cannot cast ulong to int'. I've fixed that with explicit casts.

This is mostly the cause of the old C code which compiled without warnings. I've fixed this now.

> Second, it complained about undefined reference to dlopen and
> friends. I've fixed that by adding
> "libs": [
>          "dl"
>      ]
> to package.json

I've added it as a Posix flag, however do note that I still don't know whether the demo will work on Posix since I don't know how to load the glu library there. I'll have to investigate this in a virtual machine later.

> And finally, I've got
> object.Exception@src/rt/minfo.d(243): Aborting: Cycle detected
> between modules with ctors/dtors:
> dchip.cpPolyShape -> dchip.chipmunk_private -> dchip.cpArbiter ->
> dchip.cpSpace -> dchip.cpSpaceStep -> dchip.cpCollision ->
> dchip.cpPolyShape

I was afraid this was going to happen. As it stands D's module constructors are almost completely useless for real world code since this issue always pops up. Anyway I've replaced them with a single module constructor which calls initialization functions, so this is fixed now.

Thanks again for all the reports! And if you have new ones please do report them on the githup page, in the Issues section. Cheers.

On Tuesday, 5 November 2013 at 15:43:29 UTC, Andrej Mitrovic wrote:
> On 11/5/13, Sergei Nosov <sergei.nosov@gmail.com> wrote:
>> Here's a little bug report. Don't know if it's my bad.
>
> It's not your fault. And thanks for the report!
>
>> First-off, it complained about several 'cannot cast ulong to
>> int'. I've fixed that with explicit casts.
>
> This is mostly the cause of the old C code which compiled without
> warnings. I've fixed this now.
>
>> Second, it complained about undefined reference to dlopen and
>> friends. I've fixed that by adding
>> "libs": [
>>          "dl"
>>      ]
>> to package.json
>
> I've added it as a Posix flag, however do note that I still don't know
> whether the demo will work on Posix since I don't know how to load the
> glu library there. I'll have to investigate this in a virtual machine
> later.
>
>> And finally, I've got
>> object.Exception@src/rt/minfo.d(243): Aborting: Cycle detected
>> between modules with ctors/dtors:
>> dchip.cpPolyShape -> dchip.chipmunk_private -> dchip.cpArbiter ->
>> dchip.cpSpace -> dchip.cpSpaceStep -> dchip.cpCollision ->
>> dchip.cpPolyShape
>
> I was afraid this was going to happen. As it stands D's module
> constructors are almost completely useless for real world code since
> this issue always pops up. Anyway I've replaced them with a single
> module constructor which calls initialization functions, so this is
> fixed now.
>
> Thanks again for all the reports! And if you have new ones please do
> report them on the githup page, in the Issues section. Cheers.

It seems to work now! I've send you a little pull request fixing glu loading on my Ubuntu setup.

On 11/6/13, Sergei Nosov <sergei.nosov@gmail.com> wrote:
> It seems to work now! I've send you a little pull request fixing glu loading on my Ubuntu setup.

Merged. And thanks!

On 11/6/13, Sergei Nosov <sergei.nosov@gmail.com> wrote:
> It seems to work now! I've send you a little pull request fixing glu loading on my Ubuntu setup.

Btw, which compiler are you using? Could you try running on LDC/GDC if you have that installed and see if there's any performance difference?

I would have tried this myself on Windows, but LDC produces crashing apps, and the last version of a packaged GDC zip file doesn't work either.

On Wednesday, 6 November 2013 at 18:15:58 UTC, Andrej Mitrovic wrote:
> On 11/6/13, Sergei Nosov <sergei.nosov@gmail.com> wrote:
>> It seems to work now! I've send you a little pull request fixing
>> glu loading on my Ubuntu setup.
>
> Btw, which compiler are you using? Could you try running on LDC/GDC if
> you have that installed and see if there's any performance difference?
>
> I would have tried this myself on Windows, but LDC produces crashing
> apps, and the last version of a packaged GDC zip file doesn't work
> either.

It gets me some errors when building with LDC:
Error: ~/dchip/.dub/build/demo-debug-x86_64-ldmd2-DA39A3EE5E6B4B0D3255BFEF95601890AFD80709/new_demo: No such file or directory

But it produces cpConstraint executable, which runs, and shows the demos. The heaviest I found was on the letter G (you have a screenshot of this demo on github). I don't have the numbers (I didn't find where to look for the FPS), but it hinders exactly the same as dmd.

I didn't have a chance to look more closely, maybe it's just me.

>The C library is relatively small, clocking in at about ~11.000
lines
Do I right understand that rewriting code from C to D did not make it's more compact? I tried to calculate D source lines, and get ~11.000