We Keep Coding

Calculate which way to turn a boid to get to an object in Java

tl;dr: I have angle x and angle y in radians; Which way do I need to turn angle x to match angle y?
I have a boid with an angle which desires to point towards a goalAngle (angles are in radians). However the boid cannot turn at a speed greater than defined in Constants.maxTurningSpeed (multiplied by timePassed - how long it has been since the last physics update). If this speed is exceeded then it should instead turn at the maximum speed in that direction. The only issue is which direction.
The following code works for most scenarios but can break when going over the 0 threshold. Any help?
if ((this.goalAngle - this.angle) % (2*Math.PI) > (Constants.maxTurningSpeed*timePassed)) { // turn left or right?
this.angle += Constants.maxTurningSpeed*timePassed;
} else if ((this.goalAngle - this.angle) % (2*Math.PI) < -(Constants.maxTurningSpeed*timePassed)) {
this.angle -= Constants.maxTurningSpeed*timePassed;
} else {
this.angle = this.goalAngle;
}
Thanks

I found a solution online in this blog post by Paul Bloxel. This better describes the issue and solution.

Java: Recursion causes Stack Overflow Error even though code is correct

I am trying to make a program that goes through a sprite image, and then makes each shape in it a new image. For example, if we took Mario, I want the hat to be one image, the face to be another, and so on. I have gotten my program to work on small 32x32 images, but if I want to run this on a larger image, it causes a Stack Overflow Error. If I was using C++, I would just go about this by clearing the stack after each recursive call, but as far as I know, Java does not let you directly clear the stack. I want my program to run on Windows, Linux and Mac so I thought Java would be the best option, so I don't really want to switch the language I am using. Is there a way to delete whatever was stored on the stack after each recursive call in Java?
Here is my code, just in case there is an error with it.
private void makeShape(int x, int y)
{
if(x < 0 || y < 0 || y >= sprite.getHeight() || x >= sprite.getWidth())
{
return;
}
if(sample == colorData[y][x] && table[y][x])
{
tempBlankImage[y][x] = sample;
table[y][x] = false;
makeShape(x, y - 1);
makeShape(x, y + 1);
makeShape(x - 1, y);
makeShape(x + 1, y);
}
else
{
return;
}
}
The x and y points are generated from a for loop that goes through the image and checks if a point has been added to a shape, and if not it makes a shape from its surrounding pixels.
UPDATE:
private int[][] makeShape(int sample, int x, int y)
{
int[][] tempBlankImage = blankImage();
Queue<Point> queue = new LinkedList<Point>();
queue.add(new Point(x,y));
while(!queue.isEmpty())
{
Point point = queue.remove();
if(sample == colorData[point.y][point.x] && table[point.y][point.x])
{
tempBlankImage[point.y][point.x] = sample;
table[point.y][point.x] = false;
if(point.y < sprite.getHeight() -1)
queue.add(new Point(point.x, point.y+1));
if(point.y > 0)
queue.add(new Point(point.x, point.y-1));
if(point.x < sprite.getWidth()-1)
queue.add(new Point(point.x+1, point.y));
if(point.x > 0)
queue.add(new Point(point.x-1, point.y));
}
}
queue = null;
return tempBlankImage;
}
The Stack Overflow Error has stopped, now I am getting out Out of Memory: Java Heap Space, even though I increased it to 2 GB. I am adding each int[][] to an ArrayList, which I am guessing is the issue. How else can I store the data?

Java is well known for it's automatic well defined and tested memory management system - it is generally not good idea to manage memory on your own even if it is possible (because in some level it actually is).
What will clearing stack give you if the alghoritm execution time will let you get a beard and be able to tell stories about it to your grand children?
Do not make it as recursive - think about some iterative form of an alghoritm. You can for example iterate over all image's pixels and add them to the appropriate image (due to it's color) that will be stored in some HashMap like in this pseudo code
HashMap<Color, Image> images= new HashMap<Color, Image>();
for(Pixel pixel : originImage)
Color color = pixel.getColor();
images.get(color).put(pixel)
Do not waste your life for bad code

