Have used Box2D with ChaiScript quite a bit, but have since switched to PlayRho - a fork of Box2D which by now has moved pretty far away from Box2D. It’s written in a more modern style, maybe you want to check it out at https://github.com/louis-langholtz/PlayRho .
That being said both are a bit of a pain to bind. Both are even more of a pain to de/serialize. Still, both are awesome.

EDIT: as a side, you might find current performance of ChaiScript might bottleneck you if you are doing realtime stuff and are accessing Box2D or the like on every frame through ChaiScript. ChaiScript itself currently eats more than 10x the cycles than the physics do.

@ninnghazad Have used Box2D with ChaiScript quite a bit, but have since switched to PlayRho

Haven’t heard of PlayRho. Looks pretty cool. What are you using it for? How are you integrating with it?

@ninnghazad ChaiScript itself currently eats more than 10x the cycles than the physics do.

What version of ChaiScript were you working with? I am interested in seeing how it affects performance. Where were you seeing ChaiScript slow things down?.. I’m running ChaiScript on a Raspberry Pi, so I am cautious of such things. Thanks for the heads up.

@lefticus Would you be interested in moving these to be part of the ChaiScript organization? Maybe merging with ChaiScript_Extras in some meaningful way?

Glad you’re encouraging ChaiScript_Extras to grow. If ChaiScript_Extras_Box2D becomes solid, it may be worth considering. At this point, it’s very young and still a proof of concept.

Haven’t heard of PlayRho. Looks pretty cool. What are you using it for? How are you integrating with it?

2d “hobby” game project, spaceships, multiplayer. I switched to PlayRho because of the modern c++14 and above style, and diverse problems with Box2D when it came to determinism/serialization and networking. It’s intergrated by means of a System in the ECS and corresponding Component(s). Entities can have a BodyComponent and if needed different JointComponents, the System calls the step() and catches collision events to pass ‘em around (to ChaiScript). Trying to keep it minimal, the bindings however are quite the thing - i remember the bindings (incomplete as they were) for Box2D being a little more straight forward.
Using quite the bunch of macros to bind the different JointTypes and so on. Positions are synced between physics’ bodies and my internal positions before and after each step. That way i can use the ShiftOrigin thing and have the physics simulation always work with an origin close to 0:0 to reduce numerical problems.

RobLoach:

What version of ChaiScript were you working with? I am interested in seeing how it affects performance. Where were you seeing ChaiScript slow things down?.. I’m running ChaiScript on a Raspberry Pi, so I am cautious of such things. Thanks for the heads up.

I am currently on 6.1.0. At the moment the nastiest parts are when i call a lot of ChaiScript functions bound to std::function from the C++ side - which i do for example when calling the scripted handlers for events (like collisions, some user input and so on) and the per-frame-tic-functions of my entities. even with just a small bunch of entities ChaiScript will consume 80-90% of cycles for the client. Now keep in mind that might be because imdoingitwrong™ or my use case is excessive or or or. However i still use it, because i like the way it handles, and because i think it will continue to improve. Also i think it’s just plain elegant. Just peek at that sourcecode. M-hm…
You can find a bunch of good tips in the docs,this site and github - like make really sure you compile ChaiScript proper - that has a huge impact. And weird stuff, like i try to not use return statements in ChaiScript - for reasons beyond me that makes a difference. Even just removing the literal word return from return-statements can make difference. Maybe that has already changed, dunno.

I am currently on 6.1.0. At the moment the nastiest parts are when i call a lot of ChaiScript functions bound to std::function from the C++ side -

If you only knew how much pain I went through to completely remove std::function from the internals of ChaiScript.

Whenever you can pass a lambda instead of a result from std::bind or a std::function into the ChaiScript engine. std::function will be unavoidable in some cases, if you need that type erasure. But when you can give ChaiScript something the compiler can optimize.

If you only knew how much pain I went through to completely remove std::function from the internals of ChaiScript.

I can only imagine, but i appreciate it =).

lefticus:

And I just realized that I read your statement backward. You aren’t passing std::function into ChaiScript, you’re pulling them out. There’s really not much way around that bit.

Yeah. But i think i can squeeze out more performance by restructuring my scripts to use no return at all. Just removing all return that were the last statement of a function gave a huge boost. I still have some around that abort functions, gonna see how removing these will help. Also gonna try to reduce the dot_access (or whatsitsname) by using temporaries.

Works pretty well on Raspberry Pi… While not a graphically intensive game, Floppy Bird runs well. I find the biggest slow down is the graphic rendering right now. But I haven’t done full benchmarks and performance tests.