Monkey Box2D Port
Monkey Forums/User Modules/Monkey Box2D Port
| ||
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/ |
| ||
The slowdown is fixed. |
| ||
That's awesome dude! No need for chipmunk anymore I guess. |
| ||
good demos, good job sir |
| ||
Excellent work so far! Yea notice there's a few collision problems so far - speed is good tho |
| ||
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. |
| ||
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/ |
| ||
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. |
| ||
@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. |
| ||
im not an expert but have you tried experimenting with update rates to solve the collision issues? |
| ||
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. |
| ||
ok, did you try to contact any authors of ports? maybe they had similar problems |
| ||
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. |
| ||
Great work! Can you possibly post some sample monkey code for one of the examples? |
| ||
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 |
| ||
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. |
| ||
Excellent news - well done |
| ||
And it's released: http://code.google.com/p/monkeybox2d/ |
| ||
Congrats! Im guessing you used JungleIDE when you developed this ;) How do you run the demos? |
| ||
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 |
| ||
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! |
| ||
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. |
| ||
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 ;) |
| ||
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. |
| ||
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 |
| ||
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 |
| ||
Just looked at the examples, well done muddy shoes :) |
| ||
Love the examples :) |
| ||
I can't get it. The link for the source (hg repo) gives a 404. Heeellllpp! ME WANT!!! :) |
| ||
@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. |
| ||
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...) :) |
| ||
Ah, I messed up the command and removed a space. The repo is at https://monkeybox2d.googlecode.com/hg/ |
| ||
Well done muddy shoes shall have a good play with this later |
| ||
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! |
| ||
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! :) |
| ||
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. |
| ||
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. |
| ||
Just great, thank you! |
| ||
Looking great muddy! Thank you! |
| ||
Brilliant work, thanks. |
| ||
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. |
| ||
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? |
| ||
@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. |
| ||
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. |
| ||
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. |
| ||
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! |
| ||
@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. |
| ||
my bad |
| ||
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. |
| ||
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. |
| ||
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 |
| ||
How do we attach physics to objects in our scene? Is this covered in the repository somewhere? by example maybe? |
| ||
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. |
| ||
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! |
| ||
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. |
| ||
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? |
| ||
radians are a bit harsh for people like me who dont even know what they are, |
| ||
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. |
| ||
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. |
| ||
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! |
| ||
@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. |
| ||
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. |
| ||
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 |
| ||
@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. |
| ||
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 ![]() |
| ||
Here's a fun challenge: remove the top three bricks without the pyramid collapsing. It's more difficult than you think! :)![]() |
| ||
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. |
| ||
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? |
| ||
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 |
| ||
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. |
| ||
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. :-) |
| ||
Thanks, that provides some confirmation of my own tests. Which browser are you using? Safari? |
| ||
Firefox 5.0 |
| ||
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) |
| ||
Cheers, Ovine. It seems fairly conclusive that the test variant produces visually better performance under stress. |
| ||
@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. |
| ||
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. |
| ||
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. |
| ||
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 :-) |
| ||
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. |
| ||
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 |
| ||
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. |
| ||
Thanks! |
| ||
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 ? :) |
| ||
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. |
| ||
many thanks :) |
| ||
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 |
| ||
That is most likely the debug outline graphics, once you turn that off and hook up your own image based rendering the module flies. |
| ||
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. |
| ||
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. |
| ||
There is a bug in b2gravitycontroller.monkey. Will not compile "Constants.F_MIN" must be replaced two times with "Constants.FMIN". |
| ||
Is it just me or does the zip for v1.07 contain a corrupted maindemo.monkey file? |
| ||
I wasn't able to run the v1.07 with the last monkey (v50) too... |
| ||
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. |
| ||
... 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 |
| ||
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 |
| ||
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. |
| ||
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 |
| ||
Interesting read, I am happy with the performance so far, but I have not really stressed it, still cross platform is great with Monkey. |
| ||
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 ! |
| ||
Sorry, I'm not a BlitzMax user so I can't offer any help. |
| ||
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. |
| ||
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 ) |
| ||
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. |
| ||
[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. |
| ||
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 |
| ||
Muddy, Itīs possible to attach a image in the object created with the CreateBody command ? |
| ||
Sure. You can store a reference to whatever you like with the SetUserData method. |
| ||
Continued here... |