Andengine PhysicsHandler makes player look laggy

Hey my problem is that in the onUpdate in PhysicsHandler the pSecondsElapsed often jumps from 0.016... to 0.038 which makes the player move in such big steps that it looks like the player would lagg.
Here to the importante Code from the onUpdate :
#Override
protected void onUpdate(final float pSecondsElapsed, final IEntity pEntity) {
if(this.mEnabled) {
/* Apply linear acceleration. */
final float accelerationX = this.mAccelerationX;
final float accelerationY = this.mAccelerationY;
if(accelerationX != 0 || accelerationY != 0) {
this.mVelocityX += accelerationX * pSecondsElapsed;
this.mVelocityY += accelerationY * pSecondsElapsed;
}
/* Apply angular velocity. */
final float angularVelocity = this.mAngularVelocity;
if(angularVelocity != 0) {
pEntity.setRotation(pEntity.getRotation() + angularVelocity * pSecondsElapsed);
}
/* Apply linear velocity. */
final float velocityX = this.mVelocityX;
final float velocityY = this.mVelocityY;
if(velocityX != 0 || velocityY != 0) {
pEntity.setPosition(pEntity.getX() + velocityX * pSecondsElapsed, pEntity.getY() + velocityY * pSecondsElapsed);
}
}
}
btw I am only using the linear velocity. Does anyone have a solution for this? Thanks for your help!

