Messages

I think, maybe IsMotorEnabled is in a later version of Box2D.

No, it is in the b2RevoluteJoint.h file that we're using with the current wrapper.

Code (glbasic) Select Expand


class b2RevoluteJoint : public b2Joint
{
public:
/// Is the joint motor enabled?
bool IsMotorEnabled() const;
}


As I understand it, b2RevoluteJoint extends b2Joint, and I know how to reference b2Joint, but not the extended members

[class b2Joint]

Seems I'm the only one interested in box2d these days! Though hopefully this will catch the eye of someone who can answer my (hopefully very basic) C related question.

I've added motors and limit angles to joints in the GLBasic wrapper. Yay me. But being a complete non-programmer type, I can't get my head round returning references across classes. I was wondering if anyone here could give me a heads up (see below for specifics), cuz if I can solve this little issue I think I can add a heck of a lot more to the box2d wrapper functionality.

Ok. Here's the thing. I can reference a DIRECT definition of 'class b2Joint', such as the joint type, with a function such as the following:

Code (glbasic) Select Expand


FUNCTION b_JointGetType: joint%

INLINE
b2Joint* pB = bJoints(joint); return pB->GetType();
ENDINLINE

ENDFUNCTION


but what I need to know is how to reference a definition specific to 'class b2RevoluteJoint : public b2Joint', such as IsMotorEnabled() ?

I can't just express:

Code (glbasic) Select Expand

b2RevoluteJoint* pB = bJoints(joint);

because it tells me error: invalid conversion from `b2Joint*' to `b2RevoluteJoint*'.

I can't say:

Code (glbasic) Select Expand

b2Joint* pB = bJoints(joint); return pB->IsMotorEnabled();

because it tells me error: 'class b2Joint' has no member named 'IsMotorEnabled', and since I don't know anything about C, now I'm out of guesses and am stuck!

So if anyone could post the INLINE for the as yet non existent function b_JointIsMotorEnabled: joint% to show me how to correctly reference b2RevoluteJoint, I'm pretty sure that following this example there's a whole raft of extra functionality I could add to the box2d wrapper.

I realise there's potentially an issue with 'what if the joint isn't one with a motor?', but I'm not too worried about that right now, since I'm hoping to be able to write the function to use the above gettype(), then interrogate the correct class and return a value conditionally... all I'm really interested in right now is how to return b2RevoluteJoint->IsMotorEnabled in the first place!

Thanks!

I don't understand method 1... Wouldn't we have a doubled (retina) resolution but with doubled pixels (as currently the iPhone does)?

That's how I read it too, and it seems pointless even supporting the resolution if you're just going to pixel-double it. That's what happens right now automatically if you run a 320x480 project on a retina display. The point of supporting the resolution at all is surely for us to be able to take advantage of the higher resolution screen capability?

Why don't you just give us the resolution as a project option like any other and let us decide what to do with it, rather than try and implement some special case? It's pretty trivial to supply higher res graphics and scale them down if a lower res screen. Or to even use a different media directory depending on supported resolution.

Obviously yes, we would need a reliable way to detect the actual screen supported resolution.

edit: Oh wait. I see why you're trying to figure out a workaround type method... because SETSCREEN doesn't work on an iDevice. ONLY the project option makes any difference. So if we did a retina resolution project and it was actually a low res screen, you'd see the top left corner of the project. Right? Well, in that case, the only logical answer is that SETSCREEN really NEEDS to work to override project settings so that we can write a 'universal' version.

If you don't, then we would have the utterly ludicrous situation where you'd have to deploy an iPad version, an iPhone (Retina) version, and an iPhone (Standard) version. Frankly I don't even think Apple would let you.

But in that case, my point still stands... if we can't actually use and react to SETSCREEN... why bother supporting a retina device at all? It automatically pixel-doubles from 320x480. Which appears to be what you're proposing anyway.

Assuming that you can't get SETSCREEN to actually work, which would be by far the best situation all round, then your described method 2, 'fall back from Retina to standard', would be best, because at least we can take advantage of that higher resolution.

[what]

It's my pool example and you're not meant to follow me. Post sample code and we can work on that!

Really? Seems a bit pointless. I'd have to write code especially, which would ultimately be of no particular value to me or anyone else, when we could surely just talk in terms of the basic principle of how you would handle collisions between ANY two dynamic and currently moving objects without contact listeners, which would surely be more useful for anyone else who is interested in the future.

As I said, isSleeping wouldn't work where a pool ball has already been struck, has woken and is now moving, if it should then collide with another moving ball. Or if a character collides with a moving platform, or one race car that collides with another, etc etc, if you want to be strangely protective of your pool ball analogy. So interpreting what you said subsequent to that, I was merely asking if you were stating that, as a general principle, you would monitor each object each frame, and assume that any rapid deviation of speed or angle must have been caused by a collision? Or did you mean something else entirely that I haven't understood?

If you're saying that it depends what I want to do as to how it should be handled, and that's why you requested I post code, then I'd counter that this is precisely why it's pretty much essential that contact listeners are implemented for box2d to be of any use!.. they are the default, one-size-fits-all solution. And then we wouldn't have to be talking around all these less than perfect workarounds!

