Not logged inGosu Forums
Forum back to libgosu.org Help Search Register Login
Up Topic Gosu / Extending Gosu / Ruby bindings for Chipmunk 5.3.4
- - By beoran Date 2011-05-01 14:51
Chipmunk is a 2D game dynamics library that allows you to accurately simulate the physics of your game and do collision detection and response easily.

I have updated banisterfiend's and my Ruby bindings to Chipmunk to version 5.3.4. These bindings are based on the bindings to chipmunk 5.1.0, and include the improvements in the default ruby bindings included with Chipmunk, but also many other extras such as support for Abiters, callback objects, sleeping bodies, and more. Contrary to chipmunk-ffi, these bindings are a C extension for speed. But they should be mostly compatibe with chimunk-ffi. You can find these bindings here:

http://github.com/beoran/chipmunk

The ruby bindings have full rspec specifications, and are also fully documented with hand-crafted documentation (not autogenerated) here:

http://beoran.github.com/chipmunk/

A ruby gem was released on rubygems.org, including a binary one for use on windows with RubyInstaller 1.9.2, so feel free test it!
Any questions about these bindings or chipmunk are also welcome.

B.
Parent - - By Spooner Date 2011-05-01 17:30 Edited 2011-05-01 17:51
Thanks! Glad to see the binary bindings getting some love after a long gap (I've never managed to get ffi to work on Win7x64 with Ruby 1.9.2).

Quite a few of the features that seem to be in this version I was annoyed at not finding in the previous version (specifically layers, groups, Shape#object attribute and probably other stuff I can't remember, which I think I implemented, to an extent, in Ruby). Just tested my game, Wrath and it still works, but it only uses extremely simplistic physics (mainly just using it as a fast collision detector).

* Using 1.9.2 on Windows (from installer) I needed to manually specify the platform ('gem install chipmunk --platform=mswin32') in order to get the binary gem. Needs a mingw32 version uploading).

* IRB seg-faults when I run "CP::Shape::Circle.new()", AFTER it tells me I am giving the wrong number of arguments! I shouldn't be calling it without args, but it shouldn't die on me :)

Looking at the docs, there are a number of things I might want to change in my game now :). I will bug you about things soon, don't worry :P

EDIT: Just got a seg-fault on CP::Space#remove_shape in a quick test of existing, stable code! Think I'll roll back to the old version for a bit :(
Parent - - By beoran Date 2011-05-01 21:15
Dear Spooner, you're right on all accounts. Please make issues about these tpoints on github, I'll look into it asap.
Parent - - By Spooner Date 2011-05-01 22:45
Reported. Sorry, should have done that directly!
Parent - By beoran Date 2011-05-02 10:13
Thanks for your reports! No need to apologize. :) This thread is also for your comments, just that I like the issues to be reported so I don' t forget about them.
Parent - - By Spooner Date 2011-05-12 20:43 Edited 2011-05-12 21:27
Hmm, I can't manage to install this on Linux (Kubuntu 10.something). I still am able to install the old version of the gem (Banisterfiend's), so I have those dependencies met, but I can't find any information about what I actually need to do to allow the gem to compile from source.

