# Search the Community

Showing results for tags 'Box2D'.

The search index is currently processing. Current results may not be complete.
• ### Search By Tags

Type tags separated by commas.

### Categories

• Audio
• Music and Sound FX
• Career Development
• Production and Management
• Game Design
• Game Design and Theory
• Writing for Games
• UX for Games
• Industry
• Interviews
• Event Coverage
• Programming
• Artificial Intelligence
• General and Gameplay Programming
• Graphics and GPU Programming
• Engines and Middleware
• Math and Physics
• Networking and Multiplayer
• Visual Arts
• Archive

• Audio
• Visual Arts
• Programming
• Writing

### Categories

• GameDev Unboxed

### Categories

• Game Developers Conference
• GDC 2017
• GDC 2018
• Power-Up Digital Games Conference
• PDGC I: Words of Wisdom
• PDGC II: The Devs Strike Back
• PDGC III: Syntax Error

### Forums

• Audio
• Music and Sound FX
• Games Career Development
• Production and Management
• Game Design
• Game Design and Theory
• Writing for Games
• Programming
• Artificial Intelligence
• Engines and Middleware
• General and Gameplay Programming
• Graphics and GPU Programming
• Math and Physics
• Networking and Multiplayer
• Visual Arts
• 2D and 3D Art
• Critique and Feedback
• Community
• GameDev Challenges
• GDNet+ Member Forum
• GDNet Lounge
• GDNet Comments, Suggestions, and Ideas
• Coding Horrors
• Hobby Project Classifieds
• Indie Showcase
• Article Writing
• Affiliates
• NeHe Productions
• AngelCode
• Topical
• Virtual and Augmented Reality
• News
• Workshops
• C# Workshop
• CPP Workshop
• Freehand Drawing Workshop
• Hands-On Interactive Game Development
• SICP Workshop
• XNA 4.0 Workshop
• Archive
• Topical
• Affiliates
• Contests
• Technical
• GameDev Challenges's Topics
• For Beginners's Forum

### Calendars

• Community Calendar
• Games Industry Events
• Game Jams
• GameDev Challenges's Schedule

• GDNet+
• GameDev Gear

• 0 Replies

• 0 Reviews

• 0 Views

Found 16 results

1. ## C++ Simple trig problem driving me crazy

Hello folks, I am fighting with a really simple problem that has been driving me nuts. I'm usually fairly confident with trigonometry and I'm pretty sure the issue here is not the math but in some behavior behind the scenes. A bit of background - basically I'm developing my own little 2D game engine using C++, in my free-time for fun. I work with game technology and simulation products IRL so for the most part this has been plain sailing. I am using Box2D for physics, and SFML for rendering. My game at current has a few space ships flying around via keyboard and AI input. These space ships need exhausts! So I'm currently in the process of getting a 'component' system in place, however my problem is that the animated exhaust sprites are not going where I want them to. When the base GameObject class runs it's update method, it does the following: Queries the physics object for a position Converts the physics position to a pixel position (x10 scale factor) Moves the sprite to the new position Passes new position to all 'component' objects into their 'UpdateComponent' method Components move their sprite to the correct position However the exhaust sprites seem to wander around all over the place, in no way representing where I actually want them to be! This should have been a simple case of: newPosition = (sin(rotationRadians) * offsetX, cos(rotationRadians) * offsetY) + oldPosition Here is the current code: void Exhaust::UpdateComponent(const Vec2f & position, float rotationDegrees, float deltaTime) { float angleRad = DEGREES_TO_RADIANS(rotationDegrees); float offsetX = sin(angleRad) * mOffset.x; float offsetY = cos(angleRad) * mOffset.y; sf::Vector2f newPos(position.x + offsetX, position.y + offsetY); mSprite->SetRotation(rotationDegrees); mSprite->SetPosition(newPos); mSprite->Update(deltaTime); #ifdef _DEBUG sf::Vector2f p(position.x, position.y); stringstream ss; ss << rotationDegrees; DebugUtils::DrawCross(p, 8, sf::Color::Green, ss.str()); DebugUtils::DrawCross(newPos, 8, sf::Color::Green); DebugUtils::DrawLine(p, newPos, sf::Color::Green); cout << rotationDegrees << endl; DebugUtils::DrawSpriteOutline(*mSprite->GetGraphic(), sf::Color::Green); #endif // _DEBUG } And here is a gif of it all going wrong! (link below) Gif of game engine problem Any help would be much appreciated, even if it is just a thought of where the problem might be originating from! Thanks!

