integrating box2dweb into Phaser

[jun3838]

Hi there,

 

I'm new to Phaser here, previously did some html5 canvas game base on native javascript without any framework or engine. I'm doing a game now on box2dweb, it is running ok in native canvas way, but when i try to port to Phaser, i have some issue. Below are my issue, would appreciate if someone could help or someone would have some example for references:

- box2dweb needs canvas context specify into its engine to render, my problem is i couldn't get context from Phaser game object neither do reference it manually as in
 var context = game.canvas.getContext('2d')

- my box2d game is loaded from a box2d editor called R.U.B.E,  and loaded into canvas. Due to the coordinate system in box2d and canvas is upside down, i need to do some context.save(), context.scale, context.translate, context.restore in order to render proper box2d world into canvas, otherwise it would be upside down, so without reference to context, i couldn't do any of those save and restore.
 

my main problem now is because i loaded the box2d from a json file exported from R.U.B.E editor (which you can find it here https://www.iforce2d.net/rube/), anyone experienced that ?

[Alvin]

Hi, 

 

First of all, I would suggest you to try to use our built-in Physics engine (in the physics/arcade folder).

Especially if you game doesn't explicitly need box2D, as its performance on mobile devices is kind of awful.

 

Next, if you want to access the drawing context : 

game.context

[rich]

Yeah I love RUBE! I had a slide on it in my talk yesterday Box2d performance on desktop is fine, but on mobile browser it's usually quite horrible (depends on scene complexity of course). Right now I'm evaluating p2.js as an alternative.

[jun3838]

 

Hi, 

 

First of all, I would suggest you to try to use our built-in Physics engine (in the physics/arcade folder).

Especially if you game doesn't explicitly need box2D, as its performance on mobile devices is kind of awful.

 

Next, if you want to access the drawing context : 

game.context

Hi Alvin, my game is heavily depend on box2d, actually is literally build in box2d, include map editing and image are created from R.U.B.E editor, that's why that hurts a lot...

 

 

Yeah I love RUBE! I had a slide on it in my talk yesterday Box2d performance on desktop is fine, but on mobile browser it's usually quite horrible (depends on scene complexity of course). Right now I'm evaluating p2.js as an alternative.

Hi Rich, i tried to integrate it with Phaser and had issue, nothing is loaded, if i create all the box2d body from script, it works fine, the issue now is when i load the world from RUBE's export

[LuckieLordie]

Did any of you manage to integrate Box2D with Phaser?

[Scroll3]

UP!

[BlueInt32]

Hi everyone,

I started a box2dweb/pixi game a few weeks ago, without using Phaser but maybe I can speak about my experience with loading RUBE data into a screen world and dealing with the coordinates' madness related.

 

The first thing to do when loading box2d data to canvas is to turn off any sprite display system (I turned off pixi for my part) and rely on box2dweb's Box2D.Dynamics.b2DebugDraw like she does here. Trust me, when you want to display a box2d world, you have many things to fix before even displaying one sprite, that's why I can speak of the subject without even knowing what Phaser is.

 

So turn the debugger on and try to understand where your bodies/fixtures/joints are, in what scale and whether they are upside down.

 

 

The typical things you have to do from box2d's world to screen are (the order is not relevant) :

- scales : in box2d, distances' units are in meters and you are provided with vertices and positions that are in my experience about 100 times smaller than pixels (that is to say if you have a 1x1 square in box2d units, it will be 100x100 pixels on your screen. You may change this but it works well for me. You must thus provide a METERTOPIXEL constant to multiply/divide every coordinate value to the screen

 

- offset : in box2d the origin point (0,0) is in the middle, whereas on the canvas it's top left. So if you want your object to be positionned in the middle of the screen, you have to translate bodies' positions (not vertices, which have relative positions !) to (screen.width/2 / METERTOPIXEL, screen.height/2 / METERTOPIXEL).

Note that moving box2d objects must be done in box2d unit system : you have to be very aware of the coord system you are in before moving anything

 

- miror :last but not least, in box2d, Y coordinates are oriented to the top. This means that when you get json data from RUBE, you have to make every Y coordinate multiplied by -1. But be careful ! This will screw every collisions up because box2d expects fixtures vertices to be provided counter-clockwise in order to correctly manage collisions. And when you miror your box2dworld vertically, you must make a .reverse() on every fixtures' vertices so they are counter-clockwise again (I've spent days on this issue ).

 

 

