Box2d - 2D physics

[blackway]

That's a very good news for everyone !!!!
I had no time to test because I was outside my country (I was in Brazil) for bussiness.
Now It's time to test !!!
Bye!

[Leos]

I loved this port!

Has anyone managed to export a dll wrapper of Box2D to be used separately ?

[jaywat]

For info, there is something wrong with the b_WorldDebug implementation in both the original box2d.gpas and the extended version. In the extended version, I cannot even compile a project with it.

In the other version, calling b_WorldDebug anywhere in your loop, before or after the b_Update tick, when an object has been deleted, causes an app crash.  Note, it doesnt even have to be in the same b_Update loop, so working round it by trying to make b_WorldDebug conditional on 'noDeletesThisLoop' doesn't work. There's probably a clue in the fact it still draws deleted objects long after they're deleted, even after multiple calls to b_Update. These deleted objects only seem to get replaced after I create completely new, seperately indexed objects, for some reason.

And I am being extremely, unbelievably careful about my deletes. I never delete more than one object in one b_Update call, and they're all done from stored indexes, and I never inadvertantly call a destroyed object.

Indeed, my code works perfectly, as long as I don't call b_WorldDebug. I assume it's somehow not taking into account deleted pointers and is calling them when it shouldnt.

I'm not a C coder, and don't have the knowledge to fix it. Hence this being for info, mainly for anyone else having huge frustrations with crashing when their code is actually perfectly fine!

[Kitty Hello]

post a small example that crashes, please.

[jaywat]

post a small example that crashes, please.

Well, I don't really have a 'small example'. I have my game code, which would obscure the issue, and I can't easily just hack out the bits that cause the issue into a coherent example without a lot of work. And like I said, my code works fine without a call to b_WorldDebug.

It was just a heads up, really, for anyone else who finds themselves with crashing code, especially if you're destroying objects... save yourself a lot of headaches and try removing the call to b_WorldDebug as a first step, because your code might be fine.

I'm not going to use GLBasic or Box 2D anyway for this project, because apparently crucial components of box2d such as collision listeners etc have not been implemented in the wrapper, and since sprcoll doesnt evaluate the object at a rotated angle, I can't use that for accurate collision detection. So I don't see that there is any way forward.

[jaywat]

I've posted an example below of a few edits I've made to my own box2d.gpas. After reading the Box2D manual and discovering there were a number of features and behaviours I wanted to make use of but weren't implemented in the wrapper, I had a play around. I'm sure it's all simple stuff to most, but I felt quite accomplished getting them to work, since I don't know anything at all about any flavour of C based languages. Hence coding in BASIC!

I figured I'd post the amendments I made in case they might be of use to others. I've supplied default behaviours, so they should work just fine with your existing code without complaining that you haven't supplied enough parameters and without changing the behaviour of your objects.

The extra parameters:

isSensor... A sensor is a shape that detects collision but does not produce a response. You can flag any shape as being a sensor. Sensors may be static or dynamic. Note it won't collide with anything at all! As the manual says, useful for when you need to know when two shapes overlap yet there should be no collision response.

fixedRotation... stops a physical body from being able to rotate. Can be a useful override for certain objects (say, moving platforms) since the default behaviour of box2d is that objects do rotate on collision etc.

groupIndex... You can have all shapes with the same group index ALWAYS collide by setting a POSITIVE group index, or NEVER collide by setting a NEGATIVE group index. Zero is default behaviour. Very useful, because it allows you to override the default collisions of Box2D while still being able to get and set any of Box2D's physical properties for objects. Using 'isSensor' doesn't cut it for this, because then the object wont collide with anything at all, including groundboxes.  I noticed this line was in box2d-extended but commented out. I've personally not found any issues with it.

Incidentally, personally speaking, I've found that ground boxes dont seem to have as good collision detection as actual boxes. I really dont know why, but my objects at even reasonably low velocities will embed themselves into the ground boxes and be unable to move again, even if I use setBullet for supposedly enhanced collision handling. So I now use a static 'ordinary' box (any object is static as long as it has a mass of 0.0) with a positive group index instead of ground boxes, which seems to have eliminated that problem entirely.

Code (glbasic) Select Expand


FUNCTION b_CreateBox: mass, friction, restitution, lineardamp,angulardamping, x, y, w, h, isSensor = FALSE, fixedRotation = FALSE, groupIndex = 0
   INLINE
   b2BodyDef def;
   def.position.Set(x,y);
   def.linearDamping = lineardamp;
   def.angularDamping = angulardamping;
   def.fixedRotation = fixedRotation;         // you would need to add this to other shape functions you want to do the same with
   b2Body* pBody = bWorld->CreateBody( &def );
   b2PolygonDef poly;
      if(mass>0.0) poly.density = mass;
      poly.filter.groupIndex = groupIndex;   // and add this!
      poly.friction = friction;
      poly.restitution = restitution;
      poly.isSensor = isSensor;              // and add this!
      poly.SetAsBox(w*.5, h*.5);
      pBody->CreateShape( &poly);
      if(mass>0.0) pBody->SetMassFromShapes();
   return b_NewObject(pBody, bBody);
   ENDINLINE