3. ## Mobile How to check if Bike doing backflip/ frontflip?

I'm using construct 2 physics I have a working bike with everything setup and I'm able to do frontflip and backflip by adding angular velocity to the bike I want to increase score/ add points and display the "backflip / frontflip" text when the bike does it. so please help me I want to know the logic and how it's done. p.s. example about construct 2 is not necessary, just explain me how other games do it or anything else you have to share Thanks, Drago
4. ## Working on the AI, a coreographic fight.

This week was full work on the AI, which was lacking a bit, to say the least. It is a simple state machine that changes based on the distance to the character (far? jump, close? punch/kick) and its own physical state (falling? stucked? idling? close to edge?). Eventually I managed to make sequence I'm quite proud of: Several silly situations came out of it before I reached that stage: The AI trying hard to punch, only to fall to their death. Finally! It manages to punch me. It's not really hard to terminate the threat. Sometimes it even terminates itself... is the most convoluted way. When your fighting your bro, and a brofist is mandatory. The AI is not prepared to fight flying robots. Ok, that was a decent punch. So it does not get too cocky. If you are interested in Posable Heroes, you can wishlist it on steam.

8. ## A new hud

Lately I've been working on updating the hud. The game is quite colorful (once you press play) so I thought adding a cardboard only hud to make the distinction. Use to look like this: Now it looks like this: Top left is supposed to be the briefing about the current level. Working on localizing those texts. More about posable heroes: Steam Store Page
9. ## [Android] JumpBall

Hello everyone. My new game Name: JumpBall Genre: clicker Engine: cocso2d-x + Box2D Language: C++ Complete: 100% [Release] [Android] Description: Tap to screen for pushed ball. At each mark it is necessary to be ahead of the balloon, which is constantly accelerated. When pushing the ball you need to give the maximum possible acceleration if you make a mistake then the ball will slow down very much. Video Each time generate new terrain
10. ## Understanding Constraint Resolution in Physics Engine

