A Look at Java 3D Programming for Mobile Devices 196
An anonymous reader writes "IBM developerworks is running an article that describes the Mobile 3D Graphics API and introduces you to 3D programming for Java mobile devices. Sony's PSP has shown the graphics power you can put into a mobile device and mobile gaming. Although the average mobile phone is technologically behind this specialized game machine, Java seems to be helping to drive the market in a very definite direction."
nGage called... (Score:0, Insightful)
You know what would be nifty instead? A scripting language....
if (received_SMS_number == mom_number and time_of_day > 23.00 and time_of_day 6.00):
sms (mom_number, "I'm still at my friend's house")
Just reminds me (Score:4, Insightful)
Ah, Moore's Law, what isn't practical today will be in 18 months (or 36 months, etc.).
He is a smart guy, he just doesn't have the vision to look out that far into the future.
Bad Idea! (Score:4, Insightful)
This seems like a bad idea to me. Instead of trying to make a phone compete with a gaming console they should be looking for more innovate things that they can make phones do.
How much would a phone.. (Score:5, Insightful)
And queue the Java-being-slow comments... (Score:4, Insightful)
Re:How much would a phone.. (Score:3, Insightful)
Explain this to me (Score:4, Insightful)
Re:A very definite direction (Score:3, Insightful)
Java is in no way driving 3D games development - on mobile platforms or otherwise, this is just a bizarre article. It comes as no surprise to me the IBM/SUN employee who submitted this article wishes to remain 'anonymous'.
There are currently zero mobile Java games available that compare even remotely favourably to a decent GBA title, let alone with any titles available on the DS or PSP.
Typically, the frame rates are awful, the interfaces are not responsive, the sound is often out of sync and of poor quality (as are the often tiny sprites). Even something like a Java based chess game with a slow and unresponsive interface can be frustrating to use.
Mobile devices are constrained by battery life, which in turn means they tend to be fairly modest devices. They simply don't have time to waste on a JRE and titles need to be heavily optimised on a per-platform basis, even for very simple games (because games software in particular has to be responsive, or users will very quickly become frustrated).
Of course if your writing reasonable code in the first place, it shouldn't be all that difficult to keep it portable (something that most game developers manage without too much trouble anyway).
Java! That's the answer! (Score:3, Insightful)
There are so many people (me included) who would love to be able to program for the PSP, but they won't open it up for various reasons (fear of piracy, mostly).
So why not give people a Java sandbox (J2ME would be fine) to play in? That way they can make games and other fun things, but they won't be able to use it to boot pirated games off memory sticks and such (unless they REALLY mess up the JVM). Seems like a perfect solution.
They sold the Net Yahorzee, why not give us this? Download a copy today (tied to the PSP's serial number to prevent copying?) for only $20! They'd make a fortune.
Re:3D Handsets (Score:4, Insightful)
On the one hand, we have the PSP - an ultra-slick, hardware-accelerated, single-purpose device which is excellent at playing action games.
On the other, we have almost-ubiquitous Java handsets (here in Europe, anyway), with enough processing power to run simplified versions of the console games. That is a niche begging to be filled.
The hardcore g4merz will have a PSP. And probably a GBA, a GBM and an Atari Lynx just in case. Everyone else will have a cellphone. They are very different markets and will have very different expectations and different needs.
Re:A very definite direction (Score:4, Insightful)
They don't have to "drive" 3D games development, they just have to be fun enough that people with mobile phones want to play them.
There are currently zero mobile Java games available that compare even remotely favourably to a decent GBA title, let alone with any titles available on the DS or PSP.
Oh, I agree DS or PSP games are more fun, it would be strange otherwise since they are dedicated gaming machines. Thing is, there are many millions more mobile phones sold. Not all people are hardcore gamers who are willing to pay for one of those devices. Some just want a few minutes of diversion while on the bus. A Sudoku puzzle or similar. And this article shows that these games are getting better and better.
Typically, the frame rates are awful, the interfaces are not responsive, the sound is often out of sync and of poor quality (as are the often tiny sprites).
That is just FUD. I have played plenty of fun and responsive Java games. Still, it must be said that more developers should focus on making addictive puzzle games or similar rather than action games. As you point out, the processor, the screen and the input possibilities are by necessity rather limited.
Re:Just reminds me (Score:4, Insightful)
Ease of development, maintainability and porting are also forms of technological superiority, and in this case perhaps more important than pure performance?
Re:Just reminds me (Score:4, Insightful)
Java was designed for embedded products. [wikipedia.org]
Or the past, apparently.
Re:Hello World (Score:5, Insightful)
Re:Hello World (Score:5, Insightful)
I know how to use plenty of languages, I learn new ones all the time. I wasn't just guessing the execution speed of Java, I was speaking from experience. As for the test code you use to show Java is slower, that's a huge mistake. You've composed a test which is ideal for C++ to execute. That's like proving a jeep is faster than a porche by doing time trials in offroad terrain. Given a more abstract problem than "Go through these loops a billion times", the solution in Java wouldn't even resemble the equivilant solution in C++. You can't approach the same problem identically in both languages, if you do, you're not writing Java code, you're writing C++ code in Java.
There's a lot of utility code that would be necessary in a C++ program that's not necessary to perform the equivilant task in Java. Each language isn't just different syntax, you need an entirely different way of thinking. Trying to port a solution line for line into a different language is senseless.
Re:Hello World (Score:2, Insightful)
I agree with most of what you're saying but I do think that rallying
around a standard also has it's advantages. That's why C became such
a reference point for scientific and engineering software. It works
and it's ubiquitous (available everywhere). Java is similar. It has
many problems too (like every language) but if Computer Scientists
and programmers rally around Java as a language of choice it will
continue to improve and allow us even more freedom in where and how
it is used.
BTW I ran your little test in Java and C. I was incredibly close to
your number in Java (1 min 20 sec) but nearly identical code in C:
#include
int main ()
{
long double t = 0, lp, ilp;
for (lp = 0; lp = 0; ilp --)
{
t ++;
}
}
}
Compilied with gcc it took 2 minutes and 30 seconds to run!!
Go figure.... If you change back to just a double (Vs long
double) it finishes in 1 minute 10 seconds. So I think you
have to admit that just saying Java is slow is a tremendous
over simplification.
Re:Hello World (Score:4, Insightful)
The test given doesn't bring into a single feature that's unique to any language. It tests the execution speed of a loop and the increment/decrement of primitive types which is likely to be equally fast/slow in any language as it just comes down to the processor speed. To test Java as a language, a good start would be testing the creation of objects, allocating and deallocating arbitrary amounts of memory, and calling random methods on randomly sized objects.
Objects and memory management is where Java shines. Many tests that compare Java's speed to C++ speed tend to focus on areas where C++ shines and Java performs poorly, like resizing containers.
One reason Java really shines with objects is that Java doesn't run into the performance overhead incurred by copy constructors. There are a lot of situations in which Java will perform more slowly than C++. There are also situations where Java performs better. The end result is that Java's performance and C++'s performance can't be compared based on a single test. Many people craft a single test and based on the results of one test they brazely declare that Java is always slower. If, one day, it was 100 degrees in NYC, and 90 degrees in Las Vegas, one wouldn't say it's always hotter in NYC. By the same token, you can't compare language performances with a single test. The only real way to compare the performance of two languages is to actually spec a real-world program and have two teams go about building it in different languages.