www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dchip is a D2 port of the Chipmunk2D physics library for 2D games

reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
https://github.com/AndrejMitrovic/dchip

What is Chipmunk2D?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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=92s 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?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

There are a number of reasons why a port was made and why it can be benefic=
ial:

- 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 compile=
rs.
- 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
Nov 02 2013
next sibling parent reply "simendsjo" <simendsjo gmail.com> writes:
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.
Nov 03 2013
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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. :)
Nov 03 2013
parent reply "Sergei Nosov" <sergei.nosov gmail.com> writes:
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.
Nov 05 2013
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Nov 05 2013
parent reply "Sergei Nosov" <sergei.nosov gmail.com> writes:
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.
Nov 05 2013
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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!
Nov 06 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Nov 06 2013
parent reply "Sergei Nosov" <sergei.nosov gmail.com> writes:
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-DA39A3EE5E6B4B0D3255BFEF956018 0AFD80709/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.
Nov 06 2013
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/7/13, Sergei Nosov <sergei.nosov gmail.com> wrote:
 I don't have the numbers (I
 didn't find where to look for the FPS), but it hinders exactly
 the same as dmd.
Hmm, I have the same issue. It might be an issue with the port. Or worse-case scenario, something wrong with the front-end (since all 3 major compilers use the same front-end).
Nov 07 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/7/13, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 Hmm, I have the same issue. It might be an issue with the port.
I did some profiling. I had some excessive opengl error check calls, which I've fixed in git-head. And I was wrong about -O not working, it works but it takes ~1-2 minutes to compile. Anyway in -release -inline -O -noboundscheck mode the sample now works perfectly smooth! In debug mode it's a little slow, but this is expected as the C++ sample also lags a lot in debug mode. What's really interesting is that DMD beats VC in debug mode, but maybe this has something to do with debug information that VC includes in a debug build (perhaps profiling hooks? who knows..)
Nov 07 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/8/13, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 Anyway in -release -inline -O -noboundscheck mode the sample now works
 perfectly smooth!
Well, as long as you use float and not double via -version=CHIP_USE_DOUBLES . Chipmunk actually uses doubles by default, although I'm not sure whether it uses reals for computations (more specifically, whether VC/C++ uses reals). So there's a difference there.
Nov 07 2013
parent reply "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Friday, 8 November 2013 at 04:39:11 UTC, Andrej Mitrovic wrote:
 On 11/8/13, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 Anyway in -release -inline -O -noboundscheck mode the sample 
 now works
 perfectly smooth!
