Ashley - Thanks, that's exactly what I needed to know. I think I am going to try and tackle this... I would rather ams.js so I'll see about getting a build done (research first)...

As for the test I just swapped out ams.js with regular box2dweb in a moderate physics game and then watched cpu - nothing fancy and not a real stress test... but I didn't see a big difference in cpu use. I didn't try a max load test.

I've been digging a bit and can't find the answer... Does anyone know what build of box2d construct 2 uses?

Thanks

rexrainbow - I noticed that on your blog the zip file for pid tourque was broken. I also could not find it on the forums here. Is it that supposed to be the case?

It seemed to be doing something similar to what I wanted but I couldn't open it/ unzip it

I like the sound of alpha testing for changes to things like that. Is that possible though, it seems like a lot of this 3rd party software goes through a lot of changes.

So I heard the issue was also related to chrome and not just nw- which makes sense as I have been having trouble with that... is there an update timescale on that or am I out of the loop already?

rexrainbow - Oh my goodness, where have you been my whole life! this website is a gold mine!

So then, nothing bad happens when you call a behaviors action and don't use the event sheet to call it?

...and it works with a behavior and not just a plugin?

TiAm

I just came up with a way to test. I created a bouncing ball project and disabled construct 2 collisions. Physics ran without a hitch. This means any object with physics is having multiple collision algorithms run on it...

I need to set up some tests... I am curious what this collision testing overhead is.

steps 1 and 2 are fast so I am sure it is nominal... but it may add for some interesting optimizations that could occur in a project. Box2d supplies collision information, but it is not exposed to c2. If you want to know if an object is hitting another you have to use c2 algorithm.

Colludium - Well, to be fair, It is impossible to make the perfect tool that does everything perfectly. And I must admit that construct 2 has amazing features... I just feel that physics in particular needs a boost. I also think that in general construct 2 is more suitable for smaller projects due to the lack of pre fabs, compound object mangers, etc... so adding in physics features that someone making a really simple game can live with out may not be worth the time...

Priorities

either way, Ashley will be generous...

Of course, if I was making construct 2, it would have been in xna, only export to desktop machines, etc... But then I would get alot of complaints about other things. and it wouldn't have been construct 2. It would have been much crappier for everything other than want I wanted at the moment... lol

Colludium - There are even the little things in the behavior that can easily be changed...

you know how set position breaks the physics behavior? Basically physics sets the velocity to be the difference of the old and new position. Meaning your object blasts through space at an unreasonable speed...

That isn't box2ds fault... it's how the behavior handles it.

Even the fact that the behavior isn't using edge shapes for the tilemap boggles my mind. I told Ashley about internal seams being a source of collisions when they shouldn't and he said it was not a bug but a box2d thing and dismissed it. It is not a Box2d thing it is a Construct 2 physics behavior thing... am frustrated...

— -

As it turns out, the box2d code for these features is in the behavior script already. I don't see what version of box2d it is (which I would want to know). I don't fully profess to understanding everything I mess with but adding in more features has been surprisingly simple... I just do it in quick and dirty ways... (for example, I added an action to set the object to be kinematic... I keep the programing simple, and usually work through such manners...) I hate to put the full effort to fully enable a feature. It takes a chunk of time (for me longer, because most of it has been figuring out c2 implementation, and making sure I am not messing it up) but even still, my first feature exposure took under 2 hours. Ashley could probably do it in 10 minutes. I just can't justify permanently changing the behavior until I know for sure Ashley won't...

I figure there must be something I am not appreciating here, or some unknown.

-Answer-

Construct does do this but only in specific cases.

"...(disabling c2 collisions) will have no effect (on performance) if you don't test for collisions in events. If you make no collision tests yourself, then the C2 engine doesn't make any collision tests either, so it's irrelevant whether the object has collisions enabled or disabled.

I don't think there's any way around having the two collision tests - not all games use a Physics engine, so C2 needs its own engine. But as I say if you don't use collision events on an object then it will only use the Box2D collision engine." -Ashley

*** ORIGINAL POST ***

Hey everybody,

Does anyone know if construct 2 is using box2d internally for collision detection? Or is it using a custom system to test overlap.

It seems efficient either way, but I wondered if it did implement its own algorithms, wouldn't it basically be doing double time when you are running physics on an object as well? Because you don't ask physics if something has collided... you have to ask construct 2 if something is overlapping...

Just doing some exploring...

***END ORIGINAL POST***

QuaziGNRLnose - It turns out, Ashely said that is a very bad idea... I'm not sure why, just that construct 2 wasn't designed that way. Basically, calling a condition or action of another behavior (even on the same object) from a second behavior doesn't work. I asked for clarification but haven't heard back... I can't even find/remember what post it was in

Colludium - I meant to reference your work from another post. I have since set up tests as well and can't tell a difference between the two. I did it because the regular version is easier to add to the behavior because you can read it at the time of editing.

If there is a dichotomy between full feature set and slightly higher performance... Then I would choose features in a heartbeat. A careful developer can easily work within the constraints of performance considerations, but if you haven't got a tool to use, you can't use. I know ray casting is expensive and shouldn't be done willy nilly all over the place, but I think that the c2 work arounds are much more expensive.

The dumbest part is that I have devised a ridiculous method to determine a collision surface normal on a solid object that involves extra sprite objects, plenty of editor time placing these sprites and setting appropriate variables, all in the knowledge that box 2d can pass this info directly to construct 2. But I don't want to risk making a version of box2d that may become outdated when Scirra adds more features... Then my whole project would be broken.