We Keep Coding

Slick2d Java reversing the moving direction of an object

I'm working on this game using Java and slick2d library and I'm supposed to reverse the direction of some moving vehicles (eg:bikes) when they reach a certain x-coordinate.
Logic seems simple enough, yet some of them move right past the x-coordinate, while some reverses the direction. Confused as to why. Any help would be appreciated.
Here's my code in the update() method. getX() returns the x location from superclass as a float. BIKE_SPEED is a float, delta being the milliseconds passed since last frame.
#Override
public void update(Input input, int delta) {
if ((int)getX() == 24 || (int)getX() == 1000) {
moveRight = !moveRight;
}
move(BIKE_SPEED * delta * (moveRight ? 1 : -1), 0);
}

I'm not familiar with slick2d, but in general, it's better to use >= or <= instead of == in cases like this. The object (bike) may "jump" right past the boundaries, without triggering your change of direction condition.

How to check and test if two lines (linear equations) are parallel by throwing an illegalArgumentException?

I'm doing a project at school which one of the methods find the point of intersection of two lines. It substitutes one line’s mx+b value for the other equation’s y values, then it solve for x. I'm trying to set up a "throw" where if the two lines are parallel, it will throw an illegalArgumentException. Here is the method (from the Line class) I'm trying to setup:
public Point findIntersect(Line otherLine) {
double slope2 = otherLine.getSlope();
double yIntercept2 = otherLine.getIntercept();
double newX = (intercept - yIntercept2) / (slope2 - slope);
double newY = slope * newX + intercept;
Point aPoint = new Point(newX, newY);
return aPoint;
}
And the method that's being substantiated from:
public Point(double x, double y) {
setLocation (x, y);
}
Does anyone have any suggestions as how to properly do this?

Check if slopes of lines are equal. This indicates that the lines are parallel.
You can have a check similar to this:
if(slope == slope2){
throw new IllegalArgumentException("Lines are parallel.");
}

Insert this after the first line,
if (this.slope == otherLine.getSlope()) {
throw new IllegalArgumentException("Parallel lines will never intersect.");
}

It is not robust to test whether two floating-point values are equal or not. They could be different, yet so close to each other that their difference is very small and you get an overflow to infinity when you carry out the division by this difference.
It will be more useful for most purposes to carry out the computation of newX and then check whether the value you get is within a reasonable range. In some contexts it is better to just check whether it is infinite.
if( Double.isNaN(new X) ) {
// This happens when we divide 0 by 0
// The lines are the same line, so there are many intersections
throw new IllegalArgumentException("The intersection is not unique.");
}
if( Double.isInfinite(newX) ) {
throw new IllegalArgumentException("These line are parallel or almost so.");
}

Sorting an array according to its Geolocation positions

I have an array with lat and lng in the custom model . i want to sort the array so that minimum distance from my location comes at the top position and so on.
Here is what i have tried
myLocation = new Location("");
myLocation.setLatitude(Double.valueOf(MyApplication.getInstance().getLatitude()));
myLocation.setLongitude(Double.valueOf(MyApplication.getInstance().getLongitude()));
Collections.sort(pings, new DistanceComparator());
private class DistanceComparator implements java.util.Comparator<PingModel>
{
#Override
public int compare(PingModel lhs, PingModel rhs)
{
Location lhsLocation = new Location("");
lhsLocation.setLatitude(Double.valueOf(lhs.latloc));
lhsLocation.setLongitude(Double.valueOf(lhs.lngloc));
Location rhsLocation = new Location("");
rhsLocation.setLatitude(Double.valueOf(lhs.latloc));
rhsLocation.setLongitude(Double.valueOf(lhs.lngloc));
return (int)rhsLocation.distanceTo(myLocation) - (int)lhsLocation.distanceTo(myLocation);
}
}
The result is not sure what kind of sorting it is doing but its not according to distance.

You have a copy-paste error. Change these 2 lines:
rhsLocation.setLatitude(Double.valueOf(lhs.latloc));
rhsLocation.setLongitude(Double.valueOf(lhs.lngloc));
to:
rhsLocation.setLatitude(Double.valueOf(rhs.latloc)); // It's rhs!
rhsLocation.setLongitude(Double.valueOf(rhs.lngloc)); // It's rhs!
Apart from this, you shouldn't convert to int before subtracting the distances. In fact, you should avoid using subtraction as the return value of a comparator. This has some well-known flaws, in particular, as distances are float values, they might not fit into an int. And what is more important, the result of the subtraction might not fit into an int. This means that the int you'd be returning might overflow, leading to unexpected results.
I'd recommend you to use clear, understandable code, instead of smartish, tricky code. Consider changing the last line of your comparator to a common tri-state if:
float lhsDistance = lhsLocation.distanceTo(myLocation);
float rhsDistance = rhsLocation.distanceTo(myLocation);
if (lhsDistance < rhsDistance) {
return -1;
} else if (lhsDistance > rhsDistance) {
return 1;
} else {
return 0;
}
Note: if the values you're comparing are in fact equal, then you must return 0 in your comparator. Otherwise, you might experience subtle, nasty bugs, as explained in this answer.

Not sure if this will help, but I was working on a similar project and found this link to be very helpful : http://www.geodatasource.com/developers/java .
Basically if you have you location; use the distance function to calculate new position - your position, and then sort based on this. Loop through the array of locations, and sort based on results.
Hope it helps.
Dan.

Can you try following
return Float.compare(lhsLocation.distanceTo(myLocation), rhsLocation.distanceTo(myLocation))

Converting to int before substraction might not always work. For example, if your distanceTo() function return km and the distance from your point and the data points is within 1 km then the result of subtraction may be 0.
Instead of
return (int)rhsLocation.distanceTo(myLocation) - (int)lhsLocation.distanceTo(myLocation);
Try
return (rhsLocation.distanceTo(myLocation) - lhsLocation.distanceTo(myLocation)) > 0 ? 1 : -1;

Java Game Physics - Determine intersection and collision detection

My question can actually be broken down into two parts. The first, is what is a reasonable method for determining collision in a Java game? My second, is how to find the point of collision for use later?
Originally I was implementing a rudimentary collision system using a thread I found earlier with a simple method for finding a collision in a polygon. I have posted the code below. However as best I can tell, this will not show me the collision point, and I would have to do something separate to find it.
public boolean collisionDetection(int charX, int charY) {
if(boundry == null)
return false;
int numVert = boundry.length;
boolean ret = false;
for(int i = 0, j = numVert - 1; i < numVert; j = i++) {
if (((boundry[i].y >= charY) != (boundry[j].y >= charY)) && (charX <= (boundry[j].x -boundry[i].x) * (charY - boundry[i].y) / (boundry[j].y - boundry[i].y) + boundry[i].x)) {
ret = !ret;
}
}
return ret;
}
But I had a thought while working on this... Let us presume that I input my coordinates into the system as Points. I did them in order (e.g. point 1 -> point 2 -> point 3 -> point 1).
Knowing the points are in a connected order (e.g. they form the boundary of the object), is it then logical to say I could just use a number of line intersection methods to find if the character intersected with the border of my polygon? I know the characters current position, as well as the intended position.
Any thoughts, or if you have a suggestion a better implementation method?

you need to be doing either point to pint or box to box collision See my answer here
this explains two methods of collision detection. its in 3D but just drop the third axis and can be used for 2D. Hope this helps

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.