Original Post: Limitless Curiosity Out of various phases of the physics engine. Constraint Resolution was the hardest for me to understand personally. I need to read a lot of different papers and articles to fully understand how constraint resolution works. So I decided to write this article to help me understand it more easily in the future if, for example, I forget how this works. This article will tackle this problem by giving an example then make a general formula out of it. So let us delve into a pretty common scenario when two of our rigid bodies collide and penetrate each other as depicted below. From the scenario above we can formulate: We don't want our rigid bodies to intersect each other, thus we construct a constraint where the penetration depth must be more than zero. $$C: d>=0$$ This is an inequality constraint, we can transform it to a more simple equality constraint by only solving it if two bodies are penetrating each other. If two rigid bodies don't collide with each other, we don't need any constraint resolution. So: if d>=0, do nothing else if d < 0 solve C: d = 0 Now we can solve this equation by calculating $$\Delta \vec{p1},\Delta \vec{p2},\Delta \vec{r1}$$,and $$\Delta \vec{r2}$$ that cause the constraint above satisfied. This method is called the position-based method. This will satisfy the above constraint immediately in the current frame and might cause a jittery effect. A much more modern and preferable method that is used in Box2d, Chipmunk, Bullet and my physics engine is called the impulse-based method. In this method, we derive a velocity constraint equation from the position constraint equation above. We are working in 2D so angular velocity and the cross result of two vectors are scalars. Next, we need to find $$\Delta V$$ or impulse to satisfy the velocity constraint. This $$\Delta V$$ is caused by a force. We call this force 'constraint force'. Constraint force only exerts a force on the direction of illegal movement in our case the penetration normal. We don't want this force to do any work, contribute or restrict any motion of legal direction. $$\lambda$$ is a scalar, called Lagrangian multiplier. To understand why constraint force working on $$J^{T}$$ direction (remember J is a 12 by 1 matrix, so $$J^{T}$$ is a 1 by 12 matrix or a 12-dimensional vector), try to remember the equation for a three-dimensional plane. Now we can draw similarity between equation(1) and equation(2), where $$\vec{n}^{T}$$ is similar to J and $$\vec{v}$$ is similar to V. So we can interpret equation(1) as a 12 dimensional plane, we can conclude that $$J^{T}$$ as the normal of this plane. If a point is outside a plane, the shortest distance from this point to the surface is the normal direction. After we calculate the Lagrangian multiplier, we have a way to get back the impulse from equation(3). Then, we can apply this impulse to each rigid body. Baumgarte Stabilization Note that solving the velocity constraint doesn't mean that we satisfy the position constraint. When we solve the velocity constraint, there is already a violation in the position constraint. We call this violation position drift. What we achieve is stopping the two bodies from penetrating deeper (The penetration depth will stop growing). It might be fine for a slow-moving object as the position drift is not noticeable, but it will be a problem as the object moving faster. The animation below demonstrates what happens when we solve the velocity constraint. [caption id="attachment_38" align="alignnone" width="800"] So instead of purely solving the velocity constraint, we add a bias term to fix any violation that happens in position constraint. So what is the value of the bias? As mentioned before we need this bias to fix positional drift. So we want this bias to be in proportion to penetration depth. This method is called Baumgarte Stabilization and $$\beta$$ is a baumgarte term. The right value for this term might differ for different scenarios. We need to tweak this value between 0 and 1 to find the right value that makes our simulation stable. Sequential Impulse If our world consists only of two rigid bodies and one contact constraint. Then the above method will work decently. But in most games, there are more than two rigid bodies. One body can collide and penetrate with two or more bodies. We need to satisfy all the contact constraint simultaneously. For a real-time application, solving all these constraints simultaneously is not feasible. Erin Catto proposes a practical solution, called sequential impulse. The idea here is similar to Project Gauss-Seidel. We calculate $$\lambda$$ and $$\Delta V$$ for each constraint one by one, from constraint one to constraint n(n = number of constraint). After we finish iterating through the constraints and calculate $$\Delta V$$, we repeat the process from constraint one to constraint n until the specified number of iteration. This algorithm will converge to the actual solution.The more we repeat the process, the more accurate the result will be. In Box2d, Erin Catto set ten as the default for the number of iteration. Another thing to notice is that while we satisfy one constraint we might unintentionally satisfy another constraint. Say for example that we have two different contact constraint on the same rigid body. When we solve $$\dot{C1}$$, we might incidentally make $$\dot{d2} >= 0$$. Remember that equation(5), is a formula for $$\dot{C}: \dot{d} = 0$$ not $$\dot{C}: \dot{d} >= 0$$. So we don't need to apply it to $$\dot{C2}$$ anymore. We can detect this by looking at the sign of $$\lambda$$. If the sign of $$\lambda$$ is negative, that means the constraint is already satisfied. If we use this negative lambda as an impulse, it means we pull it closer instead of pushing it apart. It is fine for individual $$\lambda$$ to be negative. But, we need to make sure the accumulation of $$\lambda$$ is not negative. In each iteration, we add the current lambda to normalImpulseSum. Then we clamp the normalImpulseSum between 0 and positive infinity. The actual Lagrangian multiplier that we will use to calculate the impulse is the difference between the new normalImpulseSum and the previous normalImpulseSum Restitution Okay, now we have successfully resolve contact penetration in our physics engine. But what about simulating objects that bounce when a collision happens. The property to bounce when a collision happens is called restitution. The coefficient of restitution denoted $$C_{r}$$, is the ratio of the parting speed after the collision and the closing speed before the collision. The coefficient of restitution only affects the velocity along the normal direction. So we need to do the dot operation with the normal vector. Notice that in this specific case the $$V_{initial}$$ is similar to JV. If we look back at our constraint above, we set $$\dot{d}$$ to zero because we assume that the object does not bounce back($$C_{r}=0$$).So, if $$C_{r} != 0$$, instead of 0, we can modify our constraint so the desired velocity is $$V_{final}$$. We can merge our old bias term with the restitution term to get a new bias value. // init constraint // Calculate J(M^-1)(J^T). This term is constant so we can calculate this first for (int i = 0; i < constraint->numContactPoint; i++) { ftContactPointConstraint *pointConstraint = &constraint->pointConstraint; pointConstraint->r1 = manifold->contactPoints.r1 - (bodyA->transform.center + bodyA->centerOfMass); pointConstraint->r2 = manifold->contactPoints.r2 - (bodyB->transform.center + bodyB->centerOfMass); real kNormal = bodyA->inverseMass + bodyB->inverseMass; // Calculate r X normal real rnA = pointConstraint->r1.cross(constraint->normal); real rnB = pointConstraint->r2.cross(constraint->normal); // Calculate J(M^-1)(J^T). kNormal += (bodyA->inverseMoment * rnA * rnA + bodyB->inverseMoment * rnB * rnB); // Save inverse of J(M^-1)(J^T). pointConstraint->normalMass = 1 / kNormal; pointConstraint->positionBias = m_option.baumgarteCoef * manifold->penetrationDepth; ftVector2 vA = bodyA->velocity; ftVector2 vB = bodyB->velocity; real wA = bodyA->angularVelocity; real wB = bodyB->angularVelocity; ftVector2 dv = (vB + pointConstraint->r2.invCross(wB) - vA - pointConstraint->r1.invCross(wA)); //Calculate JV real jnV = dv.dot(constraint->normal pointConstraint->restitutionBias = -restitution * (jnV + m_option.restitutionSlop); } // solve constraint while (numIteration > 0) { for (int i = 0; i < m_constraintGroup.nConstraint; ++i) { ftContactConstraint *constraint = &(m_constraintGroup.constraints); int32 bodyIDA = constraint->bodyIDA; int32 bodyIDB = constraint->bodyIDB; ftVector2 normal = constraint->normal; ftVector2 tangent = normal.tangent(); for (int j = 0; j < constraint->numContactPoint; ++j) { ftContactPointConstraint *pointConstraint = &(constraint->pointConstraint[j]); ftVector2 vA = m_constraintGroup.velocities[bodyIDA]; ftVector2 vB = m_constraintGroup.velocities[bodyIDB]; real wA = m_constraintGroup.angularVelocities[bodyIDA]; real wB = m_constraintGroup.angularVelocities[bodyIDB]; //Calculate JV. (jnV = JV, dv = derivative of d, JV = derivative(d) dot normal)) ftVector2 dv = (vB + pointConstraint->r2.invCross(wB) - vA - pointConstraint->r1.invCross(wA)); real jnV = dv.dot(normal); //Calculate Lambda ( lambda real nLambda = (-jnV + pointConstraint->positionBias / dt + pointConstraint->restitutionBias) * pointConstraint->normalMass; // Add lambda to normalImpulse and clamp real oldAccumI = pointConstraint->nIAcc; pointConstraint->nIAcc += nLambda; if (pointConstraint->nIAcc < 0) { pointConstraint->nIAcc = 0; } // Find real lambda real I = pointConstraint->nIAcc - oldAccumI; // Calculate linear impulse ftVector2 nLinearI = normal * I; // Calculate angular impulse real rnA = pointConstraint->r1.cross(normal); real rnB = pointConstraint->r2.cross(normal); real nAngularIA = rnA * I; real nAngularIB = rnB * I; // Apply linear impulse m_constraintGroup.velocities[bodyIDA] -= constraint->invMassA * nLinearI; m_constraintGroup.velocities[bodyIDB] += constraint->invMassB * nLinearI; // Apply angular impulse m_constraintGroup.angularVelocities[bodyIDA] -= constraint->invMomentA * nAngularIA; m_constraintGroup.angularVelocities[bodyIDB] += constraint->invMomentB * nAngularIB; } } --numIteration; } General Step to Solve Constraint In this article, we have learned how to solve contact penetration by defining it as a constraint and solve it. But this framework is not only used to solve contact penetration. We can do many more cool things with constraints like for example implementing hinge joint, pulley, spring, etc. So this is the step-by-step of constraint resolution: Define the constraint in the form $$\dot{C}: JV + b = 0$$. V is always $$\begin{bmatrix} \vec{v1} \\ w1 \\ \vec{v2} \\ w2\end{bmatrix}$$ for every constraint. So we need to find J or the Jacobian Matrix for that specific constraint. Decide the number of iteration for the sequential impulse. Next find the Lagrangian multiplier by inserting velocity, mass, and the Jacobian Matrix into this equation: Do step 3 for each constraint, and repeat the process as much as the number of iteration. Clamp the Lagrangian multiplier if needed. This marks the end of this article. Feel free to ask if something is still unclear. And please inform me if there are inaccuracies in my article. Thank you for reading. NB: Box2d use sequential impulse, but does not use baumgarte stabilization anymore. It uses full NGS to resolve the position drift. Chipmunk still use baumgarte stabilization. References Allen Chou's post on Constraint Resolution A Unified Framework for Rigid Body Dynamics An Introduction to Physically Based Modeling: Constrained Dynamics Erin Catto's Box2d and presentation on constraint resolution Falton Debug Visualizer 18_01_2018 22_40_12.mp4 equation.svg
11. ## Replicating a simulation with Box2d, part 2.

