This was posted over on GameDev.net

Posted Today, 10:44 AM
"I think I've seen folks here that are also active over on java-gaming.org, so hopefully someone will see this and let the board ops know that their registration page captcha is broken: no image is displayed. On the off chance it might work, I tried the speech version, but that's broken, as well. "

You may want to check it out. Here the link to the thread http://www.gamedev.net/topic/601402-jgo-registration-page-captcha-broken/

Could you clarify what you mean by "funny places"? Is there some sort of pattern to where the area is drawn (such as always offset by x or rotated around y). Finding where the area is incorrectly being offset should help you to debug.

No. Webstart is very easy to integrate with a Java desktop application. I would definitely recommend using it, but you can wait if you want without having to worry about it.

Also, you are adding the same value to both the x and y. You should be scaling a unit length (1 unit long) vector that points from your object to the gate. Then add that to its velocity.

You could definitely get better performance than that. Think of how many triangles a modern game spits out at 60 fps. You are probably not reaching super fast performance because of bandwidth. You may be trying to send too much information to the graphics card each frame. With that said, ask yourself if you actually need more performance. If you are getting 60 fps and you are drawing what you wanted to draw, then don't worry about it. Maybe latter you can try to step that up for low end machines, but there is not much of a reason to spend time optimizing until you are nearly done.

I am just maintaining the velocities. I add an vector pointing to the center of the screen to each object's velocity, and if two objects are intersecting I push their velocities apart. Basic rigid body physics is the easy part. I already have a class for that, just didn't use that here for some reason. The hard part of physics is satisfying constraints.

It was actually the opposite for me. I used Eclipse first then switched to NBs. I first used Eclipse a few years ago and at the time the interface was kind of clunky. Since then, they have made a lot of improvements. Now it is pretty much entirely personal preference. If there is some specific feature you really want, there may be some difference, but for the general user there really is no wrong choice.

Here we go...
They are both good. Try them and see which one you like more.

This is only collision detection right now, but one of the nice things about GJK is you just need to implement the support function to use any shape. From a code perspective, there is a Collidable interface with the getSupport function. Any two shapes implementing that can be tested for collisions. Once I add some real physics to this, a rigid body would contain a list of Collidables that define its area. It would then be strait forward to add a new shape such as a capped rectangle or ellipse or whatever. So in answer to your question, yes it would be easy to add a new shape. Changing other aspects of the physics would as usual be more difficult.

It is interesting how quickly the performance collapses. There is probably something else going on other than the CPU load. Maybe the memory bandwidth becomes the bottleneck or something with the JVM. I'm not going to bother digging to deep into this because with a good broad phase, it all becomes kind of irrelevant.

You could check out this tutorial I wrote. It handles input from Java2D.

Yes, the algorithm is intended for only convex shapes. If you correctly create your support function, it will actual define the shape of the tightest convex hull regardless of whether or not the shape itself is convex. Sort of an unusual property, but it could actually be useful for some situations.

There are some other interesting things that I am looking into. It may be possible that for a shape that is offset and rotated, to not actual need to transform the shape at all. For an offset shape you just add the offset to the returned support point, rather than offsetting all the points first. I am not entirely sure, but for a rotated shape you may be able to rotate the direction vector before asking for the support, then unrotate the returned point. Combining these two means you would never need to actually transform a polygon for example. This would be a big plus and would also open the opportunity to make some form of hashed support look-up for polygons because the geometry would be static. I am still working through some of this, but it seems like there is a lot more potential for optimization.

There is a good video at the top of this page http://mollyrocket.com/forums/viewtopic.php?t=245. It discusses GJK in the 3D case where there is a greater benefit to using it. This page http://physics2d.com/content/gjk-algorithm has a good tutorial as well.

The GJK algorithm is commonly used for 3D collision detection. It is not used as often for 2D because SAT is about the same speed and less complicated. That's not to say there is no benefits to GJK for 2D. My favorite thing is that you can test any two shapes you define a support function for. The collision detection algorithm doesn't need to know anything else about the shapes or how they are stored.

