Monkey Box2D Port

Monkey Forums/User Modules/Monkey Box2D Port

muddy_shoes(Posted 2011) [#1]
Box2D is a considerably more difficult porting job than Physaxe and this is still a good week or two away from being in a releasable state. However, it is to a stage where it runs and it looks viable from a performance perspective so I figured I may as well let people know that it's on the way.

There are links below to HTML5 and Flash builds. As with the initial Fling demos, I take no responsibility for your browser falling over or any other calamity that may occur. There are still some major issues, not least of which are broken collisions, a large resource leak that makes it all slow down as you swap from demo to demo and the fact that the rendering and input classes haven't been converted to mojo fully (so several demos that require moving objects with the mouse will make no sense because you can't).

Anyway, that said, here they are. Cycle through the demos with the arrow keys. I suggest that you cycle to the right.

Flash
HTML5

I'll update as I can. Oh, and if anyone is a Box2D expert and wants to suggest where I might look for the collision problem, I'm all ears.

Edit: It's out and the project home is here: http://code.google.com/p/monkeybox2d/


muddy_shoes(Posted 2011) [#2]
The slowdown is fixed.


Xaron(Posted 2011) [#3]
That's awesome dude! No need for chipmunk anymore I guess.


slenkar(Posted 2011) [#4]
good demos, good job sir


OvineByDesign(Posted 2011) [#5]
Excellent work so far! Yea notice there's a few collision problems so far - speed is good tho


muddy_shoes(Posted 2011) [#6]
No need for chipmunk anymore I guess.


I wouldn't say that necessarily. Presumably there's a reason why chipmunk exists as well as Box2D in other languages. On the other hand, I could understand feeling less interested in slogging through a port of a library that is a duplicate to some extent.


skid(Posted 2011) [#7]
Interesting, having the flash demos running in another tab really nails performance of other tabs on my machine, (even when monkey tab is not displayed).

I'm not getting it with multiple demos running of other engines: eg

http://www.sideroller.com/wck/


simonh(Posted 2011) [#8]
Wow, awesome work! Was hoping/praying someone would manage to convert Box2D, but had my suspicions it was too difficult (certainly I was put off after looking at the code).

I've used Box2D at work with C++ and I'm not sure I could do without it now, it's that good. Monkey and Box2D would be perfect.

Good luck with the rest of the port - fingers crossed you can get the collisions working. I'll be happy to send a donation your way should you get it fully working.


muddy_shoes(Posted 2011) [#9]
@simonh: I hope so too. To be honest it's a bit of a needle in a haystack hunt for what the issue is at the moment. It's much easier when things definitely don't work, but the collision detection just seems sloppy rather than completely broken.

@skid: That does seem odd. I wouldn't have thought that flash or the browser would allow a program to hog the CPU like that.


slenkar(Posted 2011) [#10]
im not an expert but have you tried experimenting with update rates to solve the collision issues?


muddy_shoes(Posted 2011) [#11]
Increasing the update rate does improve the situation but doesn't really fix the problem as the port should behave the same as the existing Box2D ports to Flash and Javascript. They both have some slack in the collision but they don't have objects passing through other object and the floor as the Monkey port currently does.

Besides that, increasing the update rate to fix the collisions results in unacceptable performance.


slenkar(Posted 2011) [#12]
ok, did you try to contact any authors of ports?

maybe they had similar problems


muddy_shoes(Posted 2011) [#13]
I've found and fixed part of the collision problems so that objects don't pass through each other. There's still some other issue that seems to cause a problem with velocity updates when some objects approach each other, which you can see as the ball drops towards the ramp in the stacks demo. The bug-hunt goes on.

I've also fixed some of the rendering and added the mouse handling stuff so you can grab things and move them around now.


matt(Posted 2011) [#14]
Great work!

Can you possibly post some sample monkey code for one of the examples?


muddy_shoes(Posted 2011) [#15]
Sure, but it's not very Monkey-like. When porting something like Box2D there's always a decision about whether to convert to naming conventions and idioms of the target language or stick closely to the original in order to benefit from the shared knowledge. At the moment the code reflects its origins as a Flash port of a C++ library.

Anyway, FWIW, here's the set-up for the stacks example.

Class TestStack extends Test

    Method New()
	Super.New()
	'// Set Text field
	name = "Stacked Boxes"
	'// Add bodies
	Local fd :b2FixtureDef = New b2FixtureDef()
	Local sd :b2PolygonShape = New b2PolygonShape()
	Local bd :b2BodyDef = New b2BodyDef()
	bd.type = b2Body.b2_Body
	Local b :b2Body
	fd.density = 1.0
	fd.friction = 0.5
	fd.restitution = 0.1
	fd.shape = sd
	Local i :Int

	'// Create 3 stacks
	For Local i:Int = 0 Until 10 
            sd.SetAsBox((10) / m_physScale, (10) / m_physScale)
	    bd.position.Set((640/2+100) / m_physScale, (360-255+i*25) / m_physScale)
	    b = m_world.CreateBody(bd)
	    b.CreateFixture(fd)
	End 

	For Local i:Int = 0 Until 10 
            sd.SetAsBox((10) / m_physScale, (10) / m_physScale)
	    bd.position.Set((640/2-0+Rnd()*0.02 - 0.01) / m_physScale, (360-5-i*25) / m_physScale)
	    b = m_world.CreateBody(bd)
	    b.CreateFixture(fd)
	End 

	For Local i:Int = 0 Until 10 
            sd.SetAsBox((10) / m_physScale, (10) / m_physScale)
            bd.position.Set((640/2+200+Rnd()*0.02 - 0.01) / m_physScale, (360-5-i*25) / m_physScale)
            b = m_world.CreateBody(bd)
	    b.CreateFixture(fd)
        End 
	
        '// Create ball
	Local cd :b2CircleShape = New b2CircleShape()
	cd.m_radius = 40/m_physScale
	fd.density = 2
	fd.restitution = 0.2
        fd.friction = 0.5
        fd.shape = cd
        bd.type = b2Body.b2_Body
        bd.userData = New StringObject("ball")
        bd.position.Set(50/m_physScale, 100 / m_physScale)
        b = m_world.CreateBody(bd)
        b.CreateFixture(fd)
			
        '// Create ramp
        Local vxs := [New b2Vec2(0, 0),
                      New b2Vec2(0, -150 / m_physScale),
                      New b2Vec2(200 / m_physScale, 0)]
        sd.SetAsArray(vxs, vxs.Length)
        fd.density = 0
        fd.friction = 0.5
        fd.restitution = 0.1
        fd.shape = sd
        bd.type = b2Body.b2_staticBody
        bd.userData = New StringObject("ramp")
        bd.position.Set(0, 430 / m_physScale)
        b = m_world.CreateBody(bd)
        b.CreateFixture(fd)
    End
End 
	



muddy_shoes(Posted 2011) [#16]
Found and killed the bug with objects slowing down as they neared a collision. The only remaining obvious problem comparing to the Flash Box2D port is that the CCD demo isn't as stable.

Once that's resolved it's down to tidying up the code a bit and then it should be ready for a release.

I've noticed that the GLFW build has poor performance though, so there could be some work to do there, either in the Box2D code or perhaps in the monkey GC.


OvineByDesign(Posted 2011) [#17]
Excellent news - well done


muddy_shoes(Posted 2011) [#18]
And it's released:

http://code.google.com/p/monkeybox2d/


therevills(Posted 2011) [#19]
Congrats! Im guessing you used JungleIDE when you developed this ;)

How do you run the demos?


muddy_shoes(Posted 2011) [#20]
The answer is "yes and no". My comments on Jungle IDE are at the end of this thread: http://monkeycoder.co.nz/Community/posts.php?topic=949.

The Box2D demo works much like the Fling demo and there's a quick start page here: http://code.google.com/p/monkeybox2d/wiki/QuickStart


therevills(Posted 2011) [#21]
Thanks for that Mr Shoes - I guessed with Jungle due to all the new lines at the end of your files :P

Wow it takes awhile Semanting... but looks great - Well done!


muddy_shoes(Posted 2011) [#22]
That may be a result of the files passing through Jungle, or it could be my C# Flash->Monkey hacker or my Python tidy-up scripts.

...or maybe they're just from me beating my forehead against the return key during the several days of staring at code looking for translation errors.


therevills(Posted 2011) [#23]
It was a bug in JungleIDE (recently fixed) - every time you compiled, it would add a new line to your file...

Heres your very first issue:

http://code.google.com/p/monkeybox2d/issues/detail?id=1

;)


muddy_shoes(Posted 2011) [#24]
Heh. I'll happily punt that to Mark. I can't test on any of those targets (well, there's the Android emulator, but I think I'd go mad testing on that) and have to assume that if it works on HTML5, Flash and GLFW then it should be working on the others too.


invaderJim(Posted 2011) [#25]
I found the culprit for the non-compilation issue:

Line 188 in testcrankgearspulley.monkey, you're casting to the b2PulleyJoint type without assigning it to a value, which confuses the translator.

Removing the type-cast fixes the issue :)

No worky:
b2PulleyJoint(m_world.CreateJoint(pulleyDef))


Worky:
m_world.CreateJoint(pulleyDef)



Oh, and great work on porting this. Makes this monkey junkey very happy :D


AndyGFX(Posted 2011) [#26]
When i try compile it on Android target, compilation crash with:

compile:
    [javac] d:\software\android-sdk-windows\tools\ant\main_rules.xml:384: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
    [javac] Compiling 2 source files to d:\software\Monkey\bananas\box2d\demo_start.build\android\bin\classes
    [javac] d:\software\Monkey\bananas\box2d\demo_start.build\android\src\com\monkey\MonkeyGame.java:8459: not a statement
    [javac] 		(bbt_8 instanceof bb_b2pulleyjoint_b2PulleyJoint ? (bb_b2pulleyjoint_b2PulleyJoint)bbt_8 : null);
    [javac] 		^
    [javac] 1 error



Raz(Posted 2011) [#27]
Just looked at the examples, well done muddy shoes :)


DIJ(Posted 2011) [#28]
Love the examples :)


c.k.(Posted 2011) [#29]
I can't get it. The link for the source (hg repo) gives a 404. Heeellllpp! ME WANT!!! :)


muddy_shoes(Posted 2011) [#30]
@c.k.

You don't click on that link, it's for use if you're cloning via Mercurial. If you just want a download then the use the zip at: http://code.google.com/p/monkeybox2d/downloads/list .

I'll get on to those errors later today. The sun's just coming up and it looks too nice out there to be tapping keys. I'm off to the Abel Tasman for a walk.

Edit: Bloody forum auto-linking.


c.k.(Posted 2011) [#31]
I'm using TortoiseHG and it reports the 404, both from the GUI as well as the commandline.

I guess everybody else is getting the ZIP file, eh?

(And careful... the link you gave me has an extra '.' at the end, which gives a 404...) :)


muddy_shoes(Posted 2011) [#32]
Ah, I messed up the command and removed a space. The repo is at https://monkeybox2d.googlecode.com/hg/


OvineByDesign(Posted 2011) [#33]
Well done muddy shoes shall have a good play with this later


skid(Posted 2011) [#34]
Trying the new demo on my Mac but no luck, seems to be trans throwing a wobble:


TRANS monkey compiler V1.14
Parsing...
Semanting...
terminate called after throwing an instance of 'char*'

Process Complete


Oops, my bad, working now.... and collisions look awesomely fixed!


c.k.(Posted 2011) [#35]
I'm seeing a few glitches. Are these something that can be fixed, or are they just part of Box2D with Monkey?

1. Stacked boxes (ball drop on ramp and knocks over blocks): when it hits the ramp, you can often see the ball go beyond the ramp's surface before coming back out and rolling down the ramp (just press 'R' and you'll see it eventually). The Box2DFlash demo doesn't show this behavior.

2. One-sided platform: the ball can be dragged through the wall in the direction that is supposed to be blocking. Drag it fast enough and it goes right through. The Box2DFlash demo shows this behavior as well.

This is a great addition to the Monkeyverse. THANK YOU! :)


muddy_shoes(Posted 2011) [#36]
The Monkey demo is "taller" than the Flash demo and things have farther to fall and are therefore colliding at greater speeds. Box2D collisions are of the "allow overlap and then apply forces to separate" variety, as you can see most clearly with the stacks. I think of them as "squishy". Also, without CCD on, it's always going to be possible for collision tunnelling to occur (and I'm not sure that the CCD is infallible either, just better).

I'm not saying that the port is bug-free, by any means, but physics engines built to perform reasonably for game usage on moderately powerful devices generally require some compromise and you need to tweak settings and design around limitations. That said, if anyone with Box2D experience spots something that they think is definitely wrong then I'll certainly look into it.


muddy_shoes(Posted 2011) [#37]
There's a new 1.02 release.

* I believe I've found and fixed the CCD bug. It was due to me thinking that IntObject would be unboxed when performing an equality test. It isn't.

* I've altered the demo code so that the physics runs at 60fps with the rendering at 30fps. This tightens up the simulation nicely. If you're using the library in anger then you might want to spend some time experimenting with an optimal update rate for your purposes.

* I've added a domino pyramid test example, just because I like them.


Xaron(Posted 2011) [#38]
Just great, thank you!


c.k.(Posted 2011) [#39]
Looking great muddy! Thank you!


DruggedBunny(Posted 2011) [#40]
Brilliant work, thanks.


DruggedBunny(Posted 2011) [#41]
Just playing a little more, something seems to be up with the rendering on GLFW and XNA for me -- both flicker or show "ghost frames" and the XNA version crashes completely after a few seconds.

I had a quick look at OnRender but I don't really follow the "m_currTest.OnRender" stuff.


muddy_shoes(Posted 2011) [#42]
What does "crashes completely" entail? Is it repeatable? Is there an error message?

I can only test HTML5, Flash and GLFW and they all work fine for me. Is anyone else seeing problems with the GLFW build?


Cheese(Posted 2011) [#43]
@DruggedBunny

I believe I had a similar problem. (Flickering 'ghost' frames in GLFW (and extreme performance decrease), high-frequency flashing of purple in XNA, and the inability to compile for Android)

Doing the following seemed to remedy the issue for me just now:
- Update to the latest monkey release: v42(b)
- Ensure that you delete the demo's build folder after updating the module to the 1.02 release.


muddy_shoes(Posted 2011) [#44]
And now 1.03, which fixes a problem I found with removing objects from the simulation.

Edit at 18:45 NZ time - I just re-uploaded after finding another issue in the same area. If you're the one person who already downloaded the zip then you should grab the new one.


luggage(Posted 2011) [#45]
I've got the latest version of Box2D and Monkey but I get the following errors when building for XNA.

Program.cs(6605,4): error CS0201: Only assignment, call, increment, decrement, and new object expressions can be used as a statement [MonkeyGame\MonkeyGame.csproj]

I get that twice, once for the PC build and once for Xbox.

I also get the ghosting issue under GLFW.


DruggedBunny(Posted 2011) [#46]

What does "crashes completely" entail? Is it repeatable? Is there an error message?



Windows closes down the XNA version after a few seconds' running time. However, I think this is a problem with my setup if nobody else is running into it -- all Monkey XNA programs have started crashing (though none of them give rendering errors before they do).

GLFW seems fine for all other programs, so I'm still seeing rendering problems only in the box2d demo, on both GLFW and XNA. The XNA crashing isn't related to box2d.

Here are a couple of short videos of what I see (doesn't capture the ghosting effect but you can see it jumping back and forth a frame or two while running in GLFW and some horrendous purple flickering in XNA)...

http://www.hi-toro.com/monkey/box2d_glfw.avi
http://www.hi-toro.com/monkey/box2d_xna.avi

It'd be nice to know if anyone else is getting similar results or if it's just me!


muddy_shoes(Posted 2011) [#47]
@luggage:

I get the XNA compile failure too. I don't have any way to run the result so it often slips my mind to try it. The problem was me neglecting to assign an array resize back to a Field. I've fixed it and uploaded 1.04.

The problem is here:

    newArr.Resize(newLength)


gets translated to:

    (Object[])bb_std_lang.resize(bbt_newArr,bbt_newLength);


...which the C# compiler gets upset about. I notice there are also a ton of warnings on the XNA build. I'll have to take a look through them to see if there's anything there pointing to an issue in the Monkey code.


skid(Posted 2011) [#48]
my bad


muddy_shoes(Posted 2011) [#49]
Okay, I've installed the Games for Windows Live crapola to look at the XNA build and it seems to me that it's caused by double buffering behind the scenes. The box2d demo sets the update rate to 60FPS but only renders at 30FPS. It looks like the XNA target assumes that you're going to draw a frame every update and flips the buffers. Seeing as the demo draws on alternate updates, one of the buffers is empty.

I guess this could also be why you're seeing odd frame jumping on your GLFW build and others, like me, don't see it because their OpenGL implementation is different.

I'll have to have a think about what to do about this. Not being able to have an engine update that is separate from the render rate is a real pain if that's the situation.

Edit: After brief consideration, this should be easily fixable for Box2D as I can just do double physics updates at 30FPS. I think I'd still rather have the ability to set the render rate separately in general though.


muddy_shoes(Posted 2011) [#50]
And I've uploaded 1.05 with the rendering/physics update variance mechanism swapped. This fixes the XNA flickering for me. Hopefully it will resolve issues on GLFW builds too.


OvineByDesign(Posted 2011) [#51]
latest upload (1.05) fails to run using HTML5.

"Script: file:///C:/monkey/tmp/untitled1.build/html5/main.js:17436"

Using latest monkey build + IE and also tried FF4


Bit more testing "domino pyramid" is the part that broken. Its not crashing its just taking an age todo anything :S

other tests work fine


c.k.(Posted 2011) [#52]
How do we attach physics to objects in our scene? Is this covered in the repository somewhere? by example maybe?


muddy_shoes(Posted 2011) [#53]
www.box2d.org has documentation and there are plenty of Box2D tutorials elsewhere on the web. I haven't messed with the class or method names much so anything written about recent versions of box2d in general or the Flash port specifically should be applicable to the Monkey port. You can also look at the files in the demo and tests folders.


c.k.(Posted 2011) [#54]
So there's nothing Monkey-specific about applying physics to our objects? I would have thought it would require wrapper code or something. I'll study the code and figure it out... or I'll ask more questions. :)

Thanks muddy!


muddy_shoes(Posted 2011) [#55]
I uploaded 1.06 during the downtime, which should resolve the issues with FF and IE declaring the demo as an unresponsive script. It's always going to be possible for that to occur if your PC is slow enough though.

A note on performance in general:

The demo is actually a fairly good showcase for how far in front of IE and FF Chrome's V8 JS engine is. I've looked at profiles on all three and it seems as if V8 does a number of basic optimisations that mean that a number of things that rank as expensive on FF/IE are negligible on Chrome. For example, there seems to be a high function call overhead on FF/IE, but not on Chrome.

Outside of JS, the nature of the port and Monkey mean that performance is compromised across the platforms. The algorithms themselves should be fine (or as fine as Box2D in general, anyway) but there's significant overhead resulting from the layers of translation.

One such expense comes from the FlashArray class, which I used to simplify the porting. This suffers from Monkey's limitation on exposing generic arrays, which means that direct indexing goes through Get and Set methods. If the target platform can optimise this out then it's not a problem. If not (like IE/FF) then, well, it is.

Another example is the trig functions. Monkey's trig functions use degrees as their angle unit while pretty much every other language uses radians as standard. Radians are also the most common unit in the maths used in calculations for stuff like physics and Box2D is no exception. So, in the Box2D code, all the trig functions are wrapped in conversion layers that translate radians to degrees and vice versa to work with Monkey's degree based maths library. Then, Monkey does its thing and translates that code and reverses the unit conversion to call the target platform's own trig functions that are radian based.

The result is stupid code like this:

float D2R=0.017453292519943295f;
float bb_flashtypes_Math::bb_Cos(float bbt_rads){
    return (float)cos((bbt_rads*57.2957764f)*D2R);
}


Which, to be frank, makes me want to punch a wall.


DruggedBunny(Posted 2011) [#56]

Monkey's trig functions use degrees as their angle unit while pretty much every other language uses radians as standard



To be fair, I'm pretty sure Mark would much prefer things to work in radians, and it's only because of whiners like me, who can't imagine how anybody could even begin to visualise problems in radians, that Blitz* and Monkey use sane and rational degrees. Sorry!

Still, couldn't people over-rule that if they really wanted to, wrapping the standard cos/sin as required?


slenkar(Posted 2011) [#57]
radians are a bit harsh for people like me who dont even know what they are,


marksibly(Posted 2011) [#58]
Hi,

I have been meaning to add radian versions of the trig stuff for ages now but keep putting it off - will get onto it ASAP!

How do Sinr, Cosr etc sound?

Another idea would be to change Sin, Cos etc to use a global scale var (so they could work in either radians or degrees), and also add Sind, Cosd etc.


muddy_shoes(Posted 2011) [#59]
Still, couldn't people over-rule that if they really wanted to, wrapping the standard cos/sin as required?


That's what I'm talking about though. The Box2D port has wrappers that convert between radians and degrees. The point is that the Monkey translation is also creating a wrapper going the other way. The result is code that does nothing but burn processor time introducing inaccuracy.

Sure, I could write my own maths library with native implementations for trig operations that don't do this conversion but that would start to move the port away from being a pure Monkey implementation.

My point isn't to argue that radians are "better" than degrees. I'm just explaining that there are performance compromises involved and the trig conversions are a good example of that.


DruggedBunny(Posted 2011) [#60]

My point isn't to argue that radians are "better" than degrees. I'm just explaining that there are performance compromises involved and the trig conversions are a good example of that.


I didn't mean to sound like I was arguing, just explaining why Mark went the degrees way. Still, see his post above!


muddy_shoes(Posted 2011) [#61]
@DruggedBunny

Don't worry, I didn't think you were being argumentative. I was just trying to avoid the thread becoming a home for a debate about preferred units.

@Mark

CosR, SinR etc. seem fine to me. I'm not sure what the implications of your scaling factor would be on generated code. My desire would just be to have a way to write code that converts directly to the native library calls.


muddy_shoes(Posted 2011) [#62]
If anyone has a couple of minutes, could you compare the following builds of the demo:

Standard
Test

If you could let me know what render and update rates you see on the pyramid demo, what browser you're using and some idea of your CPU, that would be great. Oh, and please give me numbers when the pyramid is actively simulated and not the rate after it dims. When it dims it means that the bodies are considered settled and they get ignored.

I'm particularly interested to hear from non-Chrome users or those with low-powered netbooks and the like.


c.k.(Posted 2011) [#63]
Holy moly, muddy! How come those run so much faster than my local versions (which barely run if at all)?

Standard Render: 30FPS, avg 5ms, max 194FPS
Standard Update: 61, 4ms, 241/sec

Test Render: 30, 6ms, 180/sec
Test Update: 60, 9ms, 117/sec

However, these values fluctuated wildly.

Chrome 13.0.782.32 beta-m
Pentium(R) Dual Core E5300 @ 2.6GHz
4GB RAM
Windows 7


muddy_shoes(Posted 2011) [#64]
@c.k.

I've no idea why they run faster than your local build. There should be no difference between the Standard build above and what anyone would get locally with 1.06 of the library and V42b of Monkey.


c.k.(Posted 2011) [#65]
I don't know if I upgraded to 1.06 or not. I'll check on that. It will have to be tonight. I'll check it out.

Look how precarious this collapse is. It's actually at rest here. :D




c.k.(Posted 2011) [#66]
Here's a fun challenge: remove the top three bricks without the pyramid collapsing. It's more difficult than you think! :)




c.k.(Posted 2011) [#67]
I've tried it on another PC:

Windows XP Professional, SP 3
Intel Pentium(R) 4 CPU 3.00GHz
1GB RAM
latest Chrome beta

FPS gets down to 9. updates get down to low 40s. But performance is horrible. Can barely grab a brick. Can only slowly carry it away, no throwing it.


muddy_shoes(Posted 2011) [#68]
Yeah, performance will be bad. I'm more interested in seeing what the difference is between the two builds when the going gets tough. Did you see any difference?


c.k.(Posted 2011) [#69]
Okay, my PC at home:

Actual physics updates/sec: 28, Avg update: 34ms (max. 29 updates/sec)
Actual drawn FPS: 2, Avg. Render time: 6ms (max. 158 frames/sec)

That's using code on my own PC, running from JungleIDE (with F5).

The links you posted above give far better performance, as follows:

Actual physics updates/sec: 60, Avg update: 7ms (max. 147 updates/sec)
Actual drawn FPS: 30, Avg. Render time: 3ms (max. 290 frames/sec)

Chrome (latest beta)
Win7 64-bit
8GB RAM

Unfortunately, I didn't test both links on the old PC. I'll try to do that next chance I get. :)

o.O


muddy_shoes(Posted 2011) [#70]
I'm just going to bump and repeat the request as I can see plenty of hits on the demos but people seem reticent to say anything about what they're seeing...

If anyone has a couple of minutes, could you compare the following builds of the demo:

Standard
Test

If you could let me know what render and update rates you see on the pyramid demo, what browser you're using and some idea of your CPU, that would be great. Oh, and please give me numbers when the pyramid is actively simulated and not the rate after it dims. When it dims it means that the bodies are considered settled and they get ignored.

I'm particularly interested to hear from non-Chrome users or those with low-powered netbooks and the like.


Difference(Posted 2011) [#71]
Modelnavn: Mac mini
Model-id: Macmini3,1
Processornavn: Intel Core 2 Duo
Processorhastighed: 2,53 GHz
Antal processorer: 1
Antal kerner i alt: 2
L2-buffer: 3 MB
Hukommelse: 4 GB
Bushastighed: 1,07 GHz

Chipset-model: NVIDIA GeForce 9400
Type: GPU
Bus: PCI
VRAM (i alt): 256 MB



Standard:

Test:


Test seems faster. :-)


muddy_shoes(Posted 2011) [#72]
Thanks, that provides some confirmation of my own tests. Which browser are you using? Safari?


Difference(Posted 2011) [#73]
Firefox 5.0


OvineByDesign(Posted 2011) [#74]
FF 4
dual core 2.8
standard 19ms max 13 and 15ms max 66 ( 2 fps)
test 21ms max 50 and 15ms max 66 (11 fps)

iMac + safari
standard 21ms max 48 and 14 max 75 (2 fps)
test 23ms max 47 and 12 max 80 (12 fps)


Netbook + FF5 (atom 1.6)
standard 225mx max 6 and 94ms max 11 ( 0 fps)
test 250ms max 5 and 90ms max 11 (2 fps)


muddy_shoes(Posted 2011) [#75]
Cheers, Ovine. It seems fairly conclusive that the test variant produces visually better performance under stress.


skid(Posted 2011) [#76]
@muddy_shoes, I'm using your box2d module in my latest project and it's all going really well.

The only hickup I've had is this morning trying to use a weld joint. It doesn't seem to have any effect.

Have reverted to using a revolute joint to solve the problem but thought I'd mention it.


muddy_shoes(Posted 2011) [#77]
If you have an example of code that you'd expect to work that doesn't could you post it? I haven't yet used any of the joints outside of converting the examples, so it's very possible there's an issue that I haven't seen.


skid(Posted 2011) [#78]
When I had time I was going to scan through the examples see if I could find a revolute joint in action and replace with a weld. The manual mentions a cantilever example but I'm a bit busy today to investigate further sorry.


mangoo(Posted 2011) [#79]
Firefox 4 on a virtual windows machine.

For the first demo "Test" runs acceptable ( 15fps ), the "Standard" one is very slow here (5 fps)

Same applies to the other demos, i would say that Test is ready to use :-)


muddy_shoes(Posted 2011) [#80]
Unfortunately, the test version changes that provide the smoother visual frame-rate are actually to the mojo update loop, and not to the Box2D code. I sent the changes to Mark but received no response, so I assume he's not interested.

Edit: I did notice that the update loop had been altered a little recently, so I should probably redo the tests to see if the gap has been reduced.


muddy_shoes(Posted 2011) [#81]
1.0.7 is up. No functional changes, but I've done some work to remove the slow fake Flash array type which should get an extra frame or two. I've also changed the demo a bit to make it more friendly to touch-based devices. You can now change the example by tapping the top left or right corner and the escape key/stepback exits.

Download:
http://code.google.com/p/monkeybox2d/downloads/list

Demo:
Flash
HTML5
HTML5 with custom mojo update loop


muddy_shoes(Posted 2011) [#82]
Just in case anyone is pulling updates directly from the googlecode repo, consider yourself warned that there are commits going in that will break client code. I'm starting to remove transient object allocations and that means changing interfaces throughout.


MikeHart(Posted 2011) [#83]
Thanks!


OvineByDesign(Posted 2011) [#84]
Muddy how far have you got into committing the "removal of transient object allocations" ?

We any nearer to start using your port without fear of interface changes ? :)


muddy_shoes(Posted 2011) [#85]
How far? Half?

I won't delete any of the previous versions so if you're running on one of the zip downloads then you're fine. I was just warning people that the main repo was undergoing change in case anyone was directly pulling changes from trunk.

If you are pulling changes from trunk then I can't make any promises. I'm not doing anything at the moment but that's only because I'm busy with other things. When and if I get annoyed by the remaining garbage creation I'll be back in there and breaking things again. It's not too bad but there's definitely room for improvement. I see the GC kick in about every ten seconds or so for 50-100ms on my current box2d-based project on Android.

Even if you are working from the repo, if you just put a freeze on pulling changes while you finish whatever it is you're working on, you'll be fine.


OvineByDesign(Posted 2011) [#86]
many thanks :)


Armitage1982(Posted 2011) [#87]
Hi

I've just try the last 1.07 on the iOS emulator it's running fast but natively on my iPod touch 4 it's crazy slow (maybe 1FPS every 2 secs). Other than that it's working :)

I now wondering, if there is optimization to be done on the iOS platform: how do you proceed?
Writing some kind of native trans code in objective-C?

I ask because i'd like to understand the general work flow of Monkey.
Thanks


skid(Posted 2011) [#88]
That is most likely the debug outline graphics, once you turn that off and hook up your own image based rendering the module flies.


muddy_shoes(Posted 2011) [#89]
I don't own any iOS devices so I've never tried it. If there's a performance issue then someone need to run a profiler and see where the time is going. It could be the debug drawing but it could equally be elsewhere, such as monkey's garbage collection.


Armitage1982(Posted 2011) [#90]
Make sense.
I cannot help you yet about the profiling but as soon as I can I will give you feedback on this.
But I think skid is right, outlines are quite expensive.


Volker(Posted 2011) [#91]
There is a bug in b2gravitycontroller.monkey. Will not compile
"Constants.F_MIN" must be replaced two times with "Constants.FMIN".


Beaker(Posted 2011) [#92]
Is it just me or does the zip for v1.07 contain a corrupted maindemo.monkey file?


Armitage1982(Posted 2011) [#93]
I wasn't able to run the v1.07 with the last monkey (v50) too...


Beaker(Posted 2011) [#94]
You just need to add this to the bottom of maindemo.monkey:
Function Main()
	New MainDemo
End


You possibly need an extra End before that function as well, can't remember.


Armitage1982(Posted 2011) [#95]
... Oh yeah !
I forgot it was working this way. Sorry !

Waw, this version as all I need. I wish it exist in BlitzMax :p

What can you tell me about the state of the port ?
Seems to be already pretty usable in GLFW. Anything is missing ?
Thanks


muddy_shoes(Posted 2012) [#96]
I enabled reflection and then went through cleaning up all the newly revealed compilation errors. This may well have fixed issues with previously non-working parts of the code so it's worth a release. There's a 1.0.8 zip uploaded: http://code.google.com/p/monkeybox2d/downloads/list


Paul - Taiphoz(Posted 2012) [#97]
this is looking better and better every time I look at it, and makes me wana do something with it, after my current project is out the way.


muddy_shoes(Posted 2012) [#98]
I did some comparison testing between the Monkey Box2D port and libGDX's JNI version today. If anyone is interested: http://pointlessdiversions.blogspot.co.nz/2012/03/monkey-vs-libgdx-box2d-performance-on.html


CopperCircle(Posted 2012) [#99]
Interesting read, I am happy with the performance so far, but I have not really stressed it, still cross platform is great with Monkey.


Armitage1982(Posted 2012) [#100]
I'm trying to port the current version of box2d for BlitzMax.

I was wondering if you could help me for a small issue ? http://blitzmax.com/Community/posts.php?topic=97594

Thanks !


muddy_shoes(Posted 2012) [#101]
Sorry, I'm not a BlitzMax user so I can't offer any help.


muddy_shoes(Posted 2012) [#102]
1.0.9 (or 1.09, I seem to be inconsistent on the topic) zip uploaded: http://code.google.com/p/monkeybox2d/downloads/list.

* Fixed collision bug that only really shows when using large sensors.
* Very small optimisation to the FlashArray class.
* "Strictified" the module.


NoOdle(Posted 2012) [#103]
Wow this has improved a lot since I last tried it. Thank you for all the hard work you have put into this!

I added some extra stuff to ray casting so that I could get the point of the intersection. This is what I added:

This new callback in b2world:
Class InnerRayCastToPointCallback Extends InnerRayCastCallback
    Field result:b2Vec2
    Method Callback : Float (fixture:b2Fixture, point:b2Vec2, normal:b2Vec2, fraction:Float)
        result = point
        Return fraction
    End
End

And also this new b2world method:
    Method RayCastToPoint : b2Vec2 (point1:b2Vec2, point2:b2Vec2)
        Local callback:InnerRayCastToPointCallback = New InnerRayCastToPointCallback()
        RayCast(callback, point1, point2)
        Return callback.result
    End

Seems to work well. Is this the best way of doing it or is there another technique already implemented to do this?

[edit 2] Ok after some more playing around and further investigation of the source, I'm starting to understand how the ray casting is done. Is there a reason why b2RayCastOutput doesn't store the point of intersection?

[edit 3] For now I've added the point to the ray cast output. That way I can easily get the intersection point by doing fixture.RayCast( output, input ) and then using output.point instead of having to calculate the blend between p1 and p2 myself.

This in b2RayCastOutput:
Field point:b2Vec2 = New b2Vec2()

This in b2polygonshape in the RayCast method just below the normal calc at the bottom.
			output.point.x = ( input.p2.x * output.fraction ) + (( 1 - output.fraction ) * input.p1.x )
			output.point.y = ( input.p2.y * output.fraction ) + (( 1 - output.fraction ) * input.p1.y )	



muddy_shoes(Posted 2012) [#104]
I can't say that I've used the raycasting, so I haven't looked into the ins and outs of how to do it best. This page has a decent overview (if you get past the Ron Paul sales pitch) - http://www.iforce2d.net/b2dtut/world-querying .

I wouldn't recommend adding code to the box2d library files simply because it'll be awkward to update in the future. You should be able to put your callback and the wrapper function in your own code and just call Raycast on your b2World instance.

If you want to get back all the ray intersections then take a look at RaycastAll. That returns a FlashArray* listing all the b2Fixtures that are hit. You can either use it as a template and create a new callback based on the InnerRayCastAllCallback that collects the info you want or you could just use the list it returns and b2Fixture.Raycast to get the specifics.


* This class is just a remnant of the porting. It may well disappear at some point and be replaced by a standard array.


muddy_shoes(Posted 2012) [#105]
[edit 2] Ok after some more playing around and further investigation of the source, I'm starting to understand how the ray casting is done. Is there a reason why b2RayCastOutput doesn't store the point of intersection?


Well it does store information that describes the intersection point given that you must know the input ray. I'd guess that it's done that way to avoid performing calculations to get a result that you may not be interested in.


NoOdle(Posted 2012) [#106]
Well it does store information that describes the intersection point given that you must know the input ray. I'd guess that it's done that way to avoid performing calculations to get a result that you may not be interested in.


Yea I noticed that after I browsed the source some more. In the end I decided to use the RayCastAll and then loop all the fixtures and call another ray cast using them. I added a b2Vec2 to store the point of intersection and edited the raycast method in b2polygonshape to calculate this based on the input point.

Not the best because as you say because if I replace the module, the code won't work so I'll have to remember what I did.

Im having a great time playing around with this even if it is 6am! :D


Lugato(Posted 2012) [#107]
Muddy,

Itīs possible to attach a image in the object created with the CreateBody command ?


muddy_shoes(Posted 2012) [#108]
Sure. You can store a reference to whatever you like with the SetUserData method.


DruggedBunny(Posted 2012) [#109]
Continued here...