www.iforce2d.net

Dear developer,

I have been working with R.U.B.E. for the past few days and I found myself to be in a complicated situation.
My problem arises when I export my work into Source Code (C++). First of all, it seems important to especify that exporting in a Json file is not an option for me because the files take too long to upload - specially for scenes over 500 kb. Taking that into account, I am forced to export using the Source Code alternative.

The Problem.
When I export in Source Code, the names of each body in the scenes are not included. As a consequence, I cannot identify the different types of bodies that I may have in my game. For example: I export into Source Code a scene containing a circle. In the scene that circle was called "body1" as default. I changed the name to "wheel1", yet this name (Wheel) does not appear in the Source Code.

Having the problem been stated, I was wondering if there was any kind of solution that may help me to solve this particular problem - remember that exporting the scenes in a Json file is not an option.

Approach towards a solution.
By no means I intend to interfere with the development of your software. That being said, I was thinking about a possible - yet quick and feasible - solution. My idea is to add a property to the body's property structure in order to set the name (which I set while using R.U.B.E) of said body. This property could use exclusively [b2BodyDef.userData]. An example of this property would be:
Thanks for your time. I am looking forward to your reply. I hope there is some sort of solution for my problem, since R.U.B.E. is fantastic and I intend to keep using it.

Greetings!

Nicolás
Boxitsoft - Developer

Hi Nicolás

The cpp export uses purely the Box2D source code, which I am trying to keep as close to the official Box2D svn repository as possible so updates can be applied smoothly when the official source code changes. This makes it tricky to introduce support for extra things (eg. std::string in this case) and still have a clean way to keep it compatible.

Another thing is that if the exported cpp requires std::string, it may no longer be simple drop-in compatible with where it is being used, and people would have to fix this themselves. The cpp export is provided as a debugging convenience rather than a real solution for final production, or to help people quickly test a RUBE scene in their program without setting up the supporting jsoncpp classes.

Another thing is that placing non-ascii text into source code can cause problems, eg. Japanese, Arabic etc.

It must be cripplingly slow for your workflow to compile the new .cpp after exporting every time, before being able to run the changes! If you use json you can leave your program running and just reload the level again after exporting. Typically people would work with the editor and their program side-by-side like this to give a quicker turnaround during development.

I think a better solution would be to get at the real problem you mention - that the json is slow to load. What hardware are you running on, and how slow is 'slow'? My 3Ghz desktop PC loads a 600kb json file in under a second. In any case, perhaps a binary format might be better? Making a binary form of the b2dJson loaders is something I would like to do... someday.

Something else that might help is to remove unnecessary info from the json file. I'm planning to make a dialog where you can choose which things should be excluded, maybe even in the next update. In the meantime, you could also try the jq tool mentioned in this thread: viewtopic.php?f=8&t=62&p=308&hilit=exclude#p299