Awesome!

Please ensure you can see >= "version 1.0.0.7" in the top middle of the display, to ensure you have the correct version running. Thanks.

OK. I learned some good lessons in the last couple of weeks. Please have a try of the latest update - either here or via the updated link in the first post.

This version was created with a completely different collision filtering philosophy and, I have to say, I am very pleased with the results! It also includes an edge behavior function, so you can decide if the player should move back from an edge, move forward, etc.

Performance at idle is not as good as the standard platform plugin, but once you get moving then there's not much in it (< 0.25 ms total time spent for each plugin). The standard plugin was modified for this demo so that the script time could be measured. This means you can compare how much work each plugin is doing at any particular time.

Of note, in my system both plugins occasionally spike at taking more than 1 ms to do their calculations.... and the standard plugin decelerates more quickly (by design) when a move is commanded for the opposite direction of travel.

So, the following are now working:

Triggers:

On jump

On fall

On land

On move

On stop

On wall

Conditions:

Is on floor

Is jumping

Is falling

Is on wall (pick a side)

Is edge behavior moving away from edge

Is edge behavior moving toward an edge

Is passing through a one-way door

Is passing over a one-way floor

I've got do do some more code-tidying, and then add some actions and conditions to the helper plugin (Solid2) that is added to objects with the standard Solid behavior. More info to follow...

Ashley - I haven't looked too deeply at the pixi library but I reckon you're right.

It would be good to have a more modular approach to sprite / drawn objects in c2 / c3 (in the new runtime?). I mean, if you're just using sprites for background imagery, for example, then there's no need for the runtime to keep arrays of data on unused components like collision polygons etc. It would be amazing if that horse hasn't left already and this sort of approach could be included in the future (like many more behavior options to add to a basic particle-like sprite). Just a thought and a hope...

I thought that the C2 bunnymark in chrome outperformed Godot Engine (not Fusion 2.5 because it wasn't in the round-up) and the results were that Unity blew all of them away.

Come to think of it, Pixi.js has by far the best bunnymark results. The c2 bunnymark thread and pixi.js bunnymark. Amazing.

Thanks gameba - good find!

Update published - bug fix - now v 1.16.

Thanks Macbee!

Just an update:

I've been (enjoying?) doing a lot of performance testing. Version 1, which is the demo in the first post, utilised too many overlap checks (and had some bugs) - the performance was not a problem on desktop but not ideal for mobile. I then created a Version 2 that used raycasting... Initially I thought that would have been amazing - it was very fast but I think it lacked flexibility as a general plugin (box shape only, minimum obstacle size required). So it was then back to the drawing board to create a more efficient overlap check version. So far, the optimised Version 3 is doing very well. Performance at idle is slightly up on the standard plugin, but performance when moving is about the same. I've been comparing script time for each plugin - my objective is to ensure that this version will be at least as fast as than the standard (I think that the standard plugin is about as fast as possible in c2runtime if collision shapes are not limited to circles and boxes). I should have a demo of this in the next few days. Happy new year!

Hi gameba - Happy New Year to you too!

I took a look at your capx - weird problem caused by the layout restart. I suspect that it was a combination of the Box2D+ library not coping with the destruction and recreation of a large number of recycled objects all at once. You see, when you set an object to Box2D+ Enabled then the body is destroyed and then recreated, including all joint references. The bug was caused after the layout had restarted.

Here's a capx that contains the fix. The link object default is set Box2D+ Disabled, then - in the joint creation loop - there is a check that the links are disabled before they are set enabled. Before, the links were set enabled twice, once by reference through the family and then in the next loop iteration by reference directly by the link object condition.

I have always been a fan of the Corona SDK performance on mobile. Seriously fast physics and better than Unity I would wager. In fact, I have a partially completed plugin I was developing to use C2 as a layout editor, to export everything for later import into Corona SDK as json data and images. Then I started playing around with Godot and realised that there are better systems out there with a much better development process. But if the Corona devs were ever to create a proper layout editor then I wouldn't hesitate to go back, just for the consistently excellent performance!

Unity is very powerful, but also very complicated - better for a team of devs IMO. The performance on mobile and desktop is excellent, of course. However, I never really enjoyed developing in C#....

Wrapped JavaScript on mobile is getting better, but I remember making a physics demo in Corona approx 6 years ago that a c2 export still cannot compare with on current hardware (compared to my Corona demo working on an old first gen HTC Desire at 60 fps with no jank. Ever!).

Hi — The impulse data is only available after the collision and response have been calculated by the Box2D+ library, and that information is only available at On End-Contact. The Box2D+ World steps many times each tick. The On Begin-Contact indicates when a World step first notes that a collision must be resolved. Each Pre-Solve and Post-Solve then mark the beginning and end of each collision calculation step. Many such calculations will take place for each two colliding objects. Thus, a collision's triggers might look something like:

• On Begin-Contact
• On Pre-Solve
• On Post-Solve
• On Pre-Solve
• On Post-Solve
• On Pre-Solve
• On Post-Solve
• On End-Contact

The impulse (momentum change) inside a collision can only be resolved once the final collision velocity is available, and that is at the End-Contact. Hope this explains it?

This is supported in Containers.

Visual Studio Code. Not much of a game, but the fun happens when I start trying to debug errors .