TIGSource has an official Discord server now!LINK: https://discord.gg/m9fBD8V
Welcome, Guest. Please login or register. 1 Hour 1 Day 1 Week 1 Month Forever Login with username, password and session length Advanced search 1411609 Posts in 69672 Topics- by
- Latest Member: sevdoesgamesDecember 01, 2024, 08:06:38 PM Need hosting? Check out Digital Ocean
slembcke Level 3     |  | Chipmunk Physics and Box2D comparison « on: November 17, 2009, 10:10:58 PM » |
Hey. I've been a long time lurker around these forums, but have never really participated actively. I'm skorche on the iDevGames forums and slembcke just about everywhere else.I'm sure some of you around these parts have heard of or used the Chipmunk Physics library. (YouTube can help you if you haven't: Big Ol' Chipmuk Playlist) Anywho, I've been writing Chipmunk in my spare time for a while now. Progress is sort of slow now that I'm not in school anymore, but I'm pretty proud of where it's gotten to. I've actually had people in real life recognize my name and ask if I'm the guy that wrote Chipmunk. Very gratifying.  I don't see Chipmunk as competing with Box2D. Both are open source, fun, free time projects. Chipmunk was highly inspired by a tech demo of Box2D a couple of years before it was released as a usable library. I had been trying to build a good physics library for some time and already had my own collision detection primitives, broadphase implementation, and collision callback system. The problem was that my solver sucked. It was slow and required too much CPU to make a even a small stack of blocks stack stably. After seeing how well the impulse caching and clamping worked in the Box2D tech demo, I was sold. I worked that into Chipmunk and it's worked great ever since. Basically everything other than that was developed completely independently. To this day, I've never actually used Box2D... Not because I'm stuck up about it, I've just never gotten around to it and I don't much like working in C++. I'm mostly looking for critical input of what Chipmunk needs to better fill it's niche. What features do Chipmunk users like, and what features would Box2D users feel are missing in Box2D that could set Chipmunk apart?Benefits of both:- Free / Open Source
- Fast
- Much easier to use than shoehorning 3D engines into 2D games
Benefits of Chipmunk:- Chipmunk's spatial hash based broadphase can be much faster than Box2D's Sort and Prune and requires no explicit bounds. I'll be adding hierarchical spatial hashes eventually that will make tuning much easier. edit: Never implemented hierarchal spatial hashes, but the 6.0 beta already has support for 1D sort and sweep, an AABB tree with really great temporal coherence, and the good old spatial hashing.
- C99 implementation - I really dislike C++, and Box2Ds API strikes me as a bit awkward
- A larger selection of joint/constraint/motor types, constraint parameters can be animated at runtime
- Flexible Collision Callbacks - Chipmunk lets you register callbacks based on the type of the objects colliding. If the basic collision primitive filtering is not enough, you can reject a collision from a callback (Box2D will let you reject collisions in 2.1)
- Beveled line segment collision primitive - Like a pill shape. Much faster than polygon collision checks. edit: Box2D now has non-beveled segments
- API to assist in removing physics objects safely from within callbacks.
- Stackable elastic objects without using threshold velocities
- Surface velocities - Per shape velocities that are used during friction calculations.
- Shape Based Queries - Query the space to see if a shape overlaps with anything.
- No Assumed Scale - Box2D assumes meters for size, 9.8m/s^2 for gravity, etc. Performance suffers greatly if you don't follow this. Chipmunk makes no such assumptions. You can use pixels or tiles for your distance units, and you need only to tune the spatial hash to match. The tree in Chipmunk 6 requires no such tuning.
Benefits of Box2D:- Swept collisions - For many this is a killer feature and can be hard to live without if it's not there. I've never actually needed this, and currently have no plans to implement it.
- C++ implementation - To each their own, although operator overloading is a wonderful thing
 edit: Chipmunk has overloaded C++ operators for vector operations. - Slightly more flexible primitive collision filtering - More on this later