ENDFUNCTION


[matchy]

Well done! I've already started doing that where linear and angular damping is very much required. 
http://www.glbasic.com/forum/index.php?topic=3561.msg35761#msg35761

Lately I've been using group index and lower and upper angular joint limits for collision  although I couldn't get MaxMotorTorque or MotorSpeed with this version  .

[Wampus]

Thanks to everyone who has been working and sharing with Box2D to get it working with GLBasic. My GF gave me an idea for a game that truly needs 2D physics so I'll be needing to use Box 2D some time soon.

[matchy]

My GF gave me an idea for a game that truly needs 2D physics so I'll be needing to use Box 2D some time soon.

The idea needs 2D physics so you need Box 2D because you GF's concept. Thanks for sharing that vital information. 

[Wampus]

No problem. Incidentally, I've added you, Matchy, to an email newsletter and Facebook group so you find out first what's happening in the world of my GF having an idea for a game which needs a 2D engine like Box2D. There is also a website and multimedia promotional advertising to come soon – just so everyone knows that my GF had an idea for a game which needs a 2D engine like Box2D. They'll make a major movie about this one day. For now I just have to deal with the crowds of journalists asking me questions about it whenever I try to leave the house.

[matchy]

Incidentally, I've added you, Matchy, to an email newsletter and Facebook group...

Um, how?

[pinete]

Hi all,
I'm just download some rars posted on this thread but I'm pretty sure they're not updated, as far as I guess, maybe I'm wrong..
Could someone help me sharing a 'complete package'? I mean, a thing that I can deal with it from the very beginning without problems? or at least posting a link to it (or links)
Thanks a lot in advance!!

[jaywat]

I'm just curious to know if anyone is actually using box2d with GLBasic for anything 'serious'? Somehow I assume not.

Thing is, this box2d wrapper is all very nice and all for just fooling around with, but unless I'm very much missing the point, it's really of no practical use at all without the implementation of box2d contact listeners.

Sure, it physically HANDLES your object-object collisions, but without contact listeners, you can't get any feedback on those collisions. So how, for example, can you play a sound effect or animation? or add to a game score? or know when to destroy an object that was collided with? You can't do any of the normal things you'd expect to have in a game related to collision if you can't detect that a collision happened!

I've tried implementing glbasic sprite collisions, first of all with exact size sprites, but unless the collision just happens to exactly fall on the exact millisecond that your next frame update and collision check happens, it of course never sees that collision. (To be clear, I'm talking about a collision where the two objects will react to each other, ie, bounce off. The kind where contact happens for a fraction of a second. Detecting collisions where one object passes through another sensor object is obviously less of an issue).

I've tried using sprite collisions with a slightly larger sprite as a collision boundary in the hope of having more chance of catching the actual collision. Still unsatisfactory. Still misses at least 25% of collisions because they still don't exactly happen on the frame update you're testing - you're either just about to collide, or just finished colliding. Obviously the accuracy gets less and less the faster your object is moving.

Which is exactly why you need to get realtime feedback from box2d itself... direct feedback from the physics simulation is the only sure fire way of being sure to catch every collision so that you can act on them.

So if you ARE successfully using box2d in a glbasic game or whatever, perhaps you'd share how you're getting round this major problem? I don't even need code, really, if you can clearly describe your method.

I'm assuming it's no trivial matter to implement the contact listeners, or someone would have done it by now, because it must surely be one of the most necessary features of any physics engine. In fact, I simply can't see the point at all of using a physics engine you can't get any useful feedback from.

[matchy]

It would just be a matter of porting the contact listener functions over.

For still and moving shapes that collide and play a sound (pool balls), a current simple method is to check for IsSleeping(). Also check for bounce speed and direction change amount to determine the type of response/sound effect. These are really the only way to get collision data from inside the current box2d glb lib. Sometimes it can depend on what is really needed and in this case it doesn't check for walls with zero mass.

[jaywat]

It would just be a matter of porting the contact listener functions over.

If it's 'just be a matter of porting the contact listener functions', can someone who knows how do it, please? I wouldn't have the first clue how. I just assumed it wasn't a simple task since it hasn't been done in the wrapper, and as I said, surely it's one of the most essential functions of a physics implementation?

a current simple method is to check for IsSleeping()

None of the box2d implementations I've gotten from this thread have a way of interrogating if an object is sleeping? You have allowsleeping and puttosleep... but as far as I can tell, no way of asking if it IS asleep.