EDIT: It just fails to find chipmunk.h in the places it expects it to be.
Parent - - By RavensKrag Date 2011-05-12 21:54
I have the same problem.  I assume that you need the dev headers for Chipmunk installed or something like that.  If you build the C version of chipmunk, install that, and then install this C extension, it should work fine.  I believe you will need to build the chipmunk.so so that the gem can be built correctly.  Something about dynamic linking I presume? (I don't really know much C...)  At any rate, instead of the standard cmake command, use the following command instead.

cmake -D BUILD_SHARED=ON .

Don't forget that period at the end.

Then install as normal from-source packages are installed.

Also, this should resolve all dependencies on *buntu systems.
sudo apt-get install libglut-dev libxi-dev libxmu-dev

A nice side benefit of this is that you get the C demos for chipmunk built as well.  On that note, does anyone know if the demos were ever successfully ported to ruby? I believe I have a rather good conception of how the library works, so if there is the demand for it, perhaps I could put some work into that.  The demos are quite helpful in demonstrating what can be done with the library, from things as complex as modifying the velocity functions to simulate inter-planetary gravity, to the more basic examples which show how the different constraints function.
Parent - - By Spooner Date 2011-05-12 22:42
It is, I think, libglut3-dev (at least, that is all I could find with a name like that); thanks for the info.

I cloned the Chipmunk project from SVN, did the 'cmake' that you gave me, then a 'make' and a 'make install' and then manually moved the generated 'libchipmunk.so' to 'chipmunk.so' inside the gem intallation and I won. Sort of. The chipmunk demo works, anyway! Now at:

/home/spooner/.rvm/gems/ruby-1.9.2-p0/gems/chipmunk-5.3.4.0/lib/chipmunk.so: undefined symbol: Init_chipmunk - /home/spooner/.rvm/gems/ruby-1.9.2-p0/gems/chipmunk-5.3.4.0/lib/chipmunk.so (LoadError)
        from /home/spooner/.rvm/gems/ruby-1.9.2-p0/gems/chipmunk-5.3.4.0/lib/chipmunk.rb:14:in rescue in <top (required)>'
        from /home/spooner/.rvm/gems/ruby-1.9.2-p0/gems/chipmunk-5.3.4.0/lib/chipmunk.rb:7:in
<top (required)>'
        from /home/spooner/RubymineProjects/wrath/lib/wrath/game.rb:17:in require'
        from /home/spooner/RubymineProjects/wrath/lib/wrath/game.rb:17:in
<top (required)>'
        from /home/spooner/RubymineProjects/wrath/lib/wrath.rb:1:in require_relative'
        from /home/spooner/RubymineProjects/wrath/lib/wrath.rb:1:in
<top (required)>'
        from bin/wrath.rbw:26:in require_relative'
        from bin/wrath.rbw:26:in
<main>'


Thanks for the poke in the right direction, even if it didn't quite get me there! However, it does seem like a significant number of manual steps compared to just using apt-get :(. Certainly too much to expect even a penguinite to trudge though without a clear set of instructions (that we know work :P).
Parent - - By beoran Date 2011-05-14 20:06
The libchipmunk.so  is the C library for chipmunk ,wherease the chipmunk.so is for Ruby. You shouln't overwrite one with the other. In stead, libchipunk.so should be installed correctly in /sur/local/lib or /usr/lib if you do make install in the C chipmunk project. This should also copy the c chipmunk.h header to /usr/local/include or /usr/include. Once all that's ok, building the gem on Linux should "just work".
Parent - By Spooner Date 2011-05-14 21:28
Yes, I tried that, but it failed so I floundered a bit and messed with the .so directly (which, as you say, was madness).

After installing Chipmunk, the .so and symlink are there:
  spooner@Fish:~/chipmunk-physics-read-only$ ls /usr/local/lib/libchipmunk*
  /usr/local/lib/libchipmunk.a  /usr/local/lib/libchipmunk.so  /usr/local/lib/libchipmunk.so.5.3.4

Installing the gem goes fine:
  spooner@Fish:~/RubymineProjects/wrath$ gem install chipmunk
  Fetching: chipmunk-5.3.4.0.gem (100%)
  Building native extensions.  This could take a while...
  Successfully installed chipmunk-5.3.4.0
  1 gem installed

In IRB:
  ruby-1.9.2-p0 :002 > require 'chipmunk'
  LoadError: libchipmunk.so.5.3.4: cannot open shared object file: No such file or directory - /home/spooner/.rvm/gems/ruby-1.9.2-p0/gems/chipmunk-5.3.4.0/lib/chipmunk.so

The gem .so file is definitely there:
  spooner@Fish:~/RubymineProjects/wrath$ ls /home/spooner/.rvm/gems/ruby-1.9.2-p0/gems/chipmunk-5.3.4.0/lib         
  chipmunk.rb  chipmunk.so

I don't use Linux much, so I do get stuck when things don't go as simply as they could.
Parent - - By beoran Date 2011-05-14 20:02
RavensKrag is right, my version on of the gem doesn't vendor correctly chipmunk anymore. I think I accidentally broke that, :-p.  So you need to install chipmunk separately, either using your package manager or manually.  I'll look into bringing back the vendoring of chipmunk.

As for the port of the C demos to ruby, I never finished that, and I won't have time for it anytime soon. So if you'd like to contribute to translate these demos that would be awesome. :)

Kind Regards, B.
Parent - - By Spooner Date 2011-05-14 20:03
Thanks for looking into this! I've rolled back to 5.2.2 until this is resolved, so I am not chasing you with a stick :)
Parent - By beoran Date 2011-05-14 20:38
OK, thanks. Banisterfiend simply included the chipmunk sources right into the extension which is not very clean. I'll try to find a cleaner way to reinstate vendoring chipmunk, and also allow compiling against an external chipmunk library.
Parent - By beoran Date 2011-05-14 22:26
OK, now I allowed vendoring again in the head of my github repository. There are still other bugs, though, so I can't make a new gem just yet.
Parent - - By beoran Date 2011-05-21 12:33
A new gem for version 5.3.4.2 is out that fixes several bugs and re-vendors chipmunk. Try it! :)
Parent - - By RunnerPack Date 2011-05-21 19:07
C:\>ruby -v
ruby 1.9.2p136 (2010-12-25) [i386-mingw32]

C:\>gem -v
1.8.3

C:\>gem lis chip

*** LOCAL GEMS ***

chipmunk (5.3.4.0 x86-mingw32)