- A couple kinds of joints I don't have
- Box2D's Sort and Prune based broadphase can be faster when you have objects of highly varying sizes (Sounds like it will have several broadphase options for 2.1) edit: Box2D switched from SAP to an AABB tree like the one from Bullet.
- Larger community.
- Sleeping bodies when they come to rest. Much more important for 3D engines, but still a good feature to have. I have plans for this someday. edit: Chipmunk has supported sleeping for some time now as well.
- Probably a bunch more stuff I don't know about. Let me know what's missing here and I'll add it
Features missing from both:- Progress - It comes, but very slowly it seems
- Concave shapes - I have plans to implement them using SDFs some day
- Fluids - Very CPU intensive and hard to integrate with rigid body physics
- Buoyancy - I used to have a demo of this, but no real API (Box2D has an external library for this?)
- Ropes - We both have plans for this eventually. edit: Example code exists for both libraries, but is not integrated.
On the topic of collision filtering: Chipmunk's collision filtering is fairly simple, you have a layer bitmask, and a group. If two shapes share no layer bits in the bitmasks, they don't collide. If two shapes are in the same non-zero group, the collision is ignored. A failure of either test rejects the collision. This was implemented long ago before Box2D existed as a real library, and I've been quite happy with it. Box2D's collision filtering is more complicated with special rules and precedence. I can't actually think of how to use the added complexity. Do any veteran Box2D users have uses for positive collision groups forcing a collision or using category/masks where one object says to ignore the collision but the other overrides it? I'm wondering if I'm missing something here.Performance wise I have no idea which is better. I know some people have struggled with Box2D's performance then got things working great with Chipmunk. I also know of examples going the other way. I suspect it has mostly to do with our choice of broadphase collision detection. When they work well, they should both be using a small amount of CPU. When tortured, they can balloon to monopolize the CPU. Box2D is going to work better with varyingly sized objects, and Chipmunk is going to work better with a large number of similar sized objects. An example of where Chipmunk shines: http://methodart.blogspot.com/search?q=chipmunk I expect Chipmunk worked very well for him because all his objects are of similar size. Box2D forces you to set the bounds of your world, Chipmunk forces you to guess a good cell size and count for the grid it uses but has no bounds. Tradeoffs. (shrugs)Updated on March 29, 2011 | | « Last Edit: March 29, 2011, 07:15:10 AM by slembcke » |  Logged |
Scott - Howling Moon Software Chipmunk Physics Library - A fast and lightweight 2D physics engine. | | |
| slembcke Level 3 |  | Re: Chipmunk Physics and Box2D comparison « Reply #1 on: November 17, 2009, 11:47:56 PM » |
Was inspired to add sensor shapes to the experimental collision callback branch. Ended up being a trivial feature to implement. The branch also has improvements for collisions events (new, persistent, separated). The sensors work nicely with that. Unfortunately there is no sensible way to work in attaching raycasts or point queries as sensors. | | Logged |
Scott - Howling Moon Software Chipmunk Physics Library - A fast and lightweight 2D physics engine. | | |
Draknek Level 6   "Alan Hazelden" for short | | Re: Chipmunk Physics and Box2D comparison « Reply #2 on: November 18, 2009, 02:57:52 AM » |
Hi, really nice job on Chipmunk. I've not used it myself, but it looks great. Box2D's API has annoyed me on the small number of occasions that I've used it, so the next time I decide to use someone else's physics engine from C++, I'll probably give it a go.Also, it has some of the best physics demos ever. The tower of balanced dominoes at the start of ? Brilliant.Quote from: slembcke on November 17, 2009, 10:10:58 PMUnitless - Box2D discourages using pixel coordinates presumably for precision reasons. Chipmunk by default uses double precision floating point numbers internally. Not only do doubles tend to be faster (really really), but it basically makes precision errors go away in any reasonable usage. Use whatever units make sense to you.I'm not sure this is about precision, but I've never worked out exactly what it is about. I know that when I was creating , I needed a threshold distance d where if two bodies were closer than d (but not touching) you would remember their old contacts. I've always assumed it was settings like this that made the scale relevant, but never actually confirmed this.Quote from: slembcke on November 17, 2009, 10:10:58 PMStackable elastic objects without using threshold velocitiesBy elastic objects, do you mean objects with coefficient of restitution 1? If so, how can they stack at all?What's your take on memory management? Apparently this can be a major performance bottleneck of a physics engine.Benefit of Box2D: it's been ported to pretty much every language under the sun.Re: C vs. C++: for me, the critical thing when working with physics is operator overloading. If I can't use inline vector maths, I quickly go insane.EDIT: oh, and one reason Box2D might perform better in some situations but not others is because it implements collision islands -- if your objects are split up around the world I can see this making a big difference. | | « Last Edit: November 18, 2009, 03:20:37 AM by Draknek » | Logged |
My games | Twitter | These Robotic Hearts of Mine | Sokobond | | |
jeb Level 5  Bling bling | | Re: Chipmunk Physics and Box2D comparison « Reply #3 on: November 18, 2009, 04:54:42 AM » |
Thanks for the write up!A quick comment:If you are going to use Box2D I recommend you download it from their SVN instead of the last official release, because:1. They've changed the collision handler (it's better now). Saves you some pain to convert your code when the next release comes.2. It has ray casting. | | Logged |
Oxeye Game Studio | | |
Zaratustra Level 7  | | Re: Chipmunk Physics and Box2D comparison « Reply #4 on: November 18, 2009, 05:54:46 AM » |
Couldn't concave shapes be handled by dividing them into triangles? | | Logged |
Zaratustra Productions / Zeta\'s World / Eversion | | |
| slembcke Level 3 | | Re: Chipmunk Physics and Box2D comparison « Reply #5 on: November 18, 2009, 08:58:34 AM » |
Quote from: Draknek on November 18, 2009, 02:57:52 AMAlso, it has some of the best physics demos ever. The tower of balanced dominoes at the start of ? Brilliant.Hah. I used to make those from actual dominoes when I was a kid. I used Chipmunk as part of my senior thesis, and generated some movies and http://www.youtube.com/watch?v=Cx5GBMybxXwAs far as the unit issue. It's possible that the units are recommended so it plays nicely with the default tolerances built into the system I guess. I hadn't really considered that. Really the only tolerance value that Chipmunk uses is one that determines how much objects can overlap in order to prevent them from breaking contact and losing the cached collision data. I think Box2D does something similar, explicitly encouraging a small amount of overlap. If the scale was such that half of your object fell into that tolerance, it would be a bit awkward.Chipmunk also has a large number of bindings and ports to other languages actually: http://code.google.com/p/chipmunk-physics/wiki/BindingsAndPortsI know there are more as I haven't updated that page in a while...Memory management: You know, I read that section in the Box2D manual about how he does memory allocations and I just don't buy it in this case. The collision detection in Chipmunk calls malloc() a little more than once on average for each collision pair found. When writing it, I figured eventually I'd have to fix that to sub-allocate from a large pre-allocated block, but it has never come up as an issue. Memory management uses less than %1 of overall runtime last time I profiled. Even on the iPhone I don't run into memory fragmentation issues. Sub-allocating would probably be more cache friendly, though Chipmunk doesn't really seem to use that much memory bandwidth. I'll probably do it eventually though. It probably does help some. I'm guessing that Erin didn't do it just to make more work for himself.I feel your pain about operator overloading. I do a lot of my Chipmunk coding from Ruby for that reason actually. I consider C just sort of a necessary evil. Crayon Ball was written mostly in Ruby with a little Chipmunk and some scenegraph code in C. Ruby used less than 25% of the program's overall runtime, so the general excruciating slowness of Ruby was not really so bad a tradeoff to get overloaded operators. I've also been rather excited about programming games in OOC lately. A nice little language that makes it trivial to wrap and use C libraries and even extend C types with methods and overloaded operators. I digress...@ZaratustraYes, you can subdivide any polygon into triangles yes, but it's not very efficient and is going to make your broadphase collision detection send a lot of false positives from shapes on the same object being flagged as a potential collision pair. It also means that you have cracks in your collision shape now that other shapes can get stuck between. | | « Last Edit: November 19, 2009, 03:56:45 PM by slembcke » | Logged |
Scott - Howling Moon Software Chipmunk Physics Library - A fast and lightweight 2D physics engine. | | |
John Nesky Level 10  aka shaktool | | Re: Chipmunk Physics and Box2D comparison « Reply #6 on: November 18, 2009, 11:35:40 AM » |
Box2D has these: Quote from: slembcke on November 17, 2009, 10:10:58 PM- Ray casting - Useful for implementing bullets, lasers and sensors (recently added)
- Point queries - Useful for mouse picking and sensors
- Beveled line segment collision primitive
And these aren't part of the main Box2D library but implementations are available:Quote from: slembcke on November 17, 2009, 10:10:58 PM- Fluids - Very CPU intensive and hard to integrate with rigid body physics
- Buoyancy - I used to have a demo of this, but no real API
I do agree that Box2D's API needs some work. ^_^My least favorite part of Box2D, by far, was the contact callbacks, which force you to manually duplicate a lot of data and then attempt to parse it after the callbacks have finished.  Although I hear the callbacks aren't so bad in the latest version?My second least favorite aspect of Box2D was, perhaps surprisingly, its insistence on physically accurate behavior. I'd love to have a physics engine that gave me more control over the movement of sidescroller characters, for example:- I love the way Yoshi in Yoshi's Island hugs the ground as he runs over a hill, instead of the momentum carrying him into the air.
- Similarly, I'd like to be able to create characters like Metroid's Geemers, which hug the walls and ceilings.
- I'd love an easy way to create one-way platform surfaces that you can stand on or jump through.
- While I'm dreaming, I want Castlevania stairs and Mega Man ladders. I mean, to some extent these need to be game specific implementations, but the part about detecting that you're overlapping the some background object, and the part that attaches you to this object in some way could be a little more general and more encouraged by the API.
| | « Last Edit: November 18, 2009, 01:10:09 PM by John Nesky » | Logged |
| | |
| slembcke Level 3 | | Re: Chipmunk Physics and Box2D comparison « Reply #7 on: November 18, 2009, 12:57:47 PM » |
Yeah, I think Chipmunk's collision callback system lets you write much nicer code for handling collisions for sure. I've also just recently finalized a nice API for helping you remove objects from within collision callbacks. Something that both libraries have struggled with.Sadly I've only written a couple of prototype platformers with Chipmunk despite one of the driving reasons for creating it in the first place was to use it in platformer games! It turns out that I'm a really terrible game designer and just a good graphics and physics programmer instead.  I do have a couple of features that I've implemented with platformers specifically in mind however. For one, shapes can have a "surface velocity" that is used when calculating friction. This lets you implement things like conveyor belts or character running behaviors where surface velocity of a collision shape can be different than the body it's attached to. Just change the surface velocity of the shape for the players feet and let friction handle the rest to make them move. The neat thing about this is that it makes walking on moving objects like platforms "just work".As for doing things the "accurate" way. You never have to, the trick is to fool the physics into thinking that it's the correct behavior. For the example of Yoshi's ground hugging behavior, check if the player is near the ground and add an additional grounding force beyond normal gravity to keep them down. Cancel the force when they enter freefall. For things that walk on walls, use a pair of short raycasts to feel out the contour of the wall where the legs would go. Also consider having a separate physics controlled and animation controlled system. Only enable the physics control when the object is hit.Also... Funny that you mention one sided platforms. I was thinking about that last night when I fell asleep. I've thought about that off and on for a long time and could never come up with a satisfactory solution. The answer is so obvious it hurts that I didn't think of it sooner! As long as you have collision begin/separate events, you should have everything you need. When you receive the collision begin event, check if the normal is pointing in the correct direction. If it is, allow the collision. If it's not, ignore the collision until you receive the collision separate event. Dunno if you can do that with Box2D easily, but in Chipmunk you can reject a collision that has already been found when you get the collision start event. | | Logged |
Scott - Howling Moon Software Chipmunk Physics Library - A fast and lightweight 2D physics engine. | | |
Ivan Owl Country Level 10   alright, let's see what we can see | | Re: Chipmunk Physics and Box2D comparison « Reply #8 on: November 18, 2009, 01:06:48 PM » |
It's funny we have both the developer of Chipmunk and co-developer of Box2D on here. You guys should arm wrestle or something. | | Logged |
http://polycode.org/ - Free, cross-platform, open-source engine. | | |
| John Nesky Level 10 aka shaktool | | Re: Chipmunk Physics and Box2D comparison « Reply #9 on: November 18, 2009, 01:15:49 PM » |
Quote from: Ivan on November 18, 2009, 01:06:48 PMIt's funny we have both the developer of Chipmunk and co-developer of Box2D on here. You guys should arm wrestle or something.Okay, rock paper scissors shoot!I choose rock. | | Logged |
| | |
| slembcke Level 3 | | Re: Chipmunk Physics and Box2D comparison « Reply #10 on: November 18, 2009, 01:25:04 PM » |
Quote from: John Nesky on November 18, 2009, 01:15:49 PMOkay, rock paper scissors shoot!I choose rock. Umm... Umm... (is too nervous and can't decide which to choose) | | Logged |
Scott - Howling Moon Software Chipmunk Physics Library - A fast and lightweight 2D physics engine. | | |
| increpare Guest | | Re: Chipmunk Physics and Box2D comparison « Reply #11 on: November 18, 2009, 03:15:30 PM » |
Hah, oh man, it makes me really giddy to see you here, slembcke : D Warm welcome to the forums. QuoteI'm a really terrible game designer and just a good graphics and physics programmer instead. Ah if you want to get your gaming chops in gear you should try out I think some of the smaller-scale coordinated game-making efforts (jams/competitions/ludum dares/&c.). [I seem to be saying that to a lot of people right now, but I think it a constructive piece of advice, so whatever.] | | « Last Edit: November 18, 2009, 03:34:00 PM by increpare » | Logged |
| | |
Danmark Level 7  | | Re: Chipmunk Physics and Box2D comparison « Reply #12 on: November 18, 2009, 03:57:58 PM » |
My <$0.02 is that, perhaps because of my love for projectile weapons, raycasting is necessary for a physics engine. Last I saw Chipmunk didn't have it, and Box2D only had it in a version too unstable to use (has that changed?). | | Logged |
| | |
| slembcke Level 3 | | Re: Chipmunk Physics and Box2D comparison « Reply #13 on: November 18, 2009, 04:07:28 PM » |
Quote from: Baiame on November 18, 2009, 03:57:58 PMMy <$0.02 is that, perhaps because of my love for projectile weapons, raycasting is necessary for a physics engine. Last I saw Chipmunk didn't have it, and Box2D only had it in a version too unstable to use (has that changed?).As of about 3 weeks ago, I finally fixed and finished proper raycasting in Chipmunk in the trunk code. From what other people are saying, it sounds like the trunk code of Box2D is usable as well. | | Logged |
Scott - Howling Moon Software Chipmunk Physics Library - A fast and lightweight 2D physics engine. | | |
bateleur Level 10  | | Re: Chipmunk Physics and Box2D comparison « Reply #14 on: November 19, 2009, 01:40:20 AM » |
I like the fact Chipmunk uses doubles. I've spent some time pondering the impact of chaos on networked physics games (no really, I'm not just saying that to break my previous record for abject pretentiousness) and more precision seems like the best workaround for this sort of problem. (If anyone thinks this kind of thing doesn't happen, you haven't played enough Fantastic Contraption!)Quote from: Ivan on November 18, 2009, 01:06:48 PMIt's funny we have both the developer of Chipmunk and co-developer of Box2D on here.I think you'll find all the cool kids hang out at TIGSource.  | | Logged |
 Blog / Twitter / FaceBook // Play The Golem!  | | |
