We Keep Coding

Java Strategygame: Units-Coordination and Behaviour

on a 100x50 orthogonal tilegrid with 32x32 tiles, i created some animated Units, which are moved by A* (like in many strategy games usual) with a rightclick on the mouse.
The collision detection works by using a two dimensional booleanarray i gave the grid in the constructor and this says whether a tile is an obstacle or not.
Thats what i have so far and it works.
I am now figuring out, some Kind of Units coordinationsystem, which simply doesnt allows the Units to walk into each other. All of this just should be in this 32x32 tilesized RASTER not more for the moment.
I just thought this should be easy, but the grid is loaded once just like the obstacles, while the Units positions are always different and the Problem here is, that if i define each unit as an obstacle at Runtime, the obstacle at its Position stays stored in the gridarray and it stay some Kind of invisible obstacle, although it shouldnt be one. The result is, that the unit cant go the way back, where it cames from. Another Problem is of Course, that a unit can stand still or move arround(so far) and if it moves arround ist not rastered anymore.
My question now is: How can i implement a movable obstacle or do i have to implement a separate collision detection for my Units here?
PS: The Programm is quite big and i dont like to post the whole Code, although that would make all easier for u guys to help me, but if somebody understand what i mean, i can post the relevant Code snippets here on the Forum.

LibGDX Box2d Collision Error

I'm aware this is going to be somewhat vague. I'm writing an action adventure style game and I'm having a random (as in seemingly spontaneous) issue where the body I'm using for the character is getting caught on nothing. I'm not actually handling collisions, I'm just using the built in body touches body causes collision feature. The debug renderer indicates that there is a collision when there shouldn't be one and I can't discern why it would happen. What I suppose I need is someone more familiar with LibGDX than I am to surmise why this would happen.

I guess #CoderMusgrove is right.
If you have a flat floor, created out of many boxes, you might get stuck on the edges of them.
Thats because in the physics simulation, the body will be pushed down by gravity. This results in a collision, which usualy pushes the body back up.
But if you get pushed down in between two boxes, the collision resolver sometimes decides to push you back, as this is the shorter way out of the collision.
You can read more about this here.
Also the solutions are discussed in the link. There are a few different ways:
- Cutting the edges: If you cut the edges of your character, the collision resolver will more likely decide to push your character up. I tryed this solution to, but in my case it slowed down the character a bit. Also when i cut the edges to much, the character started jumping every time he moved onto another box.
- Using edge-shapes: Instead of using boxes, you could just use edges. It seems like you don't get stuck on edges that often, so that might allready solve your issue.
- Use gost vertices: Using Ghost Vertices, you can give the resolver a hint on how to resolve the colission. Those ghost vertices are used for collision response only, so they won't affect the rest of the simmulation.
- Combining boxes: The best solution would be to create one big box out of all adjacent boxes, if possible. This would solve the problem, as there are no more edges where the body could get stuck.

LibGDX + Box2D | How to make a joint between 2 bodies stiff? / How to make objects fall faster?

I use LibGDX as well as Box2D for my platformer.
I got a prototype working before but I had problems with slopes, because I just applya force to the center of the player to the left or the right. So I thought why not let Box2D do the work, since I am already using it. I tried to implement this:
http://www.badlogicgames.com/wordpress/?p=2017 (this video shows the idea pretty good)
The Basic idea is to make the player not just out of a box. But instead use a circle shape for the feet. This way slopes shouldn't be such a pain the make. So I created 2 bodies. Joint them to test it and I found something odd. Both bodies together took way more impuls to let the player body jump than it took a box with the same width, height.
Example for equal jumping of the box and the player:
if (GameKeys.isPressed(GameKeys.SPACE)) {
if (cl.isPlayerOnGround()) {
playerBody.applyLinearImpulse(new Vector2(0, 1800), playerBody.getWorldCenter(), true);playerBody.getWorldCenter(), true);
box.applyLinearImpulse(new Vector2(0, 10), playerBody.getWorldCenter(), true);
}
}
The reason for that is that I applied a high desity to the player body to prevent the joint from bouncing and make it more stiff.
My questions are:
Is there a better way to prevent the joint between the feets and the body of the player to be very bouncy than to just set it's density very high?
Is there any commonly used formula to get a good density, or is it just tweaking the values until it feels right?
Is there a way to let an object fall faster besides messing with the fall constant (-9.81f)? The player object and the box feel a bit to floaty at the moment.
I know these are multiple questions and I hope I don't ask for too much, but thanks to anyone who even reads all this mess ^^
The Pixels per Meter (PPM) is 32!
My Play.java:
http://pastebin.com/HB9h6MV6
P.s.: Sry for my bad english. I'm not a native English speaker (German). :)

Box2d helicopter physics

