So I noticed you have to restart construct to get the engine to change. You can't run a game, change from box2d to ams.js, and then re run it. It will still be whatever was selected on start up. I think.

Colludium - thats cool, I like your input. I like everyone's input. I think we have similar wants and desires for physics so it makes sense, lol.

Those benchmarks are interesting too. For whatever reason, in the test I did chipmunk was outperforming the others (not expected) but had a lower stability. I noticed on your tests chipmunk was not doing so well. I am curious at what would cause this. I was using gravity in my tests with elasticity at 100% to maintain perpetual movement. Friction was also 0.

delaflaquita - collision disabling is available as of the r196 and on.

I wanted to add the following:

The version of box2d web that comes with the behavior does not have resetfriction (which is expected, reset has to be used instead). I did a search of the ams.js file I found that it does have resetFriction burried in the garble up top. It is also supposed to be the most recent (2.2.1) version of box2d

In 2.2.1

Box2dBody.getContactList returns a box2dContactEdge object. Using that object you can call:

box2dContactEdge.contact.ResetFriction

In c++ it would look like this:

for ( Box2dContactEdge* contactEdge = body->getContactList();

contactEdge;

contactEdge = contactEdge->next();)

{

contactEdge->contact->ResetFriction();

}

Now, I am rubbish at jscript as a rarely use it, but I could not manage to get this working. (in the SetFriction action underneath this.fixture.SetFriction(f); this.Friction(f);

for (var contactEdge = this.body.GetContactList(); contactEdge; contactEdge.next();)

{

contactEdge.contact.ResetFriction();

}

I keep getting an error about cannot call property "ResetFriction()" of undefined. Are you having anyluck with it?

I thought maybe it has to be part of the contactListener cycle; its where people on the forums were putting it, but I read that doing it after the physics world step was fine. Well, anyway...

Hey everyone,

I did a benchmark test and posted the results on R0j0hound's chipmunk physics forum post.

These were made using a win7 i5 laptop.

The test, Box containing small bouncing balls with 100% elasticity... I continued to add balls until the cpu usage fluctuated to greater than 85%

Box2dWeb: 600

AMS.JS: 850

Chipmunk: 1400

Something to note here which is very important. AMS.JS Keeps low cpu usage and then once you cross a object count it sky rockets to 90-100% . AMS.JS seems to run an average lower cpu usage than regular Box2d web, but I am notice high cpu spikes. If ams.js spikes to be at where Box2d web runs or even above, I am not sure its benifits are worth it.

When I am making a game, I really prefer to have predictable results and right now ams.js has some unpredictability. If you end up using 500 objects and get frequent spikes, then game play could be affected in a variable way (slow, smooth,slow,smooth). If Ams spike to where box2d web runs at then you really can only safely use the same amount of objects. Does anyone have some knowledge of what is happening here?

Box2d is much more linear in its object count to cpu usage. Chipmunk starts to use more cpu as the balls settle (which they shouldn't be doing). The settling becomes more pronounced as the object count increases.

Prominent I am not sure, I didn't run the test very long. Once I managed to reach 85+% I would leave it running for a little bit to make sure it wasn't something else that cause the cpu to spike up. It seems once you reach a high cpu usage, it starts to trend up up until you are at 95-100%. It could be the memory leak, but I thought it was supposed to be a small one. Also... how is there a memory leak? Isn't it written in javascript?

mattb thanks, I need to learn the peculiarities of this engine, but so far I have done little with it.

My hunch is that your object isn't identical in tile size. That would cause it to jump. Also, if your object is an odd count of tiles wide (like 15) .

But codah is right, we need more to tell you anything.

If no one has already posted benchmarks then here we go:

These were made using a win7 i5 laptop.

The test, Box containing small bouncing balls with 100% elasticity... I continued to add balls until the cpu usage fluctuated to greater than 85%

Box2dWeb: 600

AMS.JS: 850

Chipmunk: 1400

Something to note here which is very important. AMS.JS Keeps low cpu usage and then once you cross a object count it sky rockets to 90-100% . Box2d is much more linear in its object count to cpu usage. Chipmunk starts to use more cpu as the balls settle (which they shouldn't be doing). The settling becomes more pronounced as the object count increases.

Hello,

I must first point out that this is not a bug, but an implementation problem that can result in "bugs" if the physics behavior is used in specific ways.

The physics behavior is scaled by a constant worldscale, making the behavior good for objects from 5px to 500px. Box2d has this range limitation, but the scale that it is attached to construct2 can be different. For example, the behavior could work well for objects from 10px to 1000px.

Setting the scale rigidly from within the behavior isn't the best solution unless simplicity and one size fits all is important (which it probably is lol). In a low res pixel game, the limitation is perfectly fine... unless you want a 4 by 4 fireball bouncing around. But in a hires game it's really easy to have objects larger than 500x500. In the past, I have gotten around this simply by scaling all the sprites down, but then you have to have a smaller canvas size... In other projects, I have simply gone into the behavior and changed the worldscale constant. I have to remember to change it during work with other projects and make sure I export it with the correct settings.

My work around works well, but I wouldn't expect the average user to have that option. At the same time I don't think that the average user ever cares about this 5px to 500px limitation. Or they assume that its set in stone and can't be changed.

I probably wouldn't change it but maybe it should be?

Either way... I thought I would bring this to your attention.

I am adding features as I need them to the physics behavior. Unfortunately, The current organization and terminology used by the vanilla physics behavior doesn't make additions of other features as intuitive (Static, dynamic, and kinematic) as it could be. which means the new behavior won't work with your old physics projects. ( of course, if the behavior got updated by construct it would break newer projects, so its a trade off)

If anyone is interested in the results, let me know. It may be that Ashley will be adding these soon, but I can't wait any longer.

Currently, I have added prismatic joints, and kinematic bodies and a few other things. I will be adding edge shapes, an edge shape plugin to make it easy to add collision geometry to a level, and pre collision callbacks and contact information.

I can share the code needed to make changes, which is probably more useful as you could make it work with older projects as well. Most features only take a few lines of code here and there.

Here is the original bug report ^

I am resubmitting this to add the following:

The contact class contains a set friction and reset friction method. When you change the friction on a fixture, you then iterate through all contacts for that body and call reset Friction. You can do this at the time of friction change (best) or during presolve or really at any time. The contact class can be used to manipulate a lot of things, including overriding default mixtures for elasticity, density, friction and so on. You can even use it to ignore collisions on a frame by frame basis for oneway collisions and also use it to create tangent forces/impulses.

contactClassObjectInstance.resetFriction();