| slembcke Level 3 | | Re: Chipmunk Physics and Box2D comparison « Reply #15 on: November 19, 2009, 06:58:29 AM » |
Even with doubles you'll find that it doesn't prevent a little chaos. Any of the demos that have a big old stack of objects have subtle differences in the simulation. A body that tumbles off the pile may tumble once instead of twice before coming to a rest, or might not tumble off the pile at all.In general, you just can't rely on complicated situations to have a very specific outcome. A pile of objects will look like it acts like a pile of objects, but don't expect that pile to act exactly the same way if you change the system in any way. Even adding another object far away can change iteration order by causing objects to be found in a different order by the collision detection subsystem. That order is significant when your simulation is built up with millions or tens of millions of tiny floating point errors. Like engineering in the real world, you have to make sure you are allowing for appropriate tolerances. | | Logged |
Scott - Howling Moon Software Chipmunk Physics Library - A fast and lightweight 2D physics engine. | | |
Core Xii Level 10  the resident dissident | | Re: Chipmunk Physics and Box2D comparison « Reply #16 on: November 19, 2009, 10:50:56 AM » |
I don't have any actual input to the topic at hand, but I just wanted to drop in and say hi; I really like Chipmunk! You've really managed to Keep It Simple, Stupid for a physics engine. | | Logged |
| | |
Martin 2BAM Level 10  @iam2bam | | Re: Chipmunk Physics and Box2D comparison « Reply #17 on: November 19, 2009, 01:38:36 PM » |
It's odd that you find OOP awkward. I feel the other way around.Why have a shitload of disperse functions when I can have them tidily put in a class?Having OOP all around, why still getting stuck with procedural programming?Most probably it's a mutant structureful pseudo-object-oriented code anyway (If you're not wrapping everything in classes already).Go cleaner, choose OOP Chipmunk is more focused on speed. But actually with better performing computers coming out each day, I prefer features+clean code even if it takes some design considerations on limiting the game objects.On the long run it will be better because performance will eventually match, but I'll also be able to read and understand my code better.The double vs float has been addressed @ gamedev and might be a compiler config issue.If you had issues with Box2D and floats its probably because you haven't used it correctly (play around with the unit system!).Doubles can help hide the underlying problem, not solve it. That's why everything that's not an integer, it must be compared to a range (tolerance, "epsilon"). If you don't use Box2D as it's intended, that range will not work correctly.If that doesn't suit your needs, "search & replace" and "compile" will (I love open source)Regards | | Logged |
Working on  HeliBrawl | | |
| BorisTheBrave Level 10 | | Re: Chipmunk Physics and Box2D comparison « Reply #18 on: November 19, 2009, 02:11:41 PM » |
Hi, slembcke. Good to meet you. I'd certainly recognize your username on the streets. Not so sure about your name, though.I'm more or less developer for Box2D. I've got loads of respect for Chipmunk.I have to admit, though, I've never tried it out properly. I'm envious of the API, which is Box2D's weakest feature. And the ease of use, which is similar. C was a an excellent choice for encouraging bindings to other languages too. The youtube vidoes of Chipmunk are also georgeous, with thousands of particles.Still, I feel obliged to correct a few details. Box2D is nearing v2.1, and stabilizing, and it adds many goodies. A few of which I've personally written (the initial versions of), so I hope you don't mind if I go over them.- The callback API has been simplified, and improved. There's no more "double" events, or Add/Persist/Remove. Instead, there's ContactBegin/PreSolve/PostSolve/ContactEnd. Pre/PostSolve are the ones called once per frame per contact.
- You can disable a given contact in the callback events. This makes one way platforms basically easy (there's a demo in the testbed), though there's still considerable leeway on how exactly to implement it.
- The rest of the API has been improved a bit. I'll be honest though, it's still not near Chipmunk's class. Physical properties have been separated from shape properties. Some things filling arrays now use callbacks (which could even be a worsening in terms of ease). A couple of additions for ease of use.
- New broadphase based on loose trees of bounding boxes. It's faster than the previous, and you don't need give a bounding area to begin with. Limitations on number of pairs/shapes have been removed. I doubt it's as fast as a well tuned spatial hash, but at least is saves the hassle of tuning. In the AS3 port, I'm experimenting with having a selection of broadphases. Will probably whip up spatial hash for that.
- Raycasts - integrated with the broadphase (it always had line-shape intersections). You don't need raycasts for bullets though, just use very fast bodies with the isBullet flag turned on, way cooler!
- Buoyancy ((flash demo) - part of the Contributed controllers framework.
- Thin edges - initially created by John Nesky here (he's too modest)
And of course, Box2D has continuous collision detection from v2.0, which as you say, is an amazing feature, but probably one most people can do without.I actually wrote code for modifying the world in Box2D callbacks, but Erin didn't accept it. So I'll keep that to myself for now, as it worked with the old broadphase. Erin's pretty much not accepting anything from others to trunk any more, which makes me sad.I guess it's pointless now anyway, as you can immediately "disable" bodies and joints, and have a bit of sugar to delete them later.For the record, Box2D insists on a certain scale not for precision reasons, but for tuning. All the default settings are calibrated for a particular scale, and we prefer to tell people what they should do than explain how to change the settings. It does encourage good behaviour, but like Vista's UAC, it's generally detested despite being good for you. I cannot even remember if Box2D uses floats or doubles, but it's typedef'd so you can easily swap.Doing non physical behaviour in any physics engine does take more work. But it's doable, and I think that's where the art really lies. You add extra hidden forces, you add sensors and raycasts, and generally muck around until you get a good feel. Now raycasts and disabling contacts is in, it's generally a lot more reasonable to implement (raycasts are a good way to "hug" a wall). | | Logged |
| | |
| slembcke Level 3 | | Re: Chipmunk Physics and Box2D comparison « Reply #19 on: November 19, 2009, 03:09:55 PM » |
@nitram_ceroWho said anything about finding OOP awkward? I just said I dislike C++ and am not a fan of Box2D's API. Chipmunk has been implemented in a very OOP friendly manner. At the same time, it's implemented in a way that makes it easy to write bindings to other languages for. I do most of my Chipmunk coding in Ruby, which has a lot more powerful OO features than C++. Personally I prefer hybrid functional/OO languages like Ruby or OCaml.I'm well aware of how floating point numbers work. You don't really think I could have implemented an entire physics engine without knowing what epsilon meant did you? Modern CPUs families like x86 and PPC don't actually have 32bit float hardware. Unless you are hitting memory bandwidth problems, doubles will be faster because they don't need to be converted to 64bit floats first. At least that is what I learned a while back.If you want to compare "cleanliness" of code, I'd point out that Chipmunk has half the source code of Box2D and is very comparable in it's feature set and performance. As of this moment, the trunk code of Chipmunk is 6,660 lines of code (1/3 of which is joint definitions), Box2D 2.0.1 is 13,569. A lot of that is probably choice of formatting maybe, but if C++ made things simpler and cleaner there would still not be 2x as much! I'm not saying that they've done a bad job, just that C++ != simpler. To me, cleaner is a language where I don't need to maintain header files that duplicate the same information that I have in my implementation files. In that regard, I don't consider C to be "clean" either.Not trying to start yet another programming language flamewar, but using C++ certainly didn't help keep Box2D simple or give it a nice clean API IMHO. I'm not saying it's bad either, just that it's what I expect from a C++ API. (At least it's not like a Java API ) You say that Chipmunk is more focused on speed, but that has never been true. I usually try to make the API as nice as can possibly be done in C99 code, then worry about performance after profiling the code. Trust me, I've learned my lesson about premature optimization. I've made some really dumb early design decisions that seriously hampered the flexibility of some of my earlier pre-Chipmunk physics libraries. When I started over from scratch (the version that is Chipmunk today), I worried about functionality and API first. After some profiling and inserting some better algorithms I had something much faster than the previous project anyway. So I didn't write Chipmunk in C because I thought it was the fastest, but because it was one of the fastest and the easiest to bridge with any other language I wanted to use with it. I assume I must be doing a decent job as I've gotten a lot of compliments about how simple Chipmunk is to use and how fast it is. People that have written bindings have also been thankful that it has a nice simple C API that is easy to wrap. I think every person that has ported Chipmunk to another language has told me that they started with Box2D and gave up. Just two weeks ago I got an email from somebody porting Chipmunk to LISP.QuoteAll in all, it was pretty readable code, considering all the variousthings going on inside, so it was actually quite easy to translate(as opposed to box2d, which we'd started attempting and decided to drop).C is a hammer and not everything is a nail. I've actually never written a game in C, and I probably never will. There are some things that express very nicely as C code. For other things like games, I want my objects! Don't just assume that because I'm not using C++ that I haven't seen the "light" that is C++ in all it's OOP glory. If that's the case, try expanding your horizons with some languages that have much more powerful OO and type system features than C++. Try out some functional languages as well. I've used more languages than I can remember. Every one of them taught me something new that I could reapply when programming in other languages too. I'm not trying to be a jerk about that either, it's the best advice I could give any other programmer. I just don't personally have a use for C++ that C, Ruby, Obj-C, C#, and Java don't already fill.This is probably has a much more confrontational tone than I wanted... Box2D is great, it has great features that I don't! C++ is great, people that like to use it write great stuff in it! Hugs all around! | | « Last Edit: November 19, 2009, 04:00:18 PM by slembcke » | Logged |
Scott - Howling Moon Software Chipmunk Physics Library - A fast and lightweight 2D physics engine. | | |
Please select a destination: ----------------------------- Community ----------------------------- => Townhall ===> Forum Issues =====> Archived subforums (read only) =======> Archived Projects =========> Balding's Quest =========> TIGCast =========> Indie Brawl =======> Creative =========> Writing =======> Tutorials => DevLogs => Jams & Events ===> Competitions =====> Wholesome =====> Sports =====> Versus =====> A Game by Its Cover =====> Old Competitions =======> GAMMA =======> B-Games =======> Text the Halls =======> VGNG =======> Procedural Generation =======> Bootleg Demakes =======> Commonplace Book =======> Cockpit Competition =======> Adult/Educational Compo =======> Assemblee: Part 1 =======> Assemblee: Part 2 ----------------------------- Developer ----------------------------- => Playtesting => Art ===> Workshop => Audio => Design => Technical => Business ----------------------------- Jobs ----------------------------- => Offering Paid Work => Portfolios => Collaborations ----------------------------- Player ----------------------------- => General => Games => Table Talk ----------------------------- Hidden ----------------------------- =====> Game Club =====> Unpaid Work
Loading...
Developer
Loading...