Landing r2d branch into trunk (r538)

[bengarney]

Hello PBE-ers!

I am going to be merging the r2d branch into trunk. This brings us some nice improvements:

• Simpler, more flexible, faster rendering 2d. It's better in basically every way - a full rewrite. It's much much easier to use, too. No more debugging your spatial to get stuff to render.
• Logging system cleaned up and simplified. Now there is only one logger and it is pretty concise. We will add back a few features but the intent is that if you need a really beefy logger, you can hook it into the new system, but that the new system is not itself big and beefy. Let me know if I killed your favorite feature and we can readd it.
• Global class refactored into PBE class; Global was a stupid name for a class, and with the PBE class, redundant. Now there is only one.

Anyway, consider this an FYI that this merge is in process, and that in a day or so there should be a bunch of neat shiny new code in trunk. Also, if you are developing against trunk, do be careful when you update. If people request it I can tag revision 537 of trunk so that they can use the tag to avoid nasty app breaking surprises.

The examples, lessons, and samples will be updated, too. Volunteers to help with this would be very welcome; contact us on IRC or post here if you'd like to help out!

Thanks,
Ben

[Shiki]

woohoo! can't wait for this

[natebeck]

Woooooooooot! Can't wait!

[bengarney]

Here is revision 538, the initial landing of the r2d branch.

You will notice that various things are broken at this time. The RollyBallGame compiles and runs; I will be resurrecting everything else tomorrow. Box2D components do not build. The other examples and lessons do not build. This is normal. If you need a working trunk, please revert to revision 537.

I will continue to post in this thread as I land changes.

[bengarney]

BTW - feedback on the new changes is welcome. Now is the best time to correct any major oversights. In general this should result in a clearer and simpler API for logging, rendering, and some miscellaneous global operations. So feel free to ask questions, complain, compliment, or whatever else takes your fancy.

[mas]

Sounds good .. will check in a day or so ...

[giggsy]

I don't know if it's the type of changes you asked for, but here are my two cents what I am currently "struggling" with (it's all about Box2D):
Sidenote: I must admit that I'm not yet too familiar with the code, but I'm working on it

1) collisionType:
In the common.pbelevel (also in the templates.pbelevel), why do the collision types also have a Renderable?
As in my other post, maybe I've overlooked something in the docs. But I assume that somehow the render component checks if the physics shape is in collision type one? Why?
I would unterstand if this is for debug graphics, but why is this used for sprites?
If it's not clear what I am talking about: look at the PBE-Demo, if you remove the Renderable of the Dummy, the collision circle is drawn, but the animated sprite isn't.

2) collidesWithTypes aka filter.maskBits:
I think it's a not desired behavior, that every object needs to know about every collision type it collides with.
E.g. if I create some collision shapes on the fly, with new collision types, it's not possible to let these collide with "older" objects, cause they don't have this collision type set in the mask.
I examined the code of b2ContactFilter.as, and saw the following:

Code: Select all

var collide:Boolean = (filter1.maskBits & filter2.categoryBits) != 0 && (filter1.categoryBits & filter2.maskBits) != 0;

I must say that I'm coming from the C#/XNA side, and we had a frame work using Farseer-Physics, which is a customized version of Box2D.NET, and I compared the code with the upper, leading to the conclusion, that it is actually more convenient changing it to:

Code: Select all

var collide:Boolean = (filter1.maskBits & filter2.categoryBits) != 0 || (filter1.categoryBits & filter2.maskBits) != 0;

like they did in Farseer. I don't know which version is like standard Box2D, I just think the OR is better. Try it out for yourself, it saves a lot of pain if you can get rid of all these cross-references - and at least to me, this is the behavior I'd expect (meaning if one object says it collides, it should collide).

3) Would it be possible to implement collision categories?
Of course I could write my own Box2D Components, but I'd prefer working with the official ones.
If you want, I could also do the changes and you merge it.

Puh, long post... if anything is unclear, just point it out and I'll try to clarify it

[HanClinto]

Did a code review -- looks great, Ben!

[Arcanor]

Is r538 considered a better starting point than r470 right now? I've been doing background reading and not started playing with r470 directly yet.

[Arcanor]

Ah I see by reading the thread more carefully that this is a merge in progress. I will wait until Ben says here in this thread that trunk is stable again and get that revision. I'm not in a huge rush to get started as there's still lots of reading to do.