So, in the previous post I said the main problem about duplicating a box2d world. The worlds differ. Why would you want to duplicate a box2d world? There are several reasons: To replay a cool sequence. To predict the future. To go back in time. To save the current game. To send the current world to another player. How do you solve this? There is a very simple way of going around the box2d issue. Instead of trying to make a copy of the original world, and hope for the best, you make two copies, and then destroy the original. So instead of running the original world and save the copy... You make two copies, run one and save the second one. That way, the second copy will be identical to the first one. So the solution is: everytime you want to save the current world, you are actually destroying it and making two copies. The players will continue to play on copy number #1 (they will not realise the change) and you store copy number 2, in case you ever need to get back to that instant. This is a very simple solution that can be applied to almost every case. My game turned out to be one of those special cases that required dipping into the source code. I'll talk about it in the next post. If you want to know more about my game and why I had to dance around box2d cloning issues: Posable Heroes now has a steam store page.
12. ## Choosing Flowfield Methods

I need some help determining which methods of path finding i should use. The scenario is that i want 100-1000 agents (with steering behaviors) moving to a single location (the player) via a flow field. I am currently following this PDF for guidance (Supreme Commander 2 Pathfinding) but a lot of the technologies they use are meant for an RTS. Different groups of agents often have different goals to move toward to. Since i have a single, consistent goal, would i still implement things like an A* search through sectors based on an agent's location in the map (there's a lot of agents so..), or would i simply generate the flow fields in the sectors that are occupied? Basically, since i have a single target at all times, which technologies should i use and which should i forget about
13. ## Proof of Concept