C:\>gem upd
Updating installed gems
Updating chipmunk
ERROR:  While executing gem ... (ArgumentError)
    undefined class/module YAML::PrivateType
Parent - By beoran Date 2011-05-21 19:29
Strange, I though I had solved this problem.. Probably it's due to my RVM rubygems not being up to date. I'll try to solve this ASAP.
Parent - - By beoran Date 2011-05-21 21:10
Hmmm... now rake_compiler doesn't work corectly anymore. I can't build Windows gems without it, so looks like you'll have to wait some more.
Parent - - By RunnerPack Date 2011-05-21 22:19
That's fine; I'm in no hurry. Just keeping you apprised of the situation ;)
Parent - By beoran Date 2011-05-22 22:10 Edited 2011-05-22 22:16
Yes, but I feel like I should fix this for you an all other people who want to use chipmunk. Unfortunately, it seems like I'm stuck in a web of incompatiblilities of the build tools. Rubygems 1.8.3 isn't compatible with older versions, like 1.3.x, of itself anymore. Rubygems 1.8.3 requires the use of Rake 0.9, which is incompatible with rake-compiler. Hilarity ensures... not! :p

Now I'm faced with the choice of downgading my rubygems and releasing a gem that won't work for people who use a recent version of rubygems, or wait until the upstreams resolve this cluster copulation of incompatibilities. The first case is of no help for you and anyone who has an up-to-date rubygems, the latter is of no help to anyone. I'll just note in the README that for now the gem method of installing is deprecated and a manual install is recommended. :/
Parent - - By jlnr (dev) Date 2011-05-23 08:32
Still doesn't work for me, which either means it does not contain the chipmunk source or it doesn't limit the architectures it is building for. The first one would be nicer (and cleaner) of course :)
Parent - - By beoran Date 2011-05-23 16:27
What error messages do you get? If its just due to the C sources missing in the gem, that should be easy enough to fix.
Parent - - By jlnr (dev) Date 2011-05-23 17:13
Still the first one from the issue I filed. Bundling the source with the gem again would likely fix everything.
Parent - - By beoran Date 2011-05-23 20:11
OK, I've downgraded my rubygems to 1.6.1 and now I've been able to build binary gems for windows and source gems for Linux and OS/X again. I've pushed them as chipmunk-5.3.4.3-x86-mingw32.gem and chipmunk-5.3.4.3.gem  respectively.

I really hope these gems work now. I checked the gems themselves with tar and the source code is correctly included. I hope these gems will work and not bomb out with rubygems 1.8.3.

Thanks to all of you for your patience.

B.
Parent - - By jlnr (dev) Date 2011-05-23 21:20
Now it fails with these errors:

> i686-apple-darwin10-gcc-4.2.1: ./vendor/chipmunk-5.3.4/src/chipmunk.o: No such file or directory
> i686-apple-darwin10-gcc-4.2.1: ./vendor/chipmunk-5.3.4/src/cpArbiter.o: No such file or directory
> i686-apple-darwin10-gcc-4.2.1: ./vendor/chipmunk-5.3.4/src/cpArray.o: No such file or directory


The .o files all exist, but they are located directly in ext/chipmunk (= current directory), not ext/chipmunk/vendor/chipmunk-5.3.4.
Parent - By beoran Date 2011-05-24 05:55
Hmmm, looks like my cleaner way of vendoring chipmunk is causing a few problems on OSX... If that's the case I'll probably revert it to doing it in the "dirty" way yet again, even if I dislike that way.
Parent - - By beoran Date 2011-05-24 17:59
Ok, I've pushed chipmunk-5.3.4.4 and also a new windows version. This time chipmunk is vendored in the old fashion "dirty" way again.
I hope this time it will work for all platforms.

As a result, it became impossible again to unvendor chipmunk. Ah, well, I guess it's good for performance
and easier for people who want to distribute a Ruby game. :o)
Parent - - By jlnr (dev) Date 2011-05-24 18:19
Seems to work. Have not tested any games yet but the gem installation went smoothly. Big kudos for fixing this!
Parent - - By beoran Date 2011-05-24 21:00
And you're welcome. Good to hear that it finally installs! Please do test it, as the devil's in the dark details. :p
Parent - By jlnr (dev) Date 2011-05-25 01:20
Sure. Hope to catch Spooner for a new Wrath build soon :) After that I can precompile the new gem for OS X and include it in the .app wrapper.
Parent - - By RunnerPack Date 2011-05-31 10:16
Installs for me on Win XP. Is there any example code out there with which to test it?
Parent - By beoran Date 2011-06-01 20:00
Unfortunately, the example code hasn't been ported from C yet, but you can check and run the specifications with rspec:

https://github.com/beoran/chipmunk/tree/master/spec

Also, please read the fine manual :)