RUBE's json export format is great and when you buy RUBE, you can also download an already developped loader for box2dweb that can read the exported json and create your box2d world automatically.

 

Hope this helps !

 

[iforce2d]

Hello!

 

I spent this week learning about Phaser, since some of my users have been asking about using it with RUBE. I made a couple of demos:

Basic scene - shows the bare skeleton for loading and a 'dumb' scene

Simple platform game - shows how to find items in the scene, react to collisions and use custom properties.

 

The actual 'game' files for these are quite well commented, but the supporting files still need some attention. Javascript is not my forte, so folks like Rich will probably shake their head in dismay at the lack of namespacing. If you look in the source, you will see two files making up the main part of the loader:

loadrube.js - code that only deals with box2dweb, taken almost untouched from the existing box2dweb loader sample

rube-phaser.js - code that is specific to Phaser and probably causes the most head-shaking

 

Some comments about stuff in rube-phaser.js:

 

The canvas context issue mentioned by jun3838 can be covered by using a Phaser.BitmapData which allows for full context manipulation. To show the debug draw display correctly, you will need to use Phaser.CANVAS instead of Phaser.AUTO, which hopefully should not be a problem because the debug draw is not intended for a final release version.

 

If you do want to draw non-sprite things, you can use the functions getWorldPointFromPixelPoint and getPixelPointFromWorldPoint to get them in the right place. If you want to do a lot of such drawing in world coordinates (same as how the debug draw does), you could use the same context transforms that are used inside the drawDebugData function, and then use world coordinates for drawing. See how the mouse joint is drawn there as an example.

 

The loading requires a few steps to complete. First preload() starts fetching the scene .json as a text resource into the cache. Then in create(), we parse it as JSON, and use a Phaser.Loader to load the images needed by the scene. When it's done it calls onRubeImagesLoaded which can finally create the sprites. And when that is done, we may still want to do something with the sprites (show/hide etc) so the last step of the process is to call afterImagesLoaded.

 

I have made functions called preload_rube,create_rube,update_rube,render_rube which can be placed in the regular preload,create,update,render functions. As you can see in basic.js, preload_rube takes the .json file as a parameter, and update_rube takes an frames-per-second value as a parameter.

 

Unfortunately the touch input pointer positions got messed up when I moved the canvas away from the default position in the very top-left of the page. I think this was due to offsets not being done correctly, but I didn't really have time to figure it out and I was giving priority to mouse input. If you remove everything from inside the body tags, you might have much better touch response. Actually, let me do that for you:

Basic scene 2 - as above but with only canvas on page

aaahh... that's better. On my Nexus7 with Chrome, when the canvas is positioned like that I get a pretty sweet pinch zoom, and touch drag behavior - pretty much the same as a native app

 

I am aware that there are other physics engines already built into Phaser, but using box2dweb for this first iteration made things much easier for me, since a lot of existing code could be reused and I could be sure that the resulting behavior would work as designed in RUBE. Learning both Phaser and another physics engine at the same time, while not really knowing how the Box2D settings would translate into p2.js, was a bit much to handle for right now.

 

It seems like Phaser development is progressing at a furious pace! Great to see such a thriving community too

[iforce2d]

I completely forgot a link to the source code: https://www.iforce2d.net/rube/?panel=loaders (in Javascript section)

[rich]

As a massive fan (and paid customer ) of RUBE this is really exciting to see! It would be great if RUBE exported to P2, but you're right - that would have been a massive undertaking However this thread on github may interest you: https://github.com/photonstorm/phaser/pull/545 it links to the best/fastest version of box2d in JavaScript and the start of a full integration with Phaser too. So if you did want to explore this further, it would be a good place to kick off. Also just to say: adding box2d support to Phaser (using the build I linked to) is something I'd definitely be willing to contribute funds towards making happen. Get in touch if this has any interest