Well, as long as you use float and not double via -version=CHIP_USE_DOUBLES . Chipmunk actually uses doubles by default, although I'm not sure whether it uses reals for computations (more specifically, whether VC/C++ uses reals). So there's a difference there.
I've done some experiments regarding dmd/ldc comparison. Machine: Ubuntu 12.04 (x86_64), Intel® Core™ i5-3470 CPU 3.20GHz × 4 Compilers: DMD64 D Compiler v2.064, LDC - the LLVM D compiler (0.12.0): based on DMD v2.063.2 and LLVM 3.3.1 Default target: x86_64-unknown-linux-gnu Host CPU: core-avx-i I've made 2 builds: $ dub --build=release $ dub --build=release --compiler=ldc2 And 2 runs of new_demo -bench -trial (note, I've modified the source to make both keys usable simultaneously) It runs a 1000 iteration for every demo in 'bench' set and prints it's time in ms. DMD output: 5105.89 2451.94 477.079 12709.9 4259.14 775.686 8842.77 4233.86 784.804 939.7 1643.85 1589.28 5368.47 11042.3 380.893 740.671 9.53658 LDC output: 4645.74 2236.77 434.833 10483.6 3577.5 693.307 7339.49 3445.02 627.396 856.486 1291.23 1333.11 4831.46 9002.18 361.624 605.19 9.64545 So, the ratio is something like 0.81-0.83 in favor of ldc.
Nov 10 2013
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/11/13, Sergei Nosov <sergei.nosov gmail.com> wrote:
 I've done some experiments regarding dmd/ldc comparison.

 Machine: Ubuntu 12.04 (x86_64), Intel=AE Core=99 i5-3470 CPU  
 3.20GHz =D7 4
 Compilers: DMD64 D Compiler v2.064, LDC - the LLVM D compiler
 (0.12.0):
    based on DMD v2.063.2 and LLVM 3.3.1
    Default target: x86_64-unknown-linux-gnu
    Host CPU: core-avx-i

 I've made 2 builds:
 $ dub --build=3Drelease
 $ dub --build=3Drelease --compiler=3Dldc2
Which flags does release imply?
 So, the ratio is something like 0.81-0.83 in favor of ldc.
Cool! Thanks for benchmarking.
Nov 11 2013
parent reply "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Monday, 11 November 2013 at 15:29:20 UTC, Andrej Mitrovic 
wrote:
 On 11/11/13, Sergei Nosov <sergei.nosov gmail.com> wrote:
 I've done some experiments regarding dmd/ldc comparison.

 Machine: Ubuntu 12.04 (x86_64), Intel® Core™ i5-3470 CPU  
 3.20GHz × 4
 Compilers: DMD64 D Compiler v2.064, LDC - the LLVM D compiler
 (0.12.0):
    based on DMD v2.063.2 and LLVM 3.3.1
    Default target: x86_64-unknown-linux-gnu
    Host CPU: core-avx-i

 I've made 2 builds:
 $ dub --build=release
 $ dub --build=release --compiler=ldc2
Which flags does release imply?
In my version of dub it's "-release -inline -O". I've tried also adding the -noboundscheck flag and it yielded the same results. I guess the setup for ldc is similar.
Nov 11 2013
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/12/13, Sergei Nosov <sergei.nosov gmail.com> wrote:
 In my version of dub it's "-release -inline -O". I've tried also
 adding the -noboundscheck flag and it yielded the same results. I
 guess the setup for ldc is similar.
What about using -version=CHIP_USE_DOUBLES ? I get quite a slowdown when using it with DMD, I'm wondering whether it's compiler-specific.
Nov 11 2013
parent reply "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Tuesday, 12 November 2013 at 04:07:14 UTC, Andrej Mitrovic 
wrote:
 On 11/12/13, Sergei Nosov <sergei.nosov gmail.com> wrote:
 In my version of dub it's "-release -inline -O". I've tried 
 also
 adding the -noboundscheck flag and it yielded the same 
 results. I
 guess the setup for ldc is similar.
What about using -version=CHIP_USE_DOUBLES ? I get quite a slowdown when using it with DMD, I'm wondering whether it's compiler-specific.
For some reason, DMD (v2.064.2) fails to compile with that flag. The error is: Internal error: ../ztc/cg87.c 331 Error: DMD compile run failed with exit code 1 LDC slows down for about 20-25%. Timings: 5797.39 2779.01 537.136 13459.3 4483.73 865.685 9324.52 4311.65 809.551 1088.42 1705.75 1701.38 6041.41 11310.5 409.587 726.283 10.6212
Nov 11 2013
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/12/13, Sergei Nosov <sergei.nosov gmail.com> wrote:
 For some reason, DMD (v2.064.2) fails to compile with that flag.
 The error is:
 Internal error: ../ztc/cg87.c 331
 Error: DMD compile run failed with exit code 1
Aww. If only dub knew how to automatically run dustmite.
 LDC slows down for about 20-25%.
Interesting. Thanks. Btw, how did you make dub use a -version flag anyway? I can't figure it out from the docs. I suppose it's something like: dub --build=release --version=? But I see that --version means something else in dub.
Nov 12 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 12 November 2013 at 15:39:27 UTC, Andrej Mitrovic 
wrote:
 Btw, how did you make dub use a -version flag anyway? I can't 
 figure
 it out from the docs. I suppose it's something like:

 dub --build=release --version=?

 But I see that --version means something else in dub.
It is done via package.json modification, for whole project or some specific configurations : code.dlang.org/package-format Also: "Note that setting the DFLAGS environment variable will override the build type with custom flags." (c) dub
Nov 12 2013
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 12.11.2013 16:55, schrieb Dicebot:
 On Tuesday, 12 November 2013 at 15:39:27 UTC, Andrej Mitrovic wrote:
 Btw, how did you make dub use a -version flag anyway? I can't figure
 it out from the docs. I suppose it's something like:

 dub --build=release --version=?

 But I see that --version means something else in dub.
It is done via package.json modification, for whole project or some specific configurations : code.dlang.org/package-format Also: "Note that setting the DFLAGS environment variable will override the build type with custom flags." (c) dub
Beat me to it... again ;) Correction of my previous reply: DFLAGS="-release -O -inline -version=CHIP_USE_DOUBLES" dub
Nov 12 2013
prev sibling parent =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 12.11.2013 16:39, schrieb Andrej Mitrovic:
 Btw, how did you make dub use a -version flag anyway? I can't figure
 it out from the docs. I suppose it's something like:
 
 dub --build=release --version=?
 
 But I see that --version means something else in dub.
 
If it's just temporary, this should work: DFLAGS=-version=X dub --build=release But for regular version flags that should be accessible to high level packages in a prominent way, the best way is to define two separate configurations and use the "versions" field: { ... "configurations" { { "name": "single", }, { "name": "double", "versions": ["CHIP_USE_DOUBLES"] } } } And then build with dub --build=release --config=double
Nov 12 2013
prev sibling parent reply "Suliman" <bubnenkoff gmail.com> writes:
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
Nov 06 2013
next sibling parent Rory McGuire <rjmcguire gmail.com> writes:
It's just a port so that should be the case.
On 7 Nov 2013 09:25, "Suliman" <bubnenkoff gmail.com> wrote:

 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
Nov 07 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/7/13, Suliman <bubnenkoff gmail.com> wrote:
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
I did not refactor, it's a straight port.
Nov 07 2013
parent reply "Suliman" <evermind live.ru> writes:
 I did not refactor, it's a straight port.
Could you say how much code lines can be approximately saved after porting with refactoring?
Nov 07 2013
parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Friday, 8 November 2013 at 05:04:45 UTC, Suliman wrote:
 I did not refactor, it's a straight port.
Could you say how much code lines can be approximately saved after porting with refactoring?
This question doesn't make much sense. I guess one could write the same thing from scratch in D in half the LOC. But a reduced line count wouldn't be the only benefit, a more maintainable and safer codebase would be other benefits.
Nov 09 2013