Greetings everyone! I finally managed to put together complete system that will be used as a backbone of my new game. The game itself is supposed to be a mix of Kerbal Space Program and Space Engineers in 2d, maybe with some added influences from other games. I'll get back to this later, when gameplay is more fleshed out. Right now what the game needs is: orbital physics of planetary system, large deformable terrains with rigid body simulation and transitions between those two. tl;dr; There is a video. Orbital physics This part was relatively easy. I choose simulated n-body system over fixed orbits with patched conic approximation. It's simple to write and supports all phenomena like Lagrange points. My system uses Verlet integration with fixed time step (64s) for planets and adaptive time step for small entities (artificial satellites, asteroids). The only drawback here is that plotting trajectories requires to know positions of all planets ahead of time, so it's best to evaluate whole system many steps to the future and just playback current position from history. (You can see these in video when debug drawing is enabled) Planetary physics I modeled planet's surface as linear space located around planet radius, with wrapping around when traveling sideways. Since I want my planets big (not real live big, not even KSP big, but still), each one is split into spaces that span around 4km. Those spaces are all linear and centered around origin. Rigid bodies can move from one to another, can have joints across spaces, but will never collide or interact in any way. Of course the problem is when some body wants to leave one space and enter another. We could simply teleport whole rigid body, but it would miss some collisions. My solution is to clone whole body at new location and link them with teleport joint. It's similar to fixed joint, but maintains relative offset. (don't forget to split mass in half between two bodies) In order for this to work, you need two bounding rectangles: tight and fat. When tight intersects space boundary clone body (2). Destroy cloned body only if fat stops intersecting boundary (4). For all this to work I made some changes to Box2D library, you can find my fork on github. Stitching it together Moving from planet surface space to orbital space is using simple teleportation with conversion from local space coordinates to global orbital one. I sill have some quirks to iron out, but hey, you can fly to the moon!
14. ## Open Source I shared my JavaScript 2D Game Engine.