I am developing java game using box2d for my physics, I have got helicopter, ex:
I reduced gravity by setting:
body.setGravityScale(0.03f);
So it acts bit realistic (is affected by gravity only little bit, floating in the air)
To move it, down/up left/right I have controller, thats how I control my helicopter:
body.applyLinearImpulse(new Vector2(pValueX * 3, pValueY * 3), mainBody.getWorldCenter());
Where pValueX and pValueY are 1 or -1 (directions up/down left or right)
It works good, but now I am trying to achieve more realistic effect, when moving helicopter left/right I wanted to tilt it little bit so it works like real helicopter, but could not find proper way how to do it, I have tried applying force in different part of the body, but it makes my helicopter rotating 360 degrees if keep pressing left or right.

This question is old, but in case it's still relevant, I created a helicopter using JBox2D (which pretty much maps directly to Box2D). For tilting left/right (i.e. forwards/backwards relative to the pilot):-
heli.applyTorque(TURN_TORQUE);
or
heli.applyTorque(-TURN_TORQUE);
This rotates the heli, and then if the player wants lift:
Vec2 force = new Vec2();
force.y = (float)Math.cos(chopper.getAngle()) * -1;
force.x = (float)Math.sin(chopper.getAngle());
force.mulLocal(ROTOR_FORCE);
heli.applyForceToCenter(force);

What you can do is, just define two constants as maxForceLeft and maxForceRight. When you press left apply some force on the cockpit part of the helicopter and keep comparing it with the maxForceLeft,once it reaches that value stop applying the force.Do the same for the right button by applying the force on the tail rotor part of the helicopter.In this way you can avoid rotating it 360 degrees.Depending upon the kind of effect you want for your helicopter you can apply the forces in either upward or downward direction.

http://www.iforce2d.net/b2dtut/rotate-to-angle
What you need is rotating the body to a desired angle..
This is a great tutorial to achieve this.
I hope this would help.

More Efficient Method of Drawing Thousands of Particles (Java/Android)

So I'm writing a sort of particle simulator, like a "falling sand game" if you know what that is, and I've kind of hit a roadblock now. The way I'm doing this is I have a particle object that basically as of now has an position (int x, int y) and that's it. The way I'm drawing/moving them, is with a thread and the onDraw event for an android panel. Each time onDraw is called I loop through all the particles, move them down one pixel unless they hit the bottom and then draw them, this is pretty smooth until I get to about 200 particles, then the fps drops significantly. I know this is computation heavy the way I'm doing it, there's no debate about it, but is there any way I could do this to allow a lot more particles to be drawn and with less lag?
Thanks in advance.

I take it you're using an individual-pixel drawing function for this? That would indeed be slow.
I see a couple ways to improve it. First is to put the pixels into an in-memory bitmap then draw the whole bitmap at the same time. Second, since particles are always just going down one pixel, you can scroll part of the bitmap instead of replotting everything. If Android doesn't have a scroll then just draw the bitmap one pixel down and start a new bitmap for the particles above the scroll. You'll have to fix up the particles on the bottom, but there are fewer of those.

I've never done things like this before, but I have done some complex cellular automata. Sorry if this is too vague.
The basic idea here is to mark all particles that should "keep falling" or "not move" and exclude them from complex processing (with a special short/fast processor for the "falling" list - all you need to do is drop each one by a pixel).
The acceleration for non-moving particles - static particles (I'll call them S particles), is that they don't move. Mark it for all non-moving regions (like a gravity-immune "wall" or "bowl" that a user might make. Mark particles above it S if they are stable, so for example for liquid, if it has S particles under, and to both sides of itself, it will not move. For something like sand that forms piles, if it has an S in each of the three spots under it, it makes a pile, you'll get nice 45-degree piles like this, I'm sure you can change it to make some things form steeper, or less-steep piles. Do S mapping bottom-up.
The acceleration for particles with no particle under them is falling - F particles. Particles with an F particle under them are also F particles. Mark these bottom-up as well.
Particles unmarked F or S are complex, they may start falling, stop falling, or roll, use the slow processor, which you already have, to deal with them, there shouldn't be many.
In the end what you will have is many many fast particles. Those in a pile/lake and those raining down. The leftover particles are those on the edge of slopes, on the top of lakes, or in other complex positions. There shouldn't be nearly as many as there will be fast particles.
Visually mark each kind of particle with some colour, complex particles being bright red. Find cases where it is still slow, and see what other kinds of fast processors you should make. For example you may find that making lots of piles of sand creates lots of red areas along slopes, you may want to invest in speeding up "rolling zones" along the slopes of piles.
Hope it makes sense. Don't forget to come back and edit once you've figured something out!

You may want to look into OpenGL ES hardware acceleration and renderscript. It doesn't give you a more efficient solution code wise (see the other answers for that). It does open up a lot more processing power for you to use however. You can even run the entire simulation on the GPU (possibly, don't know your implementation details).
Edit
Also, if you still decide to do the processing in java, you should look at Method Profiling in DDMS. This will help you visualize where your performance bottlenecks are.

If you blur your image a bit, then you could just move half particule at a time, maybe one fourth only and print them all.. that would cut computation and the user wouldn't see it, getting the feeling all particules move.
But what ever you choose, I think you should be put a strong limit, not all users have powerfull android devices.
Regards,
stéphane

I think if particles are close each other, you can create objects that represent 3 or more particles.
When displaying several particles on screen, sets of grains maybe gets unnoticed.