Is there going to be a feature update in physics?

Ashely : Is the physics behavior going to be updated, ever? Is it in the plans? And I mean a meaningful feature update... ? I simply want a yes/no response. and if yes, what the plan and timeline is? I feel that construct 2 saying it has box2d powered physics support is like saying hot air balloons fly...

The physics behavior is a shell of what it could be. You know this, I know this. Everybody who knows what box2d is capable of knows this.

If you have no concrete plans for expanding physics support in construct 2 then please let me know. You have hinted that it is a possibility, but I can no longer develop under that speculation. I either need to solidly move my project to unity or commit my changes to the box2d behavior and apply it to the objects in my game.

There have been numerous forum postings expressing interest in the features that box2d already has... and that construct 2 could have. It simply is not possible to make a robust physically enabled game without at least a few more joints and kinematic bodies, edge shapes, pre/post solve, and collision filters (even if done manually during pre solve).

Thanks,

Afaik they want to switch completely to the asm.js version first, but this was a long time ago, and we did not saw any real hint that this is happening anytime soon (not sure which kind of problem they would have with that).

I would also appreciate info if a box 2d improvement is planned. I recently tested and compared the physics options, using the capx I posted in another thread about physics, and I've summarized the results below to highlight that asm.js offers no performance improvement, in spite of what it says on the tin...

On my Nexus + chrome:

box 2d = 190 sprites, asm.js = 190 sprites

On my laptop + chrome:

box 2d = 950 sprites, asm.js = 950 sprites

Aphrodite - I was under the same impression... Though I didn't mean to say that Ashley was hinting that there would be anything anytime soon, just that there may be more features in a situation where Scirra only had one physics exporter to deal with.

I just really need to know if anything is on the horizon. To my knowledge there has been discussions surrounding this topic for a long time. A long time ago, I said to myself, "cool no need to worry about these features I don't have because I just might get them in a future update." So I haven't let it worry me except to post my two cents on the forums here and there. But I am at the point where I actually have to make a big decision. continued development is tied wether i decide:

to commit to my own version of the physics behavior for the next 1.5 years (give or take 6 months), or continue all further development in Unity...

If Ashely does indeed have a concrete plan, then knowing that may save me a lot of work. Knowing there is no plan will also properly motivate me to make a decision as I will know what needs to be done if I stick with construct through this particular project.

It just comes down, "It would be really, really nice to know".

Each decision has its own problems in my project... I have considered going back to simple libraries where I have more control over everything, but that would be equivalent to throwing out the last year's work... and lets face it, I'm not here for the fancy no scripting event editor; I am here because construct is an amazing product that speeds up dev time considerably (I wish one could actually script events... it would take less time than the dialogue window business... anyway...off topic lol)

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.

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....

At least it's not just me who finds this frustrating! I totally agree with what you wrote - we're always hearing how technology will speed up javascript in browsers, so I have no fears about how box 2d will perform in the future.

Your collision surface normal work-around sounds a bit like some of the patches I had to invent for my sketch book game (that I'm just finishing). Some of the logic is pretty ugly, but it seems odd that a full set of box 2d features are not available when these already exist within box 2d and probably reside within the code that c2 exports.

I've also noticed that we've not had any major new features added for a while - I'm keeping my fingers crossed that what we have isn't considered good enough...

— -

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.

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...

That's even worse - it's like a game show - "look at what you could have won...."!! Seriously, though, I can only imagine that we are waiting for either a) a new physics engine to be implemented (very unlikely) or b) trying to avoid confliction with cocoonjs (which is deprecated - so let's bin cocoonjs physics: I bet no one uses it anyway given the poor performance you get on mobile). If Ashley could implement a full set of box 2d features then the c2 engine will be almost complete....

Ruskul - my answer above is out of sync! To your other points - indeed! The only consolation is scirra's box 2d is better than GameDevelop's... I'm kind of hoping that Ashley is feeling generous this year and pays some attention to making this a rather more powerful feature .

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

The physics engine is difficult. I want to go with only the asm.js physics engine, but at the time the asm.js version was built it lacked the ability to disable collisions. That's pretty much the only reason it's not the default, since right now any project using that feature will be broken by switching across to asm.js.

Adding that feature to the asm.js build has become very complicated since Emscripten subsequently got a bunch of updates and broke backwards compatibility. So despite the asm.js physics being open source, it's no longer useful since it does not build with Emscripten any more. I contacted the original developer on a couple of occasions, and they say they are too busy to update it. Besides people are now asking for features like certain types of joints that aren't supported by the (now fairly old) version of box2d that the asm.js version was built against. So to get that one last feature for asm.js and make it the default, the entire asm.js port of box2d needs to basically be rewritten from scratch. That is a pretty complicated project, and the end result may not even be backwards compatible with what we have now either (even just a slight change in the way floating point calculations are rounded can have a cascade effect with results like a tower of objects falling in a different direction with significant change to the gameplay).

Since as ever we get a constant stream of feature requests and we could never have time to deal with them all, we prioritise the easy ones, or the really important ones. This is not easy, and I see the existing situation as acceptable (there is the high-performance option with a single missing feature, or the slower box2dweb which has collision disabling). So weighing it up with the amount of work vs. benefit to be gained, I see it as not ranking very high. That doesn't mean we won't do it, it's just more likely to fall behind other things (like the requests we get for the image editor, and 'open external editor' is a good example of something easy which can bring a lot of benefit).

Box2d and Emscripten are both free open source projects, so in theory anyone could come along and do this work, and then we should easily be able to integrate it back in to the behavior. But with all the other demands other customers are making it's hard to justify ourselves doing that. So if you know how to do it yourself or have any other developers handy, building the latest Box2D with Emscripten and writing the bindings is 90% of the job.

I don't know what tests you guys are running but asm.js typically comes out 3-4x faster than box2dweb for me. I just ran another stress test to confirm: 2700 objects at 30 FPS with asm.js, and 850 at 30 FPS with box2dweb, making asm.js over 3x faster, and that's in Chrome which doesn't yet specifically compile asm.js code like Firefox does.

Ashley - thanks for the update, I completely understand your reasons for not rushing into such a project.

Just for your info, the throttle testing capx I used before and referenced above can be found in this thread. It throttles to approx 50 fps and, across a variety of platforms, I can see no difference in performance between asm.js and box 2d (bouncing balls on screen). It may be that asm.js performs better under stress, but the two have similar limits when used in what I would describe as a more representative project where the intent is to avoid max-ing out the engine.

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.

My biggest fear would be to do work that could be outdated by an update in construct... So... if you could, if you do hear anything or priorities change, could you please let me know, if you think of it...