Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Jan 2012
Offline Last Active Jan 27 2012 04:05 PM

#4906005 C++ V.S Java for game programming.

Posted by on 24 January 2012 - 11:08 PM

This should satisfy your benchmark source request, and it should give you an ample number of languages to do additional comparisons.

First Java7 has vastly improved from Java6 but that's 5 years of updated given in 1 version.

Java 7 beats C++ and C in the the K-Nucliotide benchmark by 4 to 5 seconds.
Java 7 beats C++ in the fasta benchmark by ~1 second but loses to C by .1 seconds

C flat out wins or nearly ties vs C++ in everything except the K-Nucliotide test

C when written properly beats C++ hands down.
The drawback of C is really that some more complex tasks are a pain to write without objects.

Java's main drawback is usually memory, but it's not as bad as most people think. Sure you have some where the Binary-Tree test ends up with Java taking nearly 5x the amount of memory C does, and on even small tests it still has to load a 10-15 meg virtual machine. However, somethings like the reverse complement test it takes nearly the same amount of memory as C does.

Java also attracted every programmer who was incapable of managing memory properly in C and C++ so there are a lot of bad memory structures out their in Java because at least it doesn't do the delayed crash thing C and C++ does when you mess with the memory the wrong way. Just because java has a garbage collector doesn't mean you can ignore memory, but that's what a lot of Java programmers do.

#4905906 C++ V.S Java for game programming.

Posted by on 24 January 2012 - 04:19 PM

C is best if you're going for speed.

C++ has many of the same slowdowns as Java does now. In fact today Java7 is about as fast as C++.

Java is in limbo in terms of support. The buyout of Sun by Oracle resulted in several years of Java 6 and left Java 7's updates out in the cold. Nothing like having to wait 5 years for a JSR updates that were ready to go to be integrated in. If Java 8 is released on time then that drawback is over, but if I have to wait 5 years again I will be upset.

Java tends to have outdated API's that people insist on trying to use in games, and API's that weren't tailored for games. For example Key Listeners that were intended for Swing Gui's don't work well in games. Java Sound has been neglected for years, and because of legal issues the JMF was abandoned along with MP3 support.

You'll need to get a real game api for java like lwjgl. Otherwise you're asking Java to do things in a way it wasn't designed for.

C and C++ is easier to port to consoles. XBox, Wii and PS3 do not have a real JVM supported for games. The PS3 has a slimmed down JVM for Blue-Ray functionality only.

#4904773 I cannot get Java to properly recognize my key releases

Posted by on 20 January 2012 - 11:43 PM

That's one of several issues in java.

In truth the fix is working as intended.
This is the line you need to edit in


to try and get the code to behave the way you want it.
public static final int RELEASED_LAG_MILLIS = 5;

It is using a timer trick to ignore the key repeats. The way the code is written it waits for 5 milliseconds by default before it reverts back to the undesirable behavior.

There are other "bugs" that you'll eventually run into using KeyAdapters and KeyListeners. One annoying one is when multiple keys are being pressed.

These aren't really bugs in truth. They behave this way because the OS is really sending these events. It makes the events worthless to listen to but that's how it goes. In C and C++ the key repeat is turned off for games since it ruins the experience.

Oracle really should look into integrating some of the more useful features needed for games, but until then you might want to consider using the lwjgl or something similar.
With the lwjgl you can write something that looks at the keyboard state instead, and if you still needed to know if the key was just pressed or if the key was just released you could write something like this.
    boolean keyUp = false;
    private void checkInput() {
	    if (Keyboard.isKeyDown(Keyboard.KEY_ESCAPE)) {
		    GameThread.isRunning = false;
	    if(Keyboard.isKeyDown(Keyboard.KEY_UP)  && keyUp == false){
		    System.out.println("up Key Pressed");
		    keyUp = true;
	    if(keyUp == true && !Keyboard.isKeyDown(Keyboard.KEY_UP)){
		   System.out.println("up Key Released");
		   keyUp = false;

I believe you can even turn off the repeat events if you wanted to, but basically if you want to do what you're doing in Java correctly then you'd have to implement some native code or an exiting library that already has the native code.

#4902437 Verlet particle sytem not working

Posted by on 13 January 2012 - 02:32 PM

Usually you should stop at the first line the returns the error since that's probably where the error originates at.

When you get these kinds of problems there is a couple of ways to attack it. First thing to remember is that Null Pointer exceptions is reserved for objects only. So you just have to check each object that is in the line. Your first line in updateVerlet contains no object so that's why it's not throwing an exception since you can't not initialize a primitive.

Put this code at the first line of updateVerlet
	    if(temp  == null) System.out.println("Temp is NULL");
	    if(pos  == null) System.out.println("Pos is NULL");
	    if(oldpos  == null) System.out.println("OldPos is NULL");
	    if(acceleration  == null) System.out.println("Acceleration is NULL");

You probably have two uninitialized objects in the updateVerlet function.

#4902085 How to restart thread?

Posted by on 12 January 2012 - 02:07 PM

You actually need to use a JoinFork model for what you're using. It'll also need a JoinFork Thread pool to minimize the creation of many threads.
If you use a regular Thread Pool you'll need to find a Phaser that you can use to keep them in Sync.

A word of warning. If those threads you want to use are small fine grained tasks then be sure to build a test case to check and make sure you actually made good code. Fine Grained parallelism usually slows the system down making the serial version of the code superior because of the Sync costs.

If you can redesign to use Message Passing that would be best but can be harder to understand and design around.