Hi everyone, I've shared my 2D Game Engine source code. It's the result of 4 years working on it (and I still continue improving features ) and I want to share with the community. You can see some videos on youtube and some demo gifs on my twitter account. This Engine has been developed as End-of-Degree Project and it is coded in Javascript, WebGL and GLSL. The engine is written from scratch. This is not a professional engine but it's for learning purposes, so anyone can review the code an learn basis about graphics, physics or game engine architecture. Source code on this GitHub repository. I'm available for a good conversation about Game Engine / Graphics Programming
15. ## Make Proper bullets with Box2D

Hello,   i am developing an android game with libgdx and box2d. I made a simple enemy that walks towards the player. I can shoot bullets and move the bullets like this: body.applyForce(m_impulse,body.getWorldCenter(),true); // This is applied only once This moves the bullet straight forward, that is what I want. But when the ( small ) bullet hits an enemy, he gets thrown back like 100kilometers. How can i prevent that?
16. ## Replicating a simulation with Box2d, part 3.

In the last post, I explained how to solve the box2d issue about cloning a world. It's pretty simple, fairly fast and reliable in its results. I didn't use it. Why? Because there are some cases (like my game) that it doesn't work. And those cases happen when the game has two+ characters and one can go back to change their behaviour but the other one does exactly the same. Let me put it in pictures. If you have one character going back in time: The mechanic is straight forward. If the character goes back in time and does the same movements, the result will be exactly the same, because the copied world will be the same as before. If the character goes back in time and does something different, well, the result will be different, but that makes total sense, if you change the past you cannot expect the future to be exactly the same. But, if you have 2 characters, let's see what happens: Let's say character pink stays still while character blue jumps around. A possible future is generated and the pink character observes it. This is the critical part, somebody that is not causing the events but is able to see the possible future. Now, when everything is rewound, and the pink character decides to move around, the copies will not be the same as before. Thus, the future of the blue player (that was originally observed) might change, even if the pink player never touches the blue player or its surroundings. This makes no sense in the eyes of the second player. This is a huge issue! Imagine in Posable Heroes doing some tasks with the blue character, and then coming back to work with the pink character only to realise your blue characters timeline is altered. Since the game requires precision, this is unacceptable. On the 4th and final post, I'll explain what I did to finally solve this issue (spoiler alert: thank you open source). If you are interested in Posable Heroes, you can wishlist it on steam.