Haven’t implemented the entire thing yet, and it’s still young. Mostly wanted to gauge interest, and see if anyone’s done this already before. Would love your opinions! Thanks a lot.
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.
Would you be interested in moving these to be part of the ChaiScript organization? Maybe merging with ChaiScript_Extras in some meaningful way?
@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.
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.
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 curious to see how ChaiScript performs in your case.
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.
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.
I can only imagine, but i appreciate it =).
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.
Just submitted String Methods to ChaiScript Extras. Could see extras include more extensions to the language. Thanks for starting that thing up. I’d be down for helping see it improve.
I use another fork of Box2D by Google, liquidfun.
It should be compatible though, I’ll check it out
Don’t think it’ll be a good idea to just merge all third party library “extras” into the same repo.
Maybe create multiple repos or even a seperate Chaiscript_Extras organization?
Agreed… For extending how the language uses C++ functionality for Math and Strings, it makes sense to keep it in ChaiScript_Extras. Other packages are best to live outside so that dependencies and tests clean.
For Box2D, I’ll keep it at https://github.com/RobLoach/ChaiScript_Extras_Box2D, and consider moving it if it needs it. Right now it’s happy where it is.