From the JavaDoc "Beginning with Java 1.1, the background color of offscreen images may be system dependent. Applications should use setColor followed by fillRect to ensure that an offscreen image is cleared to a specific color".

You can setBackground from Graphics2D or for the underlining component to control this. I don't know if there is any performance difference between the two operations.

Yes. I would like to expand this enough so that it can be used for physics simulation where it's useful to have a bit more information. I haven't done enough research into EPA to implement that part yet, so it will have to wait.

Ya, that's around the point where the performance breaks down for my PC as well. 250 objects is roughly 3,100,000 collision checks / sec or about 31,000 per frame. Once I add in some broad phase collision detection, this should be fine for most games of moderate complexity or less. I need to try out some caching. If the last point of the simplex (for non-intersecting objects) is saved, you can start from there on the next iteration. This would allow you to eliminate most non-intersections in one iteration instead of two. It would also be very easy to multi-thread this because each check is independent of the others.

I have been working on a 2D implementation of the GJK collision algorithm, and I now have an applet put together to demonstrate it. The applet can be found here. Let me know what you think. If you could share what sort of performance you are getting, that would be great. I will post the source code soon, once I get it cleaned up a bit.

Just as a note, the collision detection is intentionally naive (every object tested against every other object). This was to make it easier to stress the simulation.

You could first try adding System.nanoTime() calls during each update loop and calculate the time they take. This is so you can establish whether or not the update frequency is what is causing the problem. If you are using sleep(), the sleep time is the minimum amount of time slept, but it could sleep longer so that may be the problem.

Are you sure its using page flipping? BufferStrategy will try to use page flipping, but if the hardware does not support it it will use blitting. You can find out by getting the BufferCapabilities from the BufferStrategy.

It would probably be fine, but most computer screens will refresh at 60 Hz. This means sometimes the same image will be sent to the screen twice. Most people will not notice this, so it shouldn't be much of a problem.

25 FPS is just around the point when things become fluid. Higher FPS's are noticeably smoother. I don't believe the human eye really sees in FPS though. It is a continuous response and for things that are actually frame based, the mind fills in the gaps. Ultimately it is a bit irrelevant in a game because very few monitors support more than 60 Hz.

You should look at the Redbook. It is the programming guide for OpenGL. The commands for LWJGL are pretty much identical to the normal OpenGL calls, so it should be strait forward to use other material. If you dig around on the LWJGL page you can also find some additional information in the documentation section.

When concatenating AffineTransforms, just remember that they are applied to the object in the opposite order as you put them together. If you want to rotate the sprite, scale it, then translate it, you want to construct it by AffineTransform.translate().scale().rotate().

Try reversing the order of your scale and rotate.

I depends on what method is used to scale, but yes it can look ugly. The faster the interpolation method is the worse it generally looks. One way you can get around this is to scale the images once when the game starts up. Performance is less of an issue then so you can use the best looking interpolation available.

Could you put some debugging output in your code so that we can send you some useful console output? This is why you should have some form of logging in any non-trivial program.

Your Applet wouldn't load on my system. All I got was a grayish-blue blank screen. My OS is Windows 7 (64 bit) and my Java is up to date. I would recommend that you try breaking your applet down to its simplest parts. Once you have that working, add back in your other stuff until it breaks. That will tell you where the problem is.


That shouldn't cause any problems while its running, but likely means your code is not very maintainable. You should look into component based entities, which is a popular design pattern to eliminate the need for deep object hierarchies.

You can define a position as a offset from the origin (a vector) or as several values (a point). There are position vectors, also sometimes called a radius vector, and closely related with displacement vectors. If you are using Cartesian coordinates, these are all pretty much equivalent, but not necessarily so in any other basis.

A position IS a vector. It is a direction and distance from an arbitrary point in space (the origin).

Edit: It may be more accurate to say you can define the position as a vector in the above way when using the Cartesian coordinate system..

First stop for all API questions should be the Javadoc (http://download.oracle.com/javase/6/docs/api/). Look up BufferStrategy and BufferCapabilities. The class is well documented.