http://beoran.github.com/chipmunk/

Suggestions on how to improve the manual are welcome.
Parent - - By Spooner Date 2011-06-07 18:20
I've finally got around to updating my game to use the latest Chipmunk. Particular new features I was able to use was layers and groups which I had sort of implemented in my collision call-backs, which saves me running that code in Ruby :). Also used convenience stuff like StaticBody, Shape#object and vec2() which weren't previously available. Not a huge amount of CPU saved (if any), but a bit less code to maintain!

Sensible that Shape#collision_type has been made into a Ruby symbol, but I wasn't sure why #group wasn't also implemented as a symbol (it is just an integer currently, as I assume #collision_type is in C++ Chipmunk).

You did suggest that you could provide more general answers to Chipmunk problems:

* In my game I managing velocity myself, outside of Chipmunk (chipmunk is there for collisions and sensors, not movement itself, which I want to feel like an old-fashioned computer game, rather than a bouncy physics simulation).Heavy damping is on (#damping = 0) and I #apply_force to each object, run 2 physics frames, then #reset_forces (this in each Gosu frame). This mostly works, but I'm not convinced it is the right way. Should I be using #slew or another method?

* I am struggling a bit with fast-moving objects passing outside my screen (it is wrapped with segments). I assume the only thing I can do to stop this is to limit the velocity of objects or run more physics frames per second? Changing the number of physics frames, however, changes the physics considerably, because of the way I'm applying forces (I think). It would also reduce my CPU time, which is not unlimited...
Parent - - By erisdiscord Date 2011-06-08 03:37
I can't answer most of your questions with any authority, but I'd like to weigh in on one thing.

> I wasn't sure why #group wasn't also implemented as a symbol


From the Chipmunk docs:

> group: Shapes in the same non-zero group do not generate collisions. Useful when creating an object out of many shapes that you don't want to self collide. Defaults to 0;


The special treatment of 0 here would mean that the Ruby wrapper would need to do some behind-the-scenes conversion. Assuming you want nil to be the "normal" group, you'd either have to make 0 and nil both set the internal value to 0 (strange and unexpected behavior for Ruby, and lossy) or risk breaking compatibility with existing programs (0 might be set explicitly). I would lean towards the second as more-correct behavior, but~
Parent - - By Spooner Date 2011-06-08 09:55
But there aren't existing programs in Chipmunk that use group, since group was added in this release. Since collision_type is a symbol, I assume that also is wrapped around an integer, but it could just be some sugar for the Ruby version.

Group would be nil or :symbol (which would, in C++, be translated to 0 or Symbol#to_hash respectively). No reason to allow numbers to be used. Alternatively, it could be :no_group instead of nil.

Regarding my issues with general usage, I ended up using twice as many physics steps, but also ensuring that they were all of consistent length, which didn't affect FPS significantly. Skew caused problems, since it seemed to move objects through other objects without collision.
Parent - - By erisdiscord Date 2011-06-08 14:56
Oh, I didn't know it was new to the Ruby API. I think it was in chipmunk-ffi already?

I think I recall that chipmunk-ffi allows arbitrary objects for collision_type, which is potentially useful because you could have a set of standard collision_type objects that determine additional collision behavior. On the C side, the collision type is just set to the object's id. Doing the same for group might be useful in some cases, so why not make it possible?
Parent - - By Spooner Date 2011-06-08 15:42
It is new to the binary chipmunk gem. I was aware that the ffi version was more modern, but I could not get ffi to work on Windows/1.9.2, so I ignored it :P If it worked properly for everyone and was being updated, I can't really see any reason to update this version of the bindings - we don't really need two sets. Although ffi is slower per-call, Chipmunk isn't called too often (that is, you just call its methods on creation of new shapes and a few steps a frame); most of the work is in processing and callbacks.

The use of arbitrary objects seems sensible, though it only really makes sense if that object is queried/callbacked about the collisions in some way too (otherwise, might as well just use symbols).
Parent - - By shawn42 Date 2011-06-13 17:53
Unfortunately the cost of FFI can be great. There is a lot of overhead for a few things like vec2() that can really slow performance if you are creating a lot of vectors. I think it's great that we have both versions of the chipmunk wrapper, let me know if there's anything missing or wrong in the FFI version that I can help with.  Can you write up an issue for the windows problem https://github.com/shawn42/chipmunk-ffi/issues

Thanks.
Parent - By Spooner Date 2011-06-13 18:06 Edited 2011-06-23 17:13
I am pretty sure that my problem is all about FFI and not chipmunk-ffi itself. I'll write up what I have though.

EDIT: Just so I don't mislead, the problem I used to have with FFI/Chipmunk is no longer apparent, so disregard my previous comments about it.
Up Topic Gosu / Extending Gosu / Ruby bindings for Chipmunk 5.3.4

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill