digitalmars.D.announce - dchip is a D2 port of the Chipmunk2D physics library for 2D games
- Andrej Mitrovic (44/44) Nov 02 2013 https://github.com/AndrejMitrovic/dchip
- simendsjo (6/8) Nov 03 2013 (...)
- Andrej Mitrovic (5/8) Nov 03 2013 Nothing much new compared to the last time I ported C, which I wrote abo...
- Sergei Nosov (20/31) Nov 05 2013 Here's a little bug report. Don't know if it's my bad.
- Andrej Mitrovic (15/30) Nov 05 2013 This is mostly the cause of the old C code which compiled without
- Sergei Nosov (4/43) Nov 05 2013 It seems to work now! I've send you a little pull request fixing
- Andrej Mitrovic (2/4) Nov 06 2013 Merged. And thanks!
- Andrej Mitrovic (6/8) Nov 06 2013 Btw, which compiler are you using? Could you try running on LDC/GDC if
- Sergei Nosov (12/25) Nov 06 2013 It gets me some errors when building with LDC:
- Andrej Mitrovic (4/7) Nov 07 2013 Hmm, I have the same issue. It might be an issue with the port. Or
- Andrej Mitrovic (10/11) Nov 07 2013 I did some profiling. I had some excessive opengl error check calls,
- Andrej Mitrovic (6/8) Nov 07 2013 Well, as long as you use float and not double via
- Sergei Nosov (55/67) Nov 10 2013 I've done some experiments regarding dmd/ldc comparison.
- Andrej Mitrovic (3/15) Nov 11 2013 Cool! Thanks for benchmarking.
- Sergei Nosov (5/20) Nov 11 2013 In my version of dub it's "-release -inline -O". I've tried also
- Andrej Mitrovic (3/6) Nov 11 2013 What about using -version=CHIP_USE_DOUBLES ? I get quite a slowdown
- Sergei Nosov (24/34) Nov 11 2013 For some reason, DMD (v2.064.2) fails to compile with that flag.
- Andrej Mitrovic (7/12) Nov 12 2013 Interesting. Thanks.
- Dicebot (6/11) Nov 12 2013 It is done via package.json modification, for whole project or
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (4/17) Nov 12 2013 Beat me to it... again ;)
- =?ISO-8859-1?Q?S=F6nke_Ludwig?= (20/27) Nov 12 2013 If it's just temporary, this should work:
- Suliman (4/5) Nov 06 2013 lines
- Rory McGuire (2/7) Nov 07 2013
- Andrej Mitrovic (2/7) Nov 07 2013 I did not refactor, it's a straight port.
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 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
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
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
On Sunday, 3 November 2013 at 15:16:09 UTC, Andrej Mitrovic wrote:On 11/3/13, simendsjo <simendsjo gmail.com> wrote: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.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 05 2013
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.jsonI'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.cpPolyShapeI 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
On Tuesday, 5 November 2013 at 15:43:29 UTC, Andrej Mitrovic wrote:On 11/5/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.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.jsonI'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.cpPolyShapeI 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
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
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
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 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.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
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
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
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
On Friday, 8 November 2013 at 04:39:11 UTC, Andrej Mitrovic wrote:On 11/8/13, Andrej Mitrovic <andrej.mitrovich 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 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.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 10 2013
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=3Dldc2Which 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
On Monday, 11 November 2013 at 15:29:20 UTC, Andrej Mitrovic wrote:On 11/11/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.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=ldc2Which flags does release imply?
Nov 11 2013
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
On Tuesday, 12 November 2013 at 04:07:14 UTC, Andrej Mitrovic wrote: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 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.6212In 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
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 1Aww. 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
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
Am 12.11.2013 16:55, schrieb Dicebot:On Tuesday, 12 November 2013 at 15:39:27 UTC, Andrej Mitrovic wrote:Beat me to it... again ;) Correction of my previous reply: DFLAGS="-release -O -inline -version=CHIP_USE_DOUBLES" dubBtw, 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
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
The C library is relatively small, clocking in at about ~11.000lines 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
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.000lines 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
On 11/7/13, Suliman <bubnenkoff gmail.com> wrote:I did not refactor, it's a straight port.The C library is relatively small, clocking in at about ~11.000lines 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
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
On Friday, 8 November 2013 at 05:04:45 UTC, Suliman wrote: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.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 09 2013