Because I am just drawing one or two bodies and sprites to see how things work, so far there are no problems with that method.

But then I accidentally found out about body.setUserData(Object) method. Wondering if this has any advantages or deals with something I have not encountered or thought about, I went to libgdx documentation and found this (at https://code.google.com/p/libgdx/wiki/PhysicsBox2D):

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Iterator<Body> bi = world.getBodies();

while (bi.hasNext()){Bodyb = bi.next();

// Get the bodies user data - in this example, our user // data is an instance of the Entity classEntitye = (Entity) b.getUserData();

if (e != null) {// Update the entities/sprites position and anglee.setPosition(b.getPosition().x, b.getPosition().y);// We need to convert our angle from radians to degreese.setRotation(MathUtils.radiansToDegrees * b.getAngle()); }}

So if I have only one body and not an array of bodies and sprites, it will be like this:

1 2 3 4

body.setUserData(mySprite);

(whenrendering)(Sprite)body.getUserData().setPosition(values);

Right? Because I don't have many bodies and certainly I don't need an iterator.

So, is this method only useful with many bodies? Or is it my method wrong or inefficient?

The other question is, I have my sprite in one class and body in another class (Actually I have a static method which creates a body wherever I want etc). These two do not know about each other. That is to say, no references, no parameters about each other. Should I write them like this:

You have an Entity class, which holds reference to a Body and a reference to Sprite

your game loop should go in this order

1 2 3 4 5 6 7

box2d.update(whatever)

for(Entityent :entities) {ent.update(); // entity logic like AI, inputs, etc. At the end it updates Sprite position to match a Body position}

//render sprites

Sprites should be held in different structure, optimal for rendering.

Body's UserData should hold reference to its Entity - not to loop through bodies. It's useful for collision detection. Box2D lets you add listeners and filters to your world... so you can detect when your bullet collides with a player, etc. your listeners would receive to Bodies. you can identify them by their UserData

I am sorry, I can't understand. What should the entity class look like?You say Entity class should hold reference to body and sprite. And you say Body's userdata should hold reference to its entity. That sounded confusing to me. It might be because English is not my native language, but I just didn't understand.

Usually it's used for storing the java side object representing the Entity. When a collision happens, the Entity should be notified. But upon collision, you only get the Box2D Body, so you have to save user data (the entity to call the #collide(Entity) method)

Usually it's used for storing the java side object representing the Entity. When a collision happens, the Entity should be notified. But upon collision, you only get the Box2D Body, so you have to save user data (the entity to call the #collide(Entity) method)

Hm... I don't quite understand.

Sorry if I'm sounding a bit slow, but... why should the Entity be notified? (I'm still not sure I also understand what is being referred to as the Entity... is it synonymous to Object?)

Usually in games the Entity class represents anything in the game world, be it a weapon or enemy. The Entity should be connected to the box2D body because otherwise it's hard to process what body hit what other body.

Sorry, I'm probably not explaining myself right... I'm coming from the perspective of "But wait... I'm handling collisions without the use of userData... does that mean I'm doing it wrong?"

How I do it is for example I have a class called MyCoin that represents a coin in the game, and it contains a Box2D Body. Now, during gameplay, I want the coin to disappear when the player comes into contact/collides with it (meaning the player has picked it up). What I do now is that I have all the coins stored in a Vector called coins; and upon collision, I loop through that Vector to check:

(1) Is one of the fixtures the player body?AND(2) Is the other fixture a coin?

At which point, if both are true, I do all the stuff that should happen (e.g. money increases) and then queue the coin for destruction after the world step. So, like this:

It occurred to me as I was implementing this that having to loop through collections of certain objects repeatedly upon collision is probably not the best way to do things from a performance standpoint. Also, I wanted specific objects of the same class to have significantly different behavior, it would probably be a pain to handle.

But I couldn't think of another way to do it. Now, if userData will help me achieve this, I'm all ears Please help. TIA!

Great conversation took place here while my connection was broken Thanks guys.

So, let me wrap things up and see if there is something wrong in what I understood;- I should do the logic part with box2d (obviously, it is the physics part), and rendering part with an entity class (So, MyShip class is an entity class?) assuming that I want to separate logic and render (which is the efficient thing to do). - UserData is there to make collision detection easier? If I link my entity to a body using user data, I can determine which entity hit which one easier (like if(body.getUserData == myEntity) {//do stuff}

Quote from: matheus23

Usually it's used for storing the java side object representing the Entity. When a collision happens, the Entity should be notified. But upon collision, you only get the Box2D Body, so you have to save user data (the entity to call the #collide(Entity) method)

- A Body userdata could (or should?) be an entity.- What we call entity is nothing more than our objects in the game. Like, the character, the enemy, the bullets, and weapons?

- Basicly, there is nothing wrong with my method, but I still can (or should?) link the body and entity using UserData, and updating the entities using my method or the method in the libgdx page is up to me. And if I use UserData, I also have an advantage like this:

Sorry, I'm probably not explaining myself right... I'm coming from the perspective of "But wait... I'm handling collisions without the use of userData... does that mean I'm doing it wrong?"

How I do it is for example I have a class called MyCoin that represents a coin in the game, and it contains a Box2D Body. Now, during gameplay, I want the coin to disappear when the player comes into contact/collides with it (meaning the player has picked it up). What I do now is that I have all the coins stored in a Vector called coins; and upon collision, I loop through that Vector to check:

(1) Is one of the fixtures the player body?AND(2) Is the other fixture a coin?

At which point, if both are true, I do all the stuff that should happen (e.g. money increases) and then queue the coin for destruction after the world step. So, like this:

It occurred to me as I was implementing this that having to loop through collections of certain objects repeatedly upon collision is probably not the best way to do things from a performance standpoint. Also, I wanted specific objects of the same class to have significantly different behavior, it would probably be a pain to handle.

But I couldn't think of another way to do it. Now, if userData will help me achieve this, I'm all ears Please help. TIA!

Adding to this... if I do the following inside the MyCoin class:

1

body.setUserData(this); // to store this MyCoin instance inside the body

How can I use getUserData() inside the collision listener to determine that the body is linked to a MyCoin instance? Meaning... how do I complete this if-statement?

1 2 3 4

if ((fixtureA.getBody().getUserData.equals(/*what can I put here to determine that this is MyCoin?*/) && fixtureB.getBody().equals(/*what can I put here to determine that this is MyPlayer?*/)) || (fixtureB.getBody().getUserData.equals(/*what can I put here to determine that this is MyCoin?*/) && fixtureA.getBody().equals(/*what can I put here to determine that this is MyPlayer?*/))) {// do everything related to the coin getting picked up}

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org