I went ahead and looked through the repository for this engine and I found a class that may be a help to you. The base engine class has an extension called Fixed Step Engine that should allow you to control the delta time per frame, which may be worth trying out (if you haven't already) for smoother physics.

In combination with FixedStepPhysicsWorld you will get the best possible result but: There is a small "mistake" inside the FixedStepPhysicsWorld class:
Change onUpdate as follows:
...
while(this.mSecondsElapsedAccumulator >= stepLength && stepsAllowed > 0) {
world.step(stepLength, velocityIterations, positionIterations);
this.mSecondsElapsedAccumulator -= stepLength;
stepsAllowed--;
}
this.mPhysicsConnectorManager.onUpdate(pSecondsElapsed);
to
...
while(this.mSecondsElapsedAccumulator >= stepLength && stepsAllowed > 0) {
world.step(stepLength, velocityIterations, positionIterations);
this.mSecondsElapsedAccumulator -= stepLength;
stepsAllowed--;
this.mPhysicsConnectorManager.onUpdate(stepLength);
}
The problem in the original code is that the PhysicsConnectors get updated after the PhysicsWorld made multiple steps (most of the cases). My code fixes this issue. Whenever the UiThread draws the connected entities, they are always at the position where their connected bodies are. They do not skip a Physics-step.

Light/Ray casting in java?

I've been trying to make a dynamic light system in java, without using libraries. For some reason, though, it seems I can't get light to run efficiently. It flickers and lags a ton. I'm doing this with no previous understanding of lighting engines in games, so I'm open to suggestions. Here is my current update method:
public void updateLight( ArrayList<Block> blocks )
{
//reset light
light.reset();
//add the x and y of this light
light.addPoint( x, y );
//precision for loops
int ires = 1;
int jres = 2;
for( int i = 0; i < width; i += ires )
{
//get radians of current angle
float rdir = (float)Math.toRadians( dir + i - width/2 );
//set up pixel vars
int px, py;
for( int j = 0; j < length; j += jres )
{
//get position of pixel
px = (int)ZZmath.getVectorX( x, rdir, j );
py = (int)ZZmath.getVectorY( y, rdir, j );
//if point gets found
boolean foundpoint = false;
for( int n = 0; n < blocks.size(); n ++ )
{
//check if block is solid
//also check that collision is possible really quickly for efficiency
if( blocks.get( n ).solid )
{
//get info on block
int bx = blocks.get( n ).x;
int by = blocks.get( n ).y;
//quick trim
if( Math.abs( bx - px ) <= 32 && Math.abs( by - py ) <= 32 )
{
int bw = blocks.get( n ).w;
int bh = blocks.get( n ).h;
if( ZZmath.pointInBounds( px, py, bx, by, bw, bh ) )
{
//add point to polygon
light.addPoint( px, py );
//found point
foundpoint = true;
}
}
}
}
//if a point is found, break
if( foundpoint )
{
break;
}
//if at end of loop, add point
//loose definition of "end" to prevent flickers
if( j >= length - jres*2 )
{
light.addPoint( px, py );
}
}
}
}
This modifies a polygon that displays for light. I'll change that later. Any idea of ways I can make this run better? Also, no, no libraries. I don't have anything against them, just don't want to use one now.

You implementation doesn't appear to use much of the stuff I see here:
http://www.cs.utah.edu/~shirley/books/fcg2/rt.pdf
I'd recommend digesting this completely. If your objective is to understand ray tracing deeply, that's how it should be done.

Maybe your objective was to learn by writing your own raytracer. In my experience I would end up rewriting this code several times and still not get it completely right. It's good to get your hands dirty but it's not necessarily the most effective way to go about things.
Overall it looks like you need to study (object oriented) programming concepts, and take a data structures and algorithms course.
The biggest thing is readability. Document your code, for your future self if no one else. This means Clear comments before and during updateLight(). The existing comments are alright (though they paraphrase the code more than justify it), but "really quickly for efficiency" is a lie.
For a small issue of readability that could be a tiny drag on performance, make a local variable for blocks.get(n). Name it something short but descriptive, save typing and only make one method call to retrieve it.
"if at end of loop": I have no idea which loop you mean, and the for loops have definite ends. A comment }//end for or }//end for width is often helpful.
Checking if the block is solid is unnecessary! Just store your blocks in two lists, and only go through the solid blocks. Even if you have some desire to have flickering blocks, one remove and add is cheaper than O(width*length*numbernotsolid) extra work.
There are many ways you could structure how the blocks are stored to facilitate quick testing. You only want or need to test blocks whose coordinates are near to a particular light. The basic strategy is divide the space into a grid, and sort the blocks based on what section of the grid they fall into. Then when you have light in a particular section of the grid, you know you only need to test blocks in that section (and possibly a neighboring section - there are details depending on their width and the light's).
I have no idea whether that is along the lines of the right approach or not. I don't know much about raytracing, although it is or used to be rather slow. It looks like you have a decent naive implementation. There might be a slightly different naive approach that is faster and some more difficult (to code to completion) algorithms that are moderately yet more fast.
Also, I see no need to do this breadth first. Why not solve for one line (you call them pixels?) at a time. Count the number of times this code calls Math.toRadians. It looks like it's just an extraneous line because you could work along the same angle until ready for the next.

Using the distanceTo method

My code should accept locations that has accuracy under 100, if the new location accuracy is smaller then the old more in 20 then use the new one.
Also if the distance from the new location to the old one is larger then 200 use it.
I have no idea why but after testing my code I got the following locations in my db:
The last 3 records are less then 200m from each other, how come I use them??
Here is the code:
int Aloc = (int) loc.getAccuracy();
int AnewLoc = (int) newLoc.getAccuracy();
if(Aloc > AnewLoc +20)
sendTask();
else
{
float distance = loc.distanceTo(newLoc);
if(distance > 200)
sendTask();
}
This code is executed to locations that their accuracy is less then 100.
EDIT
after changing the condition to
if((AnewLoc+20) < Aloc)
I received the following records:
The new records has larger accuracy then the old one and his distance is less then 200(0.01407 km which is 14 meters). I can't understand how come it pass by the code and sent to the db.

Change your checking logic like this
int Aloc = (int) loc.getAccuracy();
int AnewLoc = (int) newLoc.getAccuracy();
if(AnewLoc < ( Aloc+20))
sendTask();
else
{
float distance = loc.distanceTo(newLoc);
if(distance > 200)
sendTask();
}
This should work