Hi Jaywat....
I don't know if Roll'n'Fall is anything 'serious' but if you like you can test it (today is free):
http://itunes.apple.com/us/app/rollnfall/id397681449?mt=8

Just downloaded. Very nice! Your accelerometer control feels just right. I tend to dislike accelerometer controlled games in general cuz they're always either way too sensitive and the tiniest unintentional movement screws up your control... or they're not sensitive enough and you have to turn the device nearly upside down to move!

I would like have more collision data but for now these are just short cuts. That is comparing objects to previous states. As far as pool ball collisions it possible to detect and compare shape velocities will reveal a moving collision.

I'm not sure I follow? Are you essentially saying, assuming our pool example, to check each ball each frame and decide that 'if I just significantly changed speed or direction, assume something else hit me'?

Replying to myself here :p

Ok, isSleeping is the same as any other flag interrogation. So the code to implement it is:

Code (glbasic) Select Expand


FUNCTION b_IsSleeping%: body%
INLINE
b2Body* pB = bBody(body); return pB->IsSleeping() ? TRUE:FALSE;
ENDINLINE
ENDFUNCTION


And yes, I can now see how I can use that if one of my objects is static. I can explicitly put an object to sleep, then check for it waking up, and play a sound or add a score or whatever accordingly, then put the object back to sleep. So certainly for dynamic->static collisions, that helps, thanks. Unfortunately, that doesn't help at all if you're trying to detect dynamic->dynamic collisions. So even in the case of pool balls... once you've woken the pool ball up by colliding with it, if another ball collides with the now moving ball, you couldn't detect that collision and play a sound.

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.

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.

[isSensor]

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


Oh ok. So the issue that ALL GLBasic apps crash on exit under iOS4 before executing GLB_ON_QUIT on a multitasking compatible device is solved, is it?

Gernot thinks he solved it quite a while ago, as per http://www.glbasic.com/forum/index.php?topic=4947.0

That thread relates to problems with the introduction of GLB_ON_PAUSE and GLB_ON_RESUME, as far as I can tell? Not really sure what the 'AUTOPAUSE' feature refers to. Nothing to do with the issue I posted about at length. If it is, it was way too subtle for me.

Kinda illustrates my point yet again. I've stated time and again that the introduction of these two functions DID NOT solve the original crash issue. They are two seperate issues: (a) fixing a bug that causes a crash on all multitasking devices, and (b) Adding capability to support multitasking.  If (a) WAS fixed, surely a ONE WORD post saying 'solved' in my bug report thread would have been the logical thing to do?

Rather than waiting to be told, you could maybe test it yourself once an update is posted,  and then perhaps inform others who are awaiting and answer.  Just a thought

Except I'm getting less and less inclined to use it for serious development, my problem with updating GLBasic is that it can often cause more problems than it fixes. So I'm extremely careful about whether I get the latest updates or not... especially when they come with an admission of no testing and Gernots own advice is to only use if you have to. "I had no real time to test all platforms, so please only update if you really experienced a bug. If others confirm it's OK, it might be safe. Sorry - but I'm really busy these days."

If I'd been aware of it being fixed, I'd have tested it and posted my findings. If you've ever read my bug reports, which you evidently haven't, you certainly can't accuse me of NOT thoroughly testing and writing up my findings. Thing is, no matter how detailed my writeup of symptoms or issues,  it's often painfully obvious from any responses that they're not even being read properly, so it feels like I'm wasting my time. Also, who are these "others who are awaiting and answer" that I have an obligation to? I wish I felt that ANYONE else here actually cared about any of the issues that are important to me. These people ought to perhaps speak up so it doesn't look like the issue is just affecting one person. Maybe it'll get looked into faster.

I'll refrain from commenting on the other part of your quote, as much as I'd like to state a few home truths.

multitasking is a feature of ios4 and crashes because no device for testing. no device -> no 100% bug fix. understand?

I think I understand, thank you, despite your somewhat mixed messages. You're saying that I can't realistically expect my apps not to crash on iOS4 and that Steve Jobs was completely correct about relying on 3rd party development platforms, yes? 

I know. I'm beginning to see that myself 

[ALL GLBasic apps crash on exit under iOS4]

the engine itself works fine in ios4 no problems with it.

Oh ok. So the issue that ALL GLBasic apps crash on exit under iOS4 before executing GLB_ON_QUIT on a multitasking compatible device is solved, is it? Because no one bothered to mention it in the bug thread. The last comment from a dev is August 26th saying "OK, I think I have a slight idea where the problem is now. I'll try to fix that soon. Next week at the latest.". And then nothing at all.

Which exactly illustrates makes my point about existing threads and issues, really.

If it is fixed, would have been kinda handy to know, since I've been waiting to update my broken apps since the launch of iOS4, while watching the bad reviews roll in and sales plummet.

I thought it was a perfectly valid question, especially since there ARE known issues with glbasic and IOS4. And I tend to find this community has a very short attention span when it comes to existing threads and issues, so it made sense to me to ask it in a new thread.

Any other questions we shouldn't ask? I wouldn't want to upset anyone...

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.

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!