game development in java

As i said a little earlier, I await the day when theres a Java Virtual Machine on every console so that amateur game developers can start writing games for mass market platforms...

Go SUN!! Go Java!!

quote:

---

Q: Suppose game developers want to migrate to the Java platform. What kind of technical barriers might they face?

A: The most difficult barrier is psychological, which is the mistaken belief that Java technology is slow. Java technologies do not compromise what you are trying to build. Java technologies today perform as well as C++.

---

Uh, correct me if I''m wrong but I find this pretty hard to believe. Assuming the code written in both languages is decent then surely C++ is faster hands down, no?

I''d like to see how Doom 3 would perform if written in Java.

quote:

---

Original post by psamty10
As i said a little earlier, I await the day when theres a Java Virtual Machine on every console so that amateur game developers can start writing games for mass market platforms...

Go SUN!! Go Java!!

---

by the time PS2, GC, Xbox, Windows, Linux, and Mac supports Java, and runs at least 90% of C++ speed, I migrate to Java.

quote:

---

Original post by template
Uh, correct me if I''m wrong but I find this pretty hard to believe. Assuming the code written in both languages is decent then surely C++ is faster hands down, no?

---

No.

Modern JIT compilers and such work extremely well. And they will just keep improving. Compile your code in C++, and your code is fixed. Byte compile it in Java, and your code will be optimized for every system it is run on.

We are rapidly approaching an environment where everything is byte compiled and run in virtual machines. .NET and Java are setting the stage, and things will just keep improving from here.

CM

quote:

---

Original post by psamty10
As i said a little earlier, I await the day when theres a Java Virtual Machine on every console so that amateur game developers can start writing games for mass market platforms...

Go SUN!! Go Java!!

---

Xbox platforms will never support a JVM. At least not officially...

When you download the java vm from sun, is that a JITer, or just a regular VM? If it isn''t the JITer, then why would I care how fast a JIT compiler can make the code go? Most people will have at best the standard download and won''t want to do any extra steps at all to get the game to run.

Also, IME, JIT compilers have a __LONG__ way to go still. They are up to about 95% the speed of C++ with properly formed code (at least in the case of the .Net JITer), but they can theoretically outperform C++ code.

With Java 1.5 supporting Generics it looks like Java will be my new primary language once it''s out of beta stages. However I wish they would implement operator overloading. Having to use an equals() method instead of just overloading the == operator is a pain in the arse and makes code readability worse.

Don''t you find the idea of operators itself a pain? Why is there one syntax for one set of functions and an entirely different one for another set of functions? Uniformity is good, and I really like that aspect of Lisp.

The next best thing would be to have a very generic parser that allows the definition of arbitrary n-ary operators. Unrealscript kind of supports that idea, except it only supports unary and binary operators, and you can only set the precedence level for new operators (when overloading preexisting ones, they keep their original precedence). It also only allows a subset of the allowed symbols for operators. You can use words and such though, so it isn''t too bad in that respect.

Not really, they''re only a pain if the person who wrote the class doesn''t know how to use them properly. I see how they can be abused but using == for checking if two objects are the same and != to determine if they''re different isn''t difficult to understand.

Also if the documentation for the class is good then it shouldn''t be difficult to find out which operator does what.

I''ve never used Lisp before so I can''t really comment on that.

quote:

---

Original post by Conner McCloud

quote:

---

Original post by template
Uh, correct me if I''m wrong but I find this pretty hard to believe. Assuming the code written in both languages is decent then surely C++ is faster hands down, no?

---

No.

Modern JIT compilers and such work extremely well. And they will just keep improving. Compile your code in C++, and your code is fixed. Byte compile it in Java, and your code will be optimized for every system it is run on.

We are rapidly approaching an environment where everything is byte compiled and run in virtual machines. .NET and Java are setting the stage, and things will just keep improving from here.

CM

---

I disagree. Even with JIT compilation, the way in which things are coded in Java is inherently inefficient. Classes are constantly being instantiated and having to be destroyed by the GC.

quote:

---

Original post by Tron3k
I disagree. Even with JIT compilation, the way in which things are coded in Java is inherently inefficient. Classes are constantly being instantiated and having to be destroyed by the GC.

---

Poorly written C++ can suffer from the same problem. But a good JIT compiler can circumvent some of that, and good programming circumvents some of the rest.

Keep in mind that comparing highly optimized C/C++ with poorly written Java isn''t a fair comparison.

And also keep in mind that Windows is moving to a managed environment, in which regular programs will suffer a performance hit. I don''t know for sure, but I believe .NET has a Java interface, so Java programs will run at full speed on those systems.

CM

quote:

---

Original post by template
Not really, they''re only a pain if the person who wrote the class doesn''t know how to use them properly. I see how they can be abused but using == for checking if two objects are the same and != to determine if they''re different isn''t difficult to understand.

---

I agree, although I don''t specifically feel operator overloading adds anything. But more importantly, String should not exist. I can''t figure out the logic that was used to come to the conclusion that Strings should be their own special type of object.

CM

My point wasn''t the operator overloading was easily abused, but that operators themselves are unneeded. Lisp doesn''t have operators, it just has functions. In C, ''+'' is a function with a special syntax (you put something before and after, instead of doing +(a, b) like with regular functions), but in Lisp, all functions have the same syntax.

About Windows going to .Net: The language will still not be native code, and if regular programs suffer a speed hit it will only be when talking to managed API. The machine code that is native now will still be native (well, except in the case of 64bit processors that use a different instruction set).

quote:

---

Original post by Extrarius
When you download the java vm from sun, is that a JITer, or just a regular VM? If it isn't the JITer, then why would I care how fast a JIT compiler can make the code go? Most people will have at best the standard download and won't want to do any extra steps at all to get the game to run.

---

All Sun's JVM use JIT. The server one (only included in the JDK, not JRE) can make more aggressive optimizations but it will cost a bit more time at startup. It should be the best choice for apps like games, where you have to wait for data loading anyway. I don't know exactly why Sun doesn't ship it with JRE.

quote:

---

Original post by Tron3k
I disagree. Even with JIT compilation, the way in which things are coded in Java is inherently inefficient. Classes are constantly being instantiated and having to be destroyed by the GC.

---

You are mistaken. Current JVMs have a highly efficient way of managing memory. They have fast access memory pools so that allocation and deallocation are cheap. There is an article on the subject on IBM developerworks : if you are interested in, I can post the link.

One of the strength of Java is that the VM is built to optimize the code which is the most "clean" (in term of OO design), so that some ugly hacks once used for speed are no longer necessary. Highly optimized C/C++ with assembly will always be faster but at a higher maintenance cost.

Today the most sluggish thing in Java is probably its Swing GUI and 2D stuff, because it is almost not hardware accelerated. But for games it shouldn't be an issue.



[edited by - overnhet on March 9, 2004 3:59:10 PM]

quote:

---

Original post by Extrarius
My point wasn''t the operator overloading was easily abused, but that operators themselves are unneeded. Lisp doesn''t have operators, it just has functions. In C, ''+'' is a function with a special syntax (you put something before and after, instead of doing +(a, b) like with regular functions), but in Lisp, all functions have the same syntax.

---

Isn''t that reverse polish notation? Nobody likes HPs, they should just give up.

For native types, operators make sense. That''s the way we do arithmetic on paper, so a direct translation to code is logical and increases both readability and writability. But for derived types, I agree that all operators [including comparisons] could easily be gotten rid of without any suffering.

CM

Reverse polish notation is somewhat simmilar to lisp for simple math functions in a way I guess, but it removes the parenthesis and seperates arguments from the functions they are being passed to which makes it more difficult to read:

Common Lisp: (* (+ 1 2 3 4 5) 6 7)
vs
Reverse Polish: 7 6 5 4 3 2 1 + + + + * *
vs
C: (1 + 2 + 3 + 4 + 5) * 6 * 7

Infix notation for math operators is natural, but I''d also say BASIC-like languages are a lot more natural for most people. Natural doesn''t neccessarily mean best for a programming language IMO.

quote:

---

Original post by Extrarius
Common Lisp: (* (+ 1 2 3 4 5) 6 7)
vs
Reverse Polish: 7 6 5 4 3 2 1 + + + + * *
vs
C: (1 + 2 + 3 + 4 + 5) * 6 * 7

---

Ahh...I see.

quote:

---

Infix notation for math operators is natural, but I''d also say BASIC-like languages are a lot more natural for most people. Natural doesn''t neccessarily mean best for a programming language IMO.

---

In a procedural language, I have to disagree. Its good in Lisp, because its functional. But in C or Java, you''re already breaking your algorithm into statements. The faster each statement can be translated too and from your pseudocode, the better.

CM

Common Lisp is a multi-paradigm language just like C++. They can both support imperitive programming, functional programming (though C++ to a lesser degree), OOP, and several other methods.

They do handle some aspects of different paradigms a little differently though.

I like my HP dammit >_<

The uniformity of (Lisp)-like languages makes them difficult to read quickly IME, indentation and bracket-balancing text editors be damned. You just don''t have the same kinds of reference points.

I would much, much rather have operator overloading in Java 1.5 than "generics". C++ templating still gives me nightmares. Operator overloading actually makes things look clearer in the right hands.

Strings certainly should be an object type. std::string is an object in C++, with methods like .c_str() and so forth, and it''s very nice to have. The immutability is annoying, but that''s what StringBuffer is for. What *really* annoys me is that there aren''t mutable versions of Integer, Character, etc.

Oh, I also hate how "char" is a numeric, fixed-size type, and not only that it''s the *only unsigned integral* type.