A Look at Java 3D Programming for Mobile Devices

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."

Comments

nGage called...

[Anonymous Coward]

...it wants its bloat back.

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")

Re:nGage called...

[sinserve]

That would have to be a *very* safe language, for values of "safe" not considered before, like restricting I/O. You don't want a bug in there to cause an SMS or a phone call DoS.

Hello World

[deltalimasierralima]

Wow! Finally I can code 'Hello World' in full 3D glory with realistic 3D shadows!

Re:Hello World

[linumax]

Wow! Finally I can code 'Hello World' in full 3D glory with realistic 3D shadows!

Well, since it's written in Java you'd better code 'Hello judgement day' , you must have heard of Java running soooo fast!

Re:Hello World

[Jekler]

It's a common myth that Java is slow. Modernly, Java applications are (on average) only 10% slower than an equivilant C++ application. With appropriate optimization, that margin is even smaller. Even then, when it comes to 3D rendering, the application is usually running at the speed of the hardware, with the Java code not really even coming into play. In a 3D environment you could say the performance margin can be less than 1% difference.

Re:Hello World

[Anonymous Coward]

10% becomes quite a bit when you're on slow platforms, like the current crop of mobiles.

ps. the 3d rendering on most mobiles is not on the hardware, and I really dont trust that the java libraries are faster than my handcoded polyfillers.

Re:Hello World

[flithm]

Actually these days it's a myth that java isn't slow.  Especially for things like games which are very processor (and math) intensive, java is EXTREMELY slow.  Anyone who does a lot of programming (other than app programming, ie games, scientific, etc) knows this.  It's really only the java zealots (who don't understand that every tool has its purpose -- including java! but also including other languages -- probably because they only know one language) who push this idea, when it simply isn't true... it never has been, and never will be, it's simply not possible (without an instruction set that directly implements java bytecode, or a truly optimizing native java compiler -- and no gcj does not fit this bill).

Don't believe me?  Try the following experiment:

public class jprog
{
        public static void main (String args[]) {
                double t = 0, lp, ilp;
                for (lp = 0; lp < 1000000000; lp ++)
                        for (ilp = 5; ilp >= 0; ilp --)
                                t ++;
        }
}

Obviously it's slightly akin to the bogomip, but it does illustrate an important point.  All this does is do some floating point math, in a loop, 5 billion times.

Quickly port this code to C, compile with gcc, and on my machine its execution takes 16.8 seconds.

Compile and run this code with Sun's latest java release and it takes 1 minute 18 seconds.  That's approximately 1/5 the speed of C!

Java is just plain really really slow.  It's not so bad if you're just doing GUI stuff, or simple application programming since that's not processor intensive, and yeah I could see a general slow down of 10% being reasonable.

But for anything else, especially games, java is not a smart choice.

Please java zealots stop spreading lies.  Take the time to learn many languages, and stop trying use a single tool for every purpose!  Java is great for certain things, but execution speed is not one of them.

Re:Hello World

[Anonymous Coward]

Modernly, Java applications are (on average) only 10% slower than an equivilant C++ application. With appropriate optimization, that margin is even smaller. Even then, when it comes to 3D rendering, the application is usually running at the speed of the hardware, with the Java code not really even coming into play. In a 3D environment you could say the performance margin can be less than 1% difference.

Wow, thank you for telling me that! As I'm feeble-minded, I won't even think of asking for any citations to support these quite remarkable claims - I'll take the unsupported word of a random person on Slashdot for it, yes sir!

Hint to moderators: wild claims are not "insightful". Claims backed up with hard facts might be. I see no hard facts.

Re:Hello World

[Anonymous Coward]

Oh look, another amazing 4 line code example doing oh so real things to PROVE java is really slow! And on slashdot no less! You're fucking brilliant. Funny enough, IBM had something to say just recently about java's speed too, and it seems they took a slightly different conclusion: http://www-128.ibm.com/developerworks/java/library /j-jtp09275.html?ca=dgr-lnxw01JavaUrbanLegends

And by the way, all those phone games, in that billion dollar industry of phone games, what do you think they run on? Thats right, java. And do you see consumers throwing their phones in disgust of the slow speed? No? Gee.

Re:Hello World

[Jekler]

I'm far from a Java zealot. I'm a programmer, language is an insignificant issue. The fact is, I've done most of my programming in C++. I avoided Java for precisely the reason that I thought it was much slower, and as it turned out a lot of my assumptions were wrong. It's even fast enough for 3d games, like Megacorps Online http://www.megacorpsonline.com/game/

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

[Anonymous Coward]

    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

[PierceLabs]

Go to www.lwjgl.org or puppygames.net. Play some of these games written in Java running on hardware accelerated OpenGL.

Proof is in the real-world applications, not arbitrary micro benchmarks.

Re:Hello World

[Jekler]

Sources http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html

There's literally tens of thousands of sources on the internet about java's execution speed and the myth of it all. Do some friggen research, what do I actually care if you believe it or not?

People wildly claim that Java is X amount slower than C++. I'm pointing out that it's not true. I guess the most mind boggling thing to me is that everyone is so skeptical about it, like if Java's execution speed approached the speed of C++ armageddon would happen.

Years ago, no one believed that the speed of C could ever approach the speed of assembly, but it has. It's come within about the same 10% margin that Java has come to C++.

I could see all the skepticism if someone was saying that Java was better. Fact is, it's no better or worse, it's just another language. Another language that happens to not be as slow as the majority think it is.

Re:Hello World

[jmacleod9975]

I am not for or against java or c++. But just out of curiosity, why is that test more suited to c++ then java. If you had to do a lot of the same type of calculations in a loop, like you might have to in scientific computing, it seems like at some point you have to do the calculations.

How would you setup the test so it was favored for java?

Re:Hello World

[3rdParty]

Java is slow. End of story.

Sure, after you factor out all the different ways Java is slow, you can come to the conclusion that Java isn't slow, but then, you don't have to factor out those cases for C, C++, hell, even Basic.

Taken as a whole, in every case, from start of execution to exit, Java is slow. So many, many people, who know a thing or two, fail to see any reason to code software where speed and performance is paramount, in Java.

Java is slow, which is why you will never see a triple-A game title coded in Java.

Re:Hello World

[Anonymous Coward]

So, you wnt to say that Java programs are quick always when the actual execution is done outside Java. Well, I think everyone will agree that hardware 3d accelerators will run quick enough, but what does it have to do with Java, you can use PHP as a scripting interface to hardware open-gl renderer and say - wow! php's cool, and so quick!!

Re:Hello World

[flithm]

You may be speaking from experience... but you've done nothing other than guess when you talk about 10%. I've given you empirical proof that java is significantly slower for doing calculations.

The example I provided was, in no way, tailored to C++. If you're doing scientific computing, or graphics programming you can't get away from doing tight loop calculations. Many (ie almost all) of the graphics algorithms are O(n^3) or higher!.

You obviously ARE a java zealot or you wouldn't be outright lieing just to try to prove your point.

Java is significantly slower. That's all there is to it.

Yes you can do everything you want in java, and yes it will run fine, but there's a reason you'll NEVER -- EVER see a top commercial game written in java, it's because the performance simply isn't there.

If you want performance you gotta go lower level.

If you want something else, such as fast development, nice libs, easy GUI creation, handy built in garbage collection, and some of the cooler java API elements such as the reflection API... then java is a great choice!

Just don't go kidding yourself it's anywhere close to the speed of low level compiled code.

Re:Hello World

[Jekler]

I guess you're right, we'll never see a commercial game programmed in java. Unless you count:
Chrome
Law and Order II
Kingdom of Wars
Alien Flux
Star Wars Galaxies
Pernica
Command & Conquer Attack Copter
Roboforge
Runescape
Wurm Online
You Don't Know Jack
Vampire: the Masquerade Redemption
Source http://fivedots.coe.psu.ac.th/~ad/jg/ch00/ch00.pdf

Although not all of those are completely coded in Java (some of them use Java and C++ both), many of them are.

Re:Hello World

[Jekler]

I apologize, what I said could be wrong. The test may not be more suited to C++ than Java. Truthfully, a short test like that could favor either language or neither. It's too small of a test to be a significant benchmark of a language. If you could test the performance capabilities of an entire language with half a dozen lines of code, no one would ever create an entirely new language until they found a way to execute 4 lines of code faster.

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.

Re:Hello World

[Anonymous Coward]

You're assuming, for no good reason, that Java applications run in a VM. I disagree with your benchmark anyway - one glaring flaw is that you timed the whole application load and execution instead of the actual loop, and you're deliberately using the extremely rare case of unrollable floating point loop indicies to discriminate between static and dynamic compliation. But in any case it's perfectly possible for Java to exceed the speed of C++ virtually all the time by using a native complier such as the excellent Excelsior JET).

Re:Hello World

[da]

Hehe...
$ javac jprog.java
$ time -p java jprog
real 29.70
user 29.62
sys 0.03
$ cc -o jprog jprog.c
$ time -p ./jprog
real 55.46
user 55.35
sys 0.02
What was your point again?

Re:Hello World

[Anonymous Coward]

The example I provided was, in no way, tailored to C++. If you're doing scientific computing, or graphics programming you can't get away from doing tight loop calculations. Many (ie almost all) of the graphics algorithms are O(n^3) or higher!.

You know you CAN in fact compile Java to native binary, if you are willing to sacrifice OS independence through the JVM?

Yes you can do everything you want in java, and yes it will run fine, but there's a reason you'll NEVER -- EVER see a top commercial game written in java, it's because the performance simply isn't there.

Puzzle Pirates

Re:Hello World

[Anonymous Coward]

Took your advice and tried your experiment. Compiled a simple C version with gcc 3.3.3. Results for the C version 2m57s. Java version 1.4.2 b03 ran it in 2m44s. Seems like what I'd expect, the hotspot Java version was comparable to the C version.

And I consider myself more of an aficionado..

Re:Hello World

[Anonymous Coward]

I am wondering since this code does not look at time for the JIT to start... and since C++ would already be optimized for this... a better test would be to put a

System.out.println("Start: "+new Date(System.currentTimeMillis()));
System.out.println("End: "+new Date(System.currentTimeMillis()));

at the start and end of the main functions... since the main overhead time there would have been due to the JIT starting and stopping. Do that and give time estimates... just curious what the results would be... your results are biased towards a precompiled solution.

Re:Hello World

[Anonymous Coward]

Hehe...
$ javac jprog.java
$ time -p java jprog
real 99.70
user 99.62
sys 0.03
$ cc -o jprog jprog.c
$ time -p ./jprog
real 15.46
user 15.35
sys 0.02
What was your point again?

Re:Hello World

[kaffiene]

You're either lying like hell, or something is severly fucked up with your system. I happen to have both Netbeans (jdk1.5) and MSVC (M$VC 6) open at the moment so I popped in your code. - actually here is the exact code i used:

Java:

long end,start = System.currentTimeMillis();

double t = 0, lp, ilp;
for (lp = 0; lp = 0; ilp --)
            t ++;

end = System.currentTimeMillis();
System.out.printf("Execution time %f", (end-start)/1000.0f);

C++

long end,start = GetTickCount();

double t = 0, lp, ilp;
for (lp = 0; lp = 0; ilp --)
            t ++;

end = GetTickCount();
printf("Execution time %f", (end-start)/1000.0f);

Results:

C++ (no optimisation) 97.57 sec
C++ (maximise speed) 25.37 sec
Java (no settings at all) 21.41 sec

Your post is utter FUD

Re:Hello World

[gral]

Where Java really shines is in its ability to mix C++ with Java through JNI, so if you just have to drop to that lower level for calculations like this, you can still do it, and enjoy the other benifits still.

Re:Hello World

[flithm]

You realize your results are impossible.

Try again next time.

Re:Hello World

[Anonymous Coward]

g++ -O3 -march=pentium4 jprog.cpp -o jprog
time ./jprog

real 0m6.306s
user 0m6.288s
sys 0m0.020s

javac jprog.java
time java jprog

real 1m44.913s
user 1m35.582s
sys 0m0.396s

Re:Hello World

[kaffiene]

WTF????

You lying piece of shit - I've just compiled the fucking results and run them right now. There are two other people who have posted similar results - are they lying too?

Fuck you and fuck the horse you rode in on you mother fucking slashbot moron. I've been coding in C for two fucking decades and I'm not about to take shit from know-nothing newbies like you.

Re:Hello World

[kaffiene]

At least three people have replied to your original post showing that when they run the test Java is faster.

You going to conclude that you've proved Java faster now?

Re:Hello World

[kaffiene]

There have now been three replies to your benchmark showing that it runs faster in java than c++.

YOU are the Zealot newbie.

Re:Hello World

[kaffiene]

WTF is up with modding the parent as "Flamebait"?

It's benchmark numbers.

How can actual timings be Flamebait? I've run the tests on windows and gotten similar results.

Moderators using mod points to avoid FACTS they don't like should not have mod points. That's just abusing the system.

Re:Hello World

[kaffiene]

I got faster results from Jdk1.5 on windows (21.4) versus Visual C++ v6 (maximise speed) (25.317)

Even including the JVM start up speed, java was faster.

Re:Hello World

[iotaborg]

Java is most quite *not* the right choice for a programming language for any sort of control system application or data acquisition, or similar application. For example, you cannot reliably get time divisions, forget any semi-realtime system. The garbage collector is what kills this mostly, as it randomly pauses execution of code; memory is highly controlled in C, giving more control, and yes you can force garbage collection but that slows down execution.

Java has its own applications, very easy to make complex code (compared to most APIs in other languages), but it definitely isn't for speed.

Re:Hello World

[Profound]

Are you joking? The JNI call overhead is extremely large which means that any gains through faster lower level code are lost, unless you are performing masses of computation at once.

Plus of all the cross language linking I've seen (C++/Python/C/.NET) it is by far the ugliest to write.

The folks who designed Java are almost religious in their beliefs. I would not be suprised if they made JNI deliberately ugly and slow to discourage people to not to write in Java, the language they spend so much on marketing and selling.

Re:Hello World

[Anonymous Coward]

try:

http://mobile.processing.org/

see samples of awesome stuff you can do with Processing (p5) language here:

http://www.processing.org/exhibition/index.html

- analogAI

"Processing is an open source programming language and environment for people who want to program images, animation, and sound. It is used by students, artists, designers, architects, researchers, and hobbyists for learning, prototyping, and production. It is created to teach fundamentals of computer programming within a visual context and to serve as a software sketchbook and professional production tool. Processing is developed by artists and designers as an alternative to commercial software tools in the same domain."

Re:Hello World

[Profound]

The hardware may be fast (lets even assume that the video card is never the bottleneck anymore) but it can only render as fast as the application can send data to it via the bus.

To maximise 3d throughput the application code must send the card data as efficiently as possible. This involves heaps of techniques that Java can do too, but also techniques like vertex buffers, packed data formats (ie pointers to raw memory with nicely aligned data the video card can just plow through)

-JVM uses network byte order, not what is on the local machine, which means you can't just chuck the video card a pointer to a lot of floats.
-You don't have pointers anyway.
-Garbage collection can be more efficient than manual collection IF ANY ONLY IF the amount of usable memory is massively (5-10x) larger than the applications memory. Console/mobile phones etc only have =64mb
-Garbage collection is non-deterministic, and must "stop the world" which ruins pipeline performance. Ie the graphics card may be starved of data when the gc fires, meaning the graphics card must wait on the cpu too.
-Collections/containers (can't build a large app without them) must cast back from object. Dynamic casts are slow and will always be slow. Templates don't have this problem, autoboxing and generics HIDE this problem.
-Small devices often don't have JITs

Just as a thought experiment, consider what the SNES and GBA did with C and asm, and compare that to Java games on the much more powerful mobile phones of today.

Re:Hello World

[Profound]

One reason Java really shines with objects is that Java doesn't run into the performance overhead incurred by copy constructors.

With C++ you can refer to objects 3 ways: pointer, reference and value. 2/3rds of these do not have the copy constructor overhead.

Re:Hello World

[Anonymous Coward]

This is one of the most ridiculous posts I've encountered in the whole time while lurking around here and it's actually the first time I even post here (been lurking here for some years). So I guess I should congratulate you for that. Please don't babble some utter crap when you clearly have no slightest clue of how computers or programming work (not to mention compilers & JIT/Hotspot which are essential things to understand in your sad benchmark). Also you have probably no idea what real-life applications mean. This is really the most pathetic Java bashing message I've read in a looong time - and boy have I read many. I'm very sorry but I honestly don't see it's worth the effort to try to explain all the x+y things wrong with your -- erm -- benchmark, since you clearly don't have a grasp of the basics.

And now that you've done your Ultimate Java Performance Benchmark and came to conclusion that Java is slow (concurrently, rendering all previous real-life tests, games & benchmarks redundant - you're the Ultimate Programmer afterall?), I suggest you go e-mail these people as soon as possible and tell them what you're doing aint really possible:

Oh and be sure to include the code snippet aka "Java vs C benchmark by Tim" in the e-mails, they surely get good laughs :)

- www.tribaltrouble.com
- www.puppygames.net
- http://www.agency9.se/products/agentfx/
- http://192.18.37.44/forums/index.php?topic=9933.0
- http://home.halden.net/tombr/squareheads/squarehea ds.html
- http://www.auriga3d.org/pictures.html

Now after checking the links, you do realize they make you look like a complete idiot when you say Java is slow and can't be used in games, don't you? If you don't, you're beyond help.

I was _completely_ certain your benchmark post was a troll.. until I saw that you actually had your website in the profile. By god did I burst into laughter :) If you're hired by any software company I truly feel sorry for your boss :)

Re:Hello World

[jericho4.0]

You people are fucking amazing. Have you ever actually wrtten an algorithim in C and Java? Seemingly not, but you did read an article once that said Java is (on average) only 10% slower than an equivilant C++ application.

Re:Hello World

[jericho4.0]

And why did they mix it with C++? Was it for the better maintainability? Or portability? Ooo! I know! Was it generators?

Re:Hello World

[jericho4.0]

Yeah, cause the last thing people need speed for is floating point math!

Oh, wait....

Re:Hello World

[Anonymous Coward]

You guys do realize that Java has a Hotspot compiler that compiles the code to native code at runtime? This results only to slower startup time as the code is first interpreted, but in theory to the same performance as C/C++. Java's security systems and garbage collector naturally eat some CPU power but it's a totally irrelevant amount. GC (if a problem) is usually tuned for each application by many VM flags available. Some things are faster in Java than C/C++ because it has more information available on runtime than statically compiled languages. This is unbelievably hard concept for unbelievably many people to understand. For example, allocation in Java is a lot faster than in C. This is covered in already posted Brian Goetz's article, but I doubt anyone actually reads anything in here. Afterall if you did, you couldn't come here anymore and spout that Java is slow, right?
Finally Mustang (Java 6.0) will introduce an advanced transitive escape analysis which, when combined with Java's heavy inlining, is gonna provide a big boost to Java's general performance.

You do understand that you're just making yourselves fools when you keep stating that Java is slow. It proves nothing else than that you're inadequate Java programmers or are using the wrong libraries/classes. And if you can't google for the serious performance comparisons, benchmarks or real-life tests, you are simply stupid people or casual newbie programmers who think they know everything about everything (a good example is the guy who posted the benchmark above). And dont take it personally, this planet is full of stupid people.

Another thing that people don't seem to understand, is that Java has many slow classes/libraries but it has nothing to do with language being slow or fast. Performance isn't number one priority in Java API design (not that it's low priority anyway), but it seems to be very high priority in the VM/language design - given what a blazingly fast VM we have today.

[quote]
Wow, thank you for telling me that! As I'm feeble-minded, I won't even think of asking for any citations to support these quite remarkable claims - I'll take the unsupported word of a random person on Slashdot for it, yes sir!
[/quote]

Why should we care if you have no basic understanding of how CPU & GPU work? EVEN IF Java would be significantly slower than C/C++ (which is not true), the fact is that most games nowadays are GPU-limited anyways. Understand now?

[quote]
You people are fucking amazing. Have you ever actually wrtten an algorithim in C and Java? Seemingly not, but you did read an article once that said Java is (on average) only 10% slower than an equivilant C++ application.
[/quote]
Alright, you clearly have, so please post what algorithms you had in mind and how do they matter in real-life applications (and in what applications, game-specific?). Implementation would be very nice to see. What of the Java's library classes did you use? How do I have a feeling in my gut that Im not getting a response from you anymore - other than "I'm not wasting my time"?

Re:Hello World

[fcgreg]

I've given you empirical proof that java is significantly slower for doing calculations.

Wrong. You've given a possible test-case, unvalidated except in one test (yours), that MAY show that C/C++ is better for a specific type of calculation operation -- and a very small one at that. If you think THAT is emperical proof, I think you need to go back to Science class.

Furthermore, go take a look at some benchmarking studies. If you tried to pass off your little loop as anything demonstrable or emperical, you'd be laughed right out of the building.

You obviously ARE a java zealot or you wouldn't be outright lieing just to try to prove your point.

Wow, in only two posts you've already resorted to personal attacks and name-calling. By the way, the only one around here that sounds like a zealot is you, I'm afraid.
Te nosce.

Java is significantly slower. That's all there is to it.

Wow again. There's a solid, reliable, fact-based statement if I've EVER heard one!

By the way, since you're posts are so poor and seem to promote nothing other than baseless, argumentative discussion, I've formed the opinion that you are a troll. Goodbye now, bridge-dweller.

Re:Hello World

[ultranova]

Quickly port this code to C, compile with gcc, and on my machine its execution takes 16.8 seconds.

Compile and run this code with Sun's latest java release and it takes 1 minute 18 seconds. That's approximately 1/5 the speed of C!

I ported this to C, and compiled with gcc -O3. I got the following timings:

• real 2m3.708s
• user 2m2.789s
• sys 0m0.601s

Then I ran the original Java code, and got the following:

• real 1m57.178s
• user 1m56.247s
• sys 0m0.610s

In other words, Java won over C code. As an interesting side note, C was much faster than Java when I removed a 0 from the outher loop of both programs.

The version of GCC was (gcc --version) "gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)".

The version of Java (java -version) was:

java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode)

I tried to post the C translation I made, but Slashdot's lame lameness filter rejected it :(. Anyway, I didn't touch the loops, I just removed the class definition (first, second and last lines) and changed the main function to "void main()". I also added block start- and end braces to both for loops - they might not be neccessary by syntax, but I've wasted enough time trying to solve weird bugs just to realize that I and the compiler disagree on where the blocks begin and end.

So I have to conclude that Java is, at least on my machine, as fast as C, if not faster in some cases. And, since it is definately easier to program with it, I'm going to stick with it for now.

But for anything else, especially games, java is not a smart choice.

You seem to be under the impression that all the games are fast and furious action games where the CPU is constantly taxed at its very limit and any reduction in framerate will lead to an instant death. However, even if Java was as slow as you claim, it would still be good enough for turn-based strategy games and puzzle games. Not everything needs to be real-time, not even all games.

Re:Hello World

[gral]

I ran the tests with the double loop on my machine, and depending on what else was going on on the system, my 1.8 Ghz system ran Java in 13seconds-1:30 and ran C++ in 12-1:15. This is on Linux with Sun Java 1.5 and GCC 3.2

There are several options available JNI being one. Even without JNI though it seems to me that the code runs pretty much the same amount in my very unscientific tests, using time.

Re:Hello World

[Profound]

For a bit of fun try running the outside loop in Java and the increment in JNI! You might want to leave it overnight... :)

Re:Hello World

[Anonymous Coward]

Are there any people who have actually had to make games on java phones who havn't been frustrated buy the lack of speed and inflexibility?

Its interesting reading all the greate things about java and the wonders of JIT and all the tricks that allow java to approah C in speed. Its pretty impressive what some of the JVMs are apparantly capable of. However, it comes down to actually writing a java phone game in practice, for what ever reason, java seems to be the main bottle neck compared to non java programing interfaces.

I'm a little confused about this benchmark. I would have thought a simple short for loop would be the type of thing that JIT would handle fairly easily making it a pretty bad demonstration of the benifits of C++. I get the feeling Java performs better in benchmarks then in the real world.

Here some things that are frustrating with java for games, especially on mobile.

Heap memmory allocation. Allocating memory is slow in both C/C++ and java, however, in C/C++ it is easy to full take total control over managing memory. This alows you to make use of every last drop of memory and avoid doing slow allocations/deallocations. In java is seems to be difficult at times to avoid allocates during the main game loop. No matter how fast java memory allocation is, it is slower then not doing it at all. Also, you end up spending heaps of time debuging heap allocation exceptions in Java.

Stack memory allocation. Java doesn't let you allocat objects on the stack. Obviousy, stack allocations are much faster then heap allocations plus they are also much better for cache. I did just read that some JVMs are now smart enough to detect this in places and optimize this wich sounds cool, but I wouldn't be to hopful about this working well all mobile handset JMVs and I wouldn't want to rely on it when it really matters.

Code size. Java doesn't seemed to be designed with the thought that you might need to make very tiny distrabutions which is exactly what is generally required with mobile phone over the air deliverable games. I supose you can always hand assemble if you want but I don't supose the JIT compiler will like it too much.

Overhead. Java takes up a lot of a phones resourses, notable memory and given the already mention memory problems, this is frustrating.

Hardware access. Java on phones seems to move you further away from the hardware, just adding an extra layer of function calls ontop of everything. Isn't the java 3d stuff just a wrapper for openGL after all? How is an extra layer ment to be fast.

Memory access. In games, memory access is typically one of the bigest bottle necks. Drawing to a sprite, looking up arrays. Java has to check if you go out of bounds on arrays which means lots of ifs all over the place. Isn't any algorthim where you are processing a large buffer is going to have to have a heap of safe java memory array bounds checking. How well does a java compare to C/C++ in a random data access from an array benchmark? This can be pretty critical for high performace code in games.

JIT. JIT jumps in every time you go down a new branch in the program and this can cause serious pauses in some situations.

Portability. lol. You have to do lots of porting. That must mean it is very portable. Not that C would be any better then java here.

When making a game on a limited, even if java was only 10% slower, its 10% too much slower. When you come to optimize, you will take every 1% you can find.

There has been a fair bit of use of Java on quality high end games on PC and consol, but I'm assuming this is mostly scripting which is typically pretty insignificant. There is a good chance that they actuall write there own JMV with out JIT and that it is slow as all hell, but they don't care because it is just a bit of scripting and is negligable in the real time performance of the game. Perhaps some groups have gotten a bit more involved. Who knows.

Anyway, in my opinion, the main thing that is holding back the games industry

Re:Hello World

[danmoore22]

really, don't read this if you have an aversion to windows.
right, i'm getting to be an old fart (and this is going to talk about some windows and worse...) and i can remember loads of up-their-own-**** C++ guys banging on about how slooooow VB was, erm mid-90s, when all it was doing was windows dialogs, all video blits really.
suffice to say they had lots of fun sending MFC WM_OPEN_THE_WINDOW_WITH_A_BLEEP messages to some grim looping CPU hogger while some dumbass VB programmer would type formHello.open() or whatever... the VB guys were a bit lost with the multi-threading but actually got a lot more work done.
end of the day, if you wanted to be precise about shit, you didn't use VB. if you want to be really fast about shit, don't use java. but if you ain't a fricking superstar, don't get hung up on C++ (since when is complex good? oops...) because you're probably screwing things up yourself much worse than any language ever did... most of us just aren't good enough, use what's simple and availabe, imho.
thing is, there's a frickin LOT of people with java compatible phones, on them all the time, there's a lot to think about beyond computing perfection here...
sorry, had beers, i just re-read and that was rubbish, but i'm not a bad person, honest,
i use linux everyday,
i think google is broken,
um, whatever else is cool,
dan.

Re:Hello World

[DrunkBishop]

C Code
void main (void)
{
        long end,start = GetTickCount();
        double t = 0, lp, ilp;
        for (lp = 0; lp < 1000000000; lp ++)
                    for (ilp = 5; ilp >= 0; ilp --)
                                t ++;
        end = GetTickCount();
        printf("Execution time %f", (end-start)/1000.0f);
}

Java Code
public static void main (String args[])
{
        long end,start = System.currentTimeMillis();
        double t = 0, lp, ilp;
        for (lp = 0; lp < 1000000000; lp ++)
                    for (ilp = 5; ilp >= 0; ilp --)
                                t ++;
        end = System.currentTimeMillis();
        System.out.printf("Execution time %f", (end-start)/1000.0f);
}

Sun Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
>java Speed
Execution time 102,223999

Java HotSpot(TM) Server VM (build 1.5.0_04-b05, mixed mode)
>java -server Speed
Execution time 23,075001

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
>Speed.exe
Execution time 66.781000

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
>SpeedOpt.exe
Execution time 17.609001

I'm running it in a Celeron 2.4Ghz 512MB Ram.
Only in server enviroments Java gets close to C.

Re:Hello World

[PierceLabs]

Yes, because we all know that the Java application is spending most of its time rendering :rolleyes:

Sony Ericsson phones

[wertarbyte]

The developer pages of SE offer Mobile Java 3D Tutorials as well: http://developer.sonyericsson.com/site/global/tech support/tipstrickscode/mobilejava3d/p_mobilejava3d _tips_new.jsp

Re:Sony Ericsson phones

[oever]

And here's the perfect game for it.
Now only if I'd have a phone that would support 3D java, I'd port it and make it available for free.

Donations are welcome. :-)

3D Handsets

[seanellis]

Quite a few handsets already support M3G, among them the Siemens S65, Motorola E680, E1000, V980, SonyEricsson V800 and K750i, and the Nokia 6630 and 6680.

M3G is a lot lighter weight than Java3D, has high and low level APIs, and has its own compact file format for efficient packaging of assets.

I've been developing M3G technology, both engines and games, since day 1 (I was our company's representative on the expert group), and I am happy that Slashdot has at last highlighted it.

If you think retreads of "Mr. Do" and "Snake" are going to cut it in the Java space from now on, think again. You might like to look at Superscape's site for a taste of the kind of 3D games that are already out there.

Developers might also want to visit Benhui.net's 3D Developer Forum.

Re:3D Handsets

[Agret]

There is just no comparison between the PSP and a mobile phone (using your links and the psp comparision in the original summrary)

http://www.superscape.com/games/title.php?SB_3D,sc reens Phone basket ball game with "amazing 3D"
http://www.1up.com/do/media?cId=3142148 PSP Basketball game

Re:3D Handsets

[mwvdlee]

OMFG! 3D Extreme Bowling. That is just SOOOOO much better than Mr. Do and Snake.

Seriously, these games look like something a Sega Genesis would be able to do.

IMHO, the only games that really work on mobile phones are games which do not require any timed action, because the controls on phones just totally suck! This still leaves a lot of genres like RPG's, turn-based (and perhaps slow real-time) strategy games, puzzle games, adventures and board games, sims (think tamagotchi/nintendogs), yet we see VERY little of those. Odd, considering the vast majority of phone users (even the fanatical phone users) are not typical gamers with typical gamer tastes.

Re:3D Handsets

[dreamchaser]

Odd, considering the vast majority of phone users (even the fanatical phone users) are not typical gamers with typical gamer tastes.

I don't know what you're smoking but I want some! Every 'typical' gamer I know has a mobile phone, and many of them are also into games on their phones.

Re:3D Handsets

[Tim Browse]

If you think retreads of "Mr. Do" and "Snake" are going to cut it in the Java space from now on, think again. You might like to look at Superscape's site for a taste of the kind of 3D games that are already out there.

Looks like poorly disguised retreads of Qix are fine, though?

Oh wait, it's got a hot girl in a bikini in it! Feel that innovation! Tssssssss!

Re:3D Handsets

[seanellis]

The comparison with the PSP was in the original link, not my post. These are very different games on very different platforms.

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:3D Handsets

[somersault]

I'm a gamer, and my last phone didnt even have games.. when they got Doom on mobiles I was pretty impressed, but I wont actually start playing games on them till they're around Quake level. I've thought the same thing about gameboys, which is why I've only just bought a DS - because it can handle a decent level of games

Re:3D Handsets

[mwvdlee]

Yes, I know most gamers have mobile phones.

Did you also realize that practically the rest of the civilized world also has mobile phones?

Gamers are but a small percentage of the mobile phone users.

Especially when using "gamer" in the popular interpretation as one who primarily plays games in the popular (racing, FPS and sports) genres.

I consider a fanatical phone user, a person who will frequently use SMS, MMS, WAP, built-in cam, built-in MP3 and in general know more than the manual does about the phone. By definition, these are people who are more "on-the-road" than a typical gamer and thus less likely to be a gamer. Apparently conventional popular game genres did not attract them enough to shift from being a hardcore phone user to becomming gamers. Logically, this means that such games would not attract them on their mobile phones either.

Perhaps you should refrain from smoking anything for a while, might help you to actually understand what you're reading. ;)

Re:3D Handsets

[glesga_kiss]

I wont actually start playing games on them till they're around Quake level.

Pocket Quake

Or, you could try Quake III, which is pretty new. Only 5fps at the moment, but they are starting to add support for GFX chips, that ought to bring it up to spec.

Not a fan of FPS on the mobile to be honest, mouse beats joypad, and joypad beats phone keypad. Gimmie Tetris on the gameboy emulator, or perhaps Age Of Empires for most of my mobile gaming.

Re:3D Handsets

[somersault]

I also agree about the controllers, but must say that in the demo of Metroid that comes with the DS, the touchpad works very well as a mouse replacement.. obviously not exactly the same, but for fighting computer opponents, or other humans using the same control system it will work great. Thanks for the link to that Pocket Quake site, though what I meant was one that would run on most phones (I'm assuming that Doom was a java version? or maybe it only ran on similar higher-end phones rather than 'everyday' type Java phones). I do love tetris too, though am not much into strategy games, etc, and I guess until phones with dual touchscreens or at least touchpad and screen come out then they're gonna suck for FPSs heh.

Re:3D Handsets

[glesga_kiss]

Mine is a touchpad actually, and the FPS's do use it for control. I'm not really a fan of that approach, perhaps practice is key? Doom, I dunno if it was out on Java, the one I had on my phone was a native binary. Cough cough Windows Mobile, yah, it's MS, but they make the best phone OS unfortunately. It's essentially a pocket computer, not much you can't do on it.

Re:3D Handsets

[somersault]

An actual touchpad that was separate from the screen? Didnt know they had those. I dont think practice is that important, I got the hang of it pretty quickly, though I'm now an old hand at FPSs, been playing CS for 6 years or so.. I agree that Windows Mobile is pretty cool compared to other phone systems, but again I dont have any use for it. If I was a road warrior then I'd maybe consider one, but would more likely just stick with a laptop.. no doubt we'll all end up with some kinda of MS/Linux/Google phone in a decade or two though ;)

Re:3D Handsets

[Anonymous Coward]

There might be plenty of handsets that support M3G but how many of them are able to play a game at decent frame rate? I have yet to see one (4fps just doesn't cut it for me). Or one with a complete, working implementation of the API (it would be nice to, say, know I could use Sprite3D and have it actually work).

Re:3D Handsets

[Anonymous Coward]

I hope you get modded up!

I was somewhat disgusted at the open sexism in those "Miss Reef" puzzles and pinballs. More soft porn to underage guys, yeah, way to go. Innovation indeed.

Re:3D Handsets

[glesga_kiss]

An actual touchpad that was separate from the screen?

Not quite. A section of the screen was set aside for it. Not tried any of the ports recently, might give it another blast, I think it was an alpha/beta copy I tried. Took up a lot of storage space, so it got ditched after the initial "neat" factor had worn off. ;-)

A very definite direction

[dajobi]

Yeah the direction of crummy little Java games - now in crummy 3D!

Re:A very definite direction

[@madeus]

A new way to make EVEN SLOWER crummy Java games indeed! Because playing Rayman at really low res @ 5-10 FPS on the N-Gage was just so much fun, everyone should be able to re-create the experience!

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).

Re:A very definite direction

[LarsWestergren]

Java is in no way driving 3D games development - on mobile platforms or otherwise, this is just a bizarre article.

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:A very definite direction

[@madeus]

And this article shows that these games are getting better and better.

I can honestly say that doesn't ring true for me at all. They've been out for years, and I keep seeing the same awful software at trade shows and developer conferences (where there is a lot of hype from vendors that don't seem to acknowledge reality).

That is just FUD. I have played plenty of fun and responsive Java games.

I'd really like to see you name some and link to them, even just 3 or 4, I'd really like to see some good examples.

I've tried loads of games (including commercial titles I've paid for) and on a variety of handsets, and found them almost all to be awful (though a few have been 'tolerable' they have still have annoying load / reload times and been very modest in functionality).

Having written Java software myself, I know most Java software that's bad is because most developers are really, really bad (and that's a primary - and unfair - reason why Java gets such a bad rap). From what I've seen though, all mobile software in Java seems to be poor, so I've assumed that the JRE is either so bad or the hardware so limited that it's just not possible to write decent software for mobile phones in Java. I'd really like to be wrong about that.

I agree the potential market for simpler games on phones is bigger in terms of customer base, but isn't worth anything if they don't want to buy it because the software is worse than the built-in (non Java) software they have on their phones

I should also point out, that although there are indeed ~1 (US) Billion mobile phone users compared to ~110 Million mobile gamers (i.e. GB/DS/PSP owners), there is a lot more money in the dedicate gaming space.

The dedicated gaming market is made up of people who are typically willing to pay 25-45 UKP per game on a regular basis (once every month or two, or more), compared to mobile users who pay between 0.50p and 1.50 UKP per game, and usually do that just a handful of times at most (and only some of them will be Java).

That said, I don't think the parent article is accurate when it says "Java seems to be helping to drive the market in a very definite direction", as it barely warrants a footnote in terms of actual impact.

Re:A very definite direction

[Anonymous Coward]

"I'd really like to see you name some and link to them, even just 3 or 4, I'd really like to see some good examples."

http://www.glu.com/
http://www.gameloft.com/
http://www.mrgoodliving.com/
http://www.morphemewireless.com/
http://www.digitalchocolate.com/
http://www.doomrpg.com/
http://www.mobu.com/

That should get you started. Yeah, a lot of phones are still a couple of steps behind the GBA. But on the other hand I can pick up half a dozen mobile games for the price of a GBA game and I don't have to faff around switching cartridges. Both formats fit their niches.

Re:A very definite direction

[@madeus]

That's not actually what was asked for, which was some specific Java games anyone would stand behind and say 'yeah they are good games, they are fun to use and responsive.'.

What you provided was a series of links to a of sites that carry a lot of very similar and really basic titles (the sort of stuff you see in 'Games Programming for Dummies' books), as well as a bunch of better but still poor quality games that are mostly selling of the back of names of triple A title licenses.

I should point out that some of the games on those sites arn't actually written in Java, they are just simply games for phones that are avalible for multiple platforms (e.g. that use BREW, but are written in C). Unfortunately for most of them, you'd actually have to buy the title and check it out to see if it is written in Java or not, as the developers often don't say. It's clear the web content providers for of some of the sites think all games for phones are written in Java and so just mislabel stuff - which doesn't help either (Mobu.com, I'm looking at you suspiciously).

The saddest part is, even the best titles I can see listed are still ropey compared to first generation (~15 year old) GameBoy titles - let alone titles on the more recent GBC or GBA. Many look really good in screen shots, but that's not much help when your fast paced action game is running at 5 FPS and you are at the verge of bashing your screen to bits in frustration at trying to get it to acknowledge basic user input more than perhaps at just one fixed interval every second. Or at least, as I say, that's my experience of them.

The only actual specific game on thelist is 'Doom RPG' - which is a Doom clone that runs at a resolution of 176x203 (which is about half the resolution of my phone). I do think it looks intriguing. Seriously though, are you saying it's not just purely gimmcky and that it's actually an enjoyable fast paced action game in it's own right? Are you sure it doesn't run at slideshow of 5-10 FPS? Can you really move, turn and shoot quickly and responsively?

Re:A very definite direction

[Anonymous Coward]

"What you provided was a series of links to a of sites that carry a lot of very similar and really basic titles (the sort of stuff you see in 'Games Programming for Dummies' books), as well as a bunch of better but still poor quality games that are mostly selling of the back of names of triple A title licenses."

Have you played even one of the games featured on any of the sites linked above? I'm guessing not.

It's pretty easy to tell if a game is developed in BREW or Java, seeing as only a tiny minority of handsets support both and all the sites listed allow you to filter products by handset. (Hint: with the exception of gameloft.com, virtually all of the products listed on the above sites are written in Java.)

"It's clear the web content providers for of some of the sites think all games for phones are written in Java and so just mislabel stuff - which doesn't help either (Mobu.com, I'm looking at you suspiciously)."

See above. It may surprise you to learn that mobile content stores like Mobu.com need to know something about the products they sell to actually be able to even deliver them over the air. In any case, 100% of the games available on mobu.com are Java only. Try reserving your suspicion for topics you have the first clue about.

And try playing some recent games before wheeling out the same ill-informed generalisations.

Just reminds me

[olddotter]

I have a freind who used to work at a major cell phone company. I remember him telling me people would NEVER use java or linux in embedded products because the memory foot print was just too big.

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.

Re:Just reminds me

[pureseth]

I don't think many people can truly say what will never happen, because nobody can predict the future.. Of course this is to an extent..

Re:Just reminds me

[seanellis]

Of course I can.

Re:Just reminds me

[seanellis]

But can anyone *really* see into the future?

Re:Just reminds me

[IamTheRealMike]

To be fair to your friend, many phones (Symbian, BREW) don't use Java but provide their own C++ API. Many people who have used Java on mobile phones have found that performance and memory management are extremely poor and not really competitive next to C++ (though this is the technology I'm talking about rather than the footprint).

Motorola now use the "JUIX" operating system which is a combination of Linux and Java so while he was definitely wrong, his mistake was simple enough - assuming that technological superiority would win out over mass-market/buzzword appeal.

Re:Just reminds me

[LarsWestergren]

Motorola now use the "JUIX" operating system which is a combination of Linux and Java so while he was definitely wrong, his mistake was simple enough - assuming that technological superiority would win out over mass-market/buzzword appeal.

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

[Bogtha]

I remember him telling me people would NEVER use java or linux in embedded products because the memory foot print was just too big.

Java was designed for embedded products.

He is a smart guy, he just doesn't have the vision to look out that far into the future.

Or the past, apparently.

Re:Just reminds me

[IamTheRealMike]

Java is reasonably easy to develop for, I'll give you that. But, wait until you start trying to write large, real world apps or games. You will suddenly find yourself knowing more about the internals of garbage collectors than you thought.

Maintainability - nearly all widely deployed Java apps are riddled with #ifdefs done using a custom pre-processor, because phones vary so wildly in bugs and capabilities that you have to produce many JARs from the same source code. Java the language provides zero help with this real world problem.

Porting between what? With Java you write to specifications, not a single implementation. While this can be great when it works, with J2ME it doesn't work. You end up spending your time porting apps between different phones, except instead of obvious API differences the problems are more like "Nokia 6680 uses 40x20 icons whilst SonyEricsson use 16x16 and the exact sizes aren't documented anywhere obvious". OK I forget the exact pixel sizes but you get the idea ...

Re:Just reminds me

[Anonymous Coward]

What I actually said was stop staring at my GF tits, and get out of my house, you stupid nerd.

Re:Just reminds me

[Taladar]

If you think Java has "Ease of development" you should really try to learn more programming languages.

Re:Just reminds me

[Anonymous Coward]

This clown advocates writing 3D games in Perl.

3D programming and multiple screens on my sony

[jurt1235]

So will I see the frontside of the object on one screen, and when I turn the phone around to watch the other screen, the back side of the object? That would be pretty cool!

Re:3D programming and multiple screens on my sony

[jurt1235]

I did not want to mention that (-:

Bad Idea!

[Agret]

3D Java Games? Anyone re-call the N-Gage?

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.

Re:Bad Idea!

[seanellis]

The original expert group included Nokia, Vodafone, Sony Ericsson, Siemens and Motorola. They were willing to bet some pretty hard cash that it is not a bad idea.

3D games are not necessarily console games. 3D, like vector graphics or color screens, is another tool for the game developer to use. And you use the tools you have to get the best out of the platform you're on. More tools at your disposal should be better for the game developers, and that impacts consumers positively too.

Re:Bad Idea!

[biraneto2]

You should read the comment about moore's law and the 18 month thing. In the future we may not have computers or game consoles because we already have a cell phone.

Re:Bad Idea!

[Rycross]

To be fair, the N-Gage failed more because of a crappy game lineup, horrible marketing, and high price tag, rather than 3d games on a cell phone being a bad idea. I mean, they actually went out of their way to insult their target audience.

Re:Bad Idea!

[Jedi Alec]

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.

Arggh, no, they should look for something I can make bloody telephone calls with. Alright, granted, its ability to wake me up in the morning is useful.

How much would a phone..

[CyricZ]

How much would it cost these days for a phone that did not have any unnecessities like 3D graphics, address books, calendars, clocks, and so forth? I'm talking about a cell phone equivalent feature-wise to your typical 1960s telephone. How terribly cheap could something like that be produced for? I'd almost be inclined to think that you could find them in vending machines.

Re:How much would a phone..

[eneville]

ebay for the nokia 8310! It's still one of the smallest and useful phones.

Re:How much would a phone..

[seanellis]

I had this from my mother-in-law recently. We went into town to the Vodafone shop. A small handset with all the latest features, on a pay-as-you-go tariff was about £40 ($80). Vodafone also do a "simply" range of handsets which just do phone, text, and nothing else. The cost? £70 ($140).

Actually, this isn't really a fair comparison - the simple phone was bigger and had a much larger screen, which is a big part of the material cost on a phone.

Re:How much would a phone..

[Da Fokka]

How much cheaper is a 8088 than a Pentium 4? It wouldn't make a lot of difference, if any.

Re:How much would a phone..

[Anonymous Coward]

I hear they have cellphone vending machines in Japan.

Re:How much would a phone..

[Otter]

How much would it cost these days for a phone that did not have any unnecessities like 3D graphics, address books, calendars, clocks, and so forth?

Given a display, number keys and telephone connection, which most people would regard as necessities for a mobile phone, you basically get the address book, calendar, clock and Tetris for free. (How long do you think it takes a devloper to code a calculator or an alarm function?) I suppose that if you were willing to ditch the display, you could save, oh, four dollars? As for 3D graphics, you can easily get a phone without 3D graphics.

Re:How much would a phone..

[torpor]

i've been using an AUS$45 cheap motorola cell phone as my main phone now for a year. its not fancy, it doesn't do 3D, color, or Java, but man does it work well as a phone ..

and yes, you can buy cell phones in vending machines now. i've seen them in tokyo, i've seen them in germany .. heck in germany you can buy a cell phone at the local Tschibo coffeeshop [boo Euro-starbucks clone, boo!]

Re:How much would a phone..

[shadow_slicer]

They would cost about the same.
Modern cell phones do most of their signal processing in software, so they have to have fairly beefy processors to begin with. So they basically already have the hardware to handle everything you mentioned. They're just trying to get the most use out of the hardware.

I don't know about GSM but with CDMA the clock needs to be accurately sync-ed to the network for communication to occur. So they just wrote a small program to display the time.
3D graphics could be easily implemented with the DSP chip the phones already use for communication (this chip isn't that busy when you're not talking on the phone..)...

Address books, and calendars are extra, but not hard to implement.
The biggest fluff on modern cell-phones are cameras, but those only add a ~$5 part.

Re:How much would a phone..

[IamTheRealMike]

A series of very cheap phones like the ones you propose are being prepared by major manufacturers for use in the third world. That said, there's a lot of cool stuff you can do with modern mobiles - really we've only started to explore this space. Java gaming is not the best mobile developers can do. Many useful, dare I say .. killer? .. apps can be written that exploit the varied nature of mobile phones. Just wait and see.

Re:How much would a phone..

[chrismcdirty]

I have a Motorola V66 (? extremely thin, B&W display) that my girlfriend gave me when she tired of it. It's at least a year old, and probably can't be bought anymore. But it makes calls, and that's about it. It also has a standby battery life of close to 1 week after being at least a year old.

Re:How much would a phone..

[badfish99]

That's nothing. They have used underwear vending machines in Japan.

Re:How much would a phone..

[Anonymous Coward]

What? There are a lot of current 16 bit processors out there that cost less than 1% of a pentium 4, so your comparison is flawed.

Just consider the power requirements for an advanced phone vs. a simple phone. Talk time is determined by the radio, but in standby, the other 'features' of the phone start to dominate. Add a high resolution screen and a camera, plus fancy sound chips and the price easily doubles. Fancy displays require fancy backlights, that drives up the cost. Add bluetooth for the headset and it goes up further. Oh, and speaker phone capablility? Add more parts and more power. Up goes the cost. All of these features require more firmware, require large FLASH and more RAM. $$$ And those fancy connectors on the bottom for docking? $$$

I thing the original poster was talking about a phone (just a phone) with at most a simple power jack, and maybe (just maybe) a headset jack. No docking. No Bluetooth. No color. Just a phone, with buttons to dial the number, and a simple monochrome display to show the 'antenna bars', number dialed, minutes used, etc..

I have an old qualcomm from 1997. It basically matches that description except for the docking connector on the bottom that never gets used for anything except recharging the battery. It just plain works, even after eight years.

Re:How much would a phone..

[LS]

"unnecessities"? Isn't a mobile phone itself an unnecessity? People got along fine before them. They planned ahead in advance, instead of "playing it by ear" so to speak. Ok, so it makes life easier. Wouldn't a 3D GPS-coordinated map also make life easier? Yes.

LS

Re:How much would a phone..

[Tryfen]

Nokia 1100.

Does nothing but voice and SMS.

Costs ~£20 on PAYT. That's ~USD$40.

Re:How much would a phone..

[cerelib]

Then the provider would not be able to possibly sell you extra features like text/pic/vid messaging. So no, really nobody wants to sell that to you.

Re:How much would a phone..

[LnxAddct]

I'd like a phone that resemembles something like an ipod shuffle. Small, slim, no screen, just enough buttons to dial a number and answer the phone. I think something like that could be extremely cheap and pretty cool looking at the same time, maybe program it so it speaks the number that called you or something if caller ID is a big issue. I'd bet it would catch on more than most people think.
Regards,
Steve

Re:How much would a phone..

[pipacs]

Nokia 1100. Does nothing but voice and SMS.

But it has a flashlight, you insensitive clod!

Re:How much would a phone..

[vidnet]

Mass production is king. If you can add one feature that allows you to sell 10% more phones, adding that feature would actually make the phone cheaper.

Re:How much would a phone..

[Anonymous Coward]

My Mum's got one of those. Tiny little thing, black and white screen, endless battery life and weighs next to nothing. She loves it.

And queue the Java-being-slow comments...

[MaestroSartori]

...even though back in 2000 I wrote a 3D software engine in Java that was more than acceptably fast enough to run Wolfenstein-quality gfx on a P75. And I knew fairly little about optimisation in Java, so that could probably have been faster. Throw in hardware acceleration, and you can bet these'll be fast enough for at least ok game-level graphics. Beyond games, I don't know what use this would have...

Re:And queue the Java-being-slow comments...

[CyricZ]

Would it be possible for you to release the source code to this engine that you've written, so we can verify your claims?

Re:And queue the Java-being-slow comments...

[Agret]

So you can run 8 year old GFX (well in 2000 it was 8 years old anyway) and you call that 'ok game-level graphics'. Maybe you haven't realised but that game is in a totally different generation to todays games. Most people would just look at your game and say "That has crap graphics" and not play it. That's how todays gamers are. I'm old school though and will play anything :) I'd like to see your engine.

Re:And queue the Java-being-slow comments...

[MaestroSartori]

If I still had my uni course stuff, I'd be glad to. But alas, those days are long gone...

Bear in mind I didn't claim it was well designed, extendable, or remotely worth using for anything other than a demonstration... ;)

Re:And queue the Java-being-slow comments...

[Anonymous Coward]

Yeah, Java is fast if you have a JIT. Do phones?

Re:And queue the Java-being-slow comments...

[MaestroSartori]

My point wasn't that Wolfie 3d graphics are acceptable. It's that I'd guess that acceptable graphics are possible given what I had running *without* hardware acceleration a few years ago. And thanks for the interest, but my old code is somewhere on a uni machine if it exists anywhere. If anyone at Strathclyde Uni finds it, they can post it if they want :)

Re:And queue the Java-being-slow comments...

[Anonymous Coward]

Wolfenstein-quality gfx on a P75

Excuse me! You call that fast? I don't want to break your heart, but I used to run the oringial Wolfenstein on my 20Mhz 386sx at full speed. You tell me how faster is a P75 compared to that!

Re:And queue the Java-being-slow comments...

[IamTheRealMike]

Most phones use the "KVM" micro virtual machine which does not do JIT compilation (imho a very stupid thing to do on a phone anyway), instead relying on a pure interpreter approach. It does practically no optimisation and has a very simplistic garbage collector. It is by no definition of the word fast. Sun now provide a JIT micro VM that implements HotSpot but even then, as we saw in an earlier Slashdot story basic optimisations like stack allocation are beyond it and most phones don't seem to use it anyway.

Unfortunately the javac compiler doesn't do any optimisation either. So you're left running unoptimised code exactly where you need it most. One of the things I want to experiment with next time I have some spare hours is using GCJ instead of JavaC to produce class files for phones. I suspect there would be an improvement.

It would have been smarter IMHO to embed a static compiler into phones (like GCC) and then use that to produce native ARM/whatever binaries at install time using the full range of optimisations possible. It would take longer to install apps, but this is a one time cost, and you could mostly eliminate the startup overhead of the VM and the speed penalty of bytecode interpreting.

Re:And queue the Java-being-slow comments...

[MaestroSartori]

Fast for unoptimised Java written by a relative novice? I'd say so, yeah.

Re:And queue the Java-being-slow comments...

[vidnet]

For a taste of what java can do, try Jake2. It's a Quake2 engine written entirely in java (easily started via webstart, on both linux and windows, and automatically downloads the Quake2 demo files if you want).

You would never be able to tell that it's java.

Re:And queue the Java-being-slow comments...

[badfish99]

The problem is that the Java language was designed to be interpreted. Compiling it into a fast native executable requires a lot of effort. I've tried using gcc on an i386 and it doesn't do the job well.

Sun must have put a lot of effort into the hotspot compiler, but its performance gains come at the expense of a lot of memory usage.

Re:And queue the Java-being-slow comments...

[sgt scrub]

I thought about this when John Romero http://en.wikipedia.org/wiki/Id_Software was said to be starting a "hand held gaming api" or something to that effect. It made sense on a dedicated system but a phone? Who has a phone that would keep a charge while pumping out high quality 3D images?

Re:And queue the Java-being-slow comments...

[deander2]

WOW. where to begin?

first off, i love java, and its use has employed me for >5 years now. and i agree that with modern JIT compilers, the language itself is pretty damn fast. not C fast, but pretty damn close to C++ fast. that being said:

for graphics, it still sucks. Swing is slow. SWT is better, but not great. JOGL is coming along, but immature. use java for server-side programming. that's where it kicks ass.

second...wolf3d ran on my 286! in 1990!!! arguing that java isn't slow by claiming this speed can be matched by a P75 is asinine! please quit advocating on java's behalf. you're doing more hard than good.

unless, of course, you're just being a troll. in which case i congratulate you, for winning by getting me to type this response. :-P

Re:And queue the Java-being-slow comments...

[Anonymous Coward]

What?! Wolfenstein launched intended for a 386 - and now you're saying that Java isn't slow because you made a 386's game run on a Pentium 75?

Re:And queue the Java-being-slow comments...

[LnxAddct]

The Netbeans IDE has a very nice J2ME feature set, including a gui for designing cell phone interfaces using drag & drop, and it comes with a variety of phone emulators so you can see how it functions on many different systems. Anyway... they have a few J3D samples for phones and they are pretty impressive, the one is a skateboarder going back and forth on a half pipe, the other is a kangaroo bouncing around on a pogo stick in a field. They both run really well on every cell I've tried (all of them have been sony ericsson or motorola phones), which I wasn't expecting (I thought maybe the emulators that Netbeans came with were being a little too generous to the cell phone). So as far as the capabilities of J3D on a J2ME go, I'm more than convinced that there are plenty of oppurtunities for really cool stuff.
Regards,
Steve

Re:And queue the Java-being-slow comments...

[Rycross]

Not to mention using old versions of the JVM. There have been good speed improvements in the JVM since 2000.

Re:And queue the Java-being-slow comments...

[MaestroSartori]

Indeed, our uni was still on 1.1.4 at the time. HotSpot compiler was still fairly new, and all the course materials were written with older stuff in mind. We still learned the AWT for pete's sake! :D

Re:And queue the Java-being-slow comments...

[CyricZ]

How does a skateboarder or a kangaroo on a pogo stick increase my productivity in any way? Sure, I imagine it's entertaining for about two or three seconds. But I fail to see any benefit to such capabilities. I mean, it won't make the signal clearer. It will probably just consume the battery. It won't get me to my meetings faster.

Re:And queue the Java-being-slow comments...

[Anonymous Coward]

That's crap. There are optimising embeddded JVMs that can be used, and it isn't that difficult to translate bytecode into native RISC code for e.g. an ARM processor, which BTW, most cellphones use.

What's more, some ARM processors support Jazelle (google it), which gives hardware assist to byte code interpretation.

Re:And queue the Java-being-slow comments...

[LnxAddct]

Heh, who was talking about productivity? :) Your post seemed to imply that running something like quake on your phone isn't yet feasible with J3d, I was simply pointing out some demos that I've used that imply differently.
Regards,
Steve

Re:And queue the Java-being-slow comments...

[IamTheRealMike]

I know about the embedded JIT VMs, and I also know about Jazelle. Thanks for assuming I don't know what I'm talking about. I do not care about what is theoretically possible on the latest hardware (assuming manufacturers actually go for the highest performance option and not the cheapest). I'm interested in what European mobile handsets are actually doing, and most still use KVM. Therefore I can and will use that as a point against mobile Java.

Explain this to me

[RootsLINUX]

Why would I want (or even care) to have 3D graphics on my mobile phone/device? The screen is already tiny. I'm sure 3D graphics are more computationally expensive and power-consuming than traditional 2D graphics. And in the end, I'm still just looking at a 2D projection of a 3D image. Its not like I want to be playing Half-life or another FPS on my cellphone. I'm sorry but this just seems stupid to me and I get the feeling that the only people who will want this "feature" will be the hard-core tech gadget geeks out there. Does a 3D API bring *anything* useful to the mobile table???

Re:Explain this to me

[CyricZ]

Do you or I need it? Of course not. We'd get a phone to increase our productivity. But that's just because we're into getting work done.

They've reached a point where basically everyone has a cell phone that does everything they _need_ it to do. Now they need to start throwing in gimmicks like this to get people to upgrade. This is especially true for the "teenyboppers" or "hardcore gamerz" who are easily amused by gadgetry such as this. Chances are there'll be many 13-year-old boys and girls begging their parents for a phone with 3D graphics support, even though it has very little practical benefit.

Re:Explain this to me

[seanellis]

Well, obviously, 3D games aren't going to be for everybody. There are some people who are quite happy playing "Snake", thank you very much.

One of the things that the M3G group was very careful about, though, was to ensure that it wasn't "just" a game engine. It's a fully-featured 3D engine which means that developers can use it for whatever they want.

Obviously, games are likely to always be the most popular application, but others are possible.

Re:Explain this to me

[Anonymous Coward]

I think people are too locked into thinking "Java on a cellphone" = "games". Even those who develop things like this 3D engine probably envision that its main use will be in games. Which will never be a good idea for various reasons, the main one being "a phone is not a gaming device".

I'm suggesting that people need to get out of the "game" mentality and look at other possibilities for Java on a phone. It's a programming language, not a game language. What sort of programs are you missing on your cell? Grocery list, T9-enabled notebook apps, todo-list, a social network generator using data from your SMS inbox, alternative user interfaces, whatever. Get out there and be creative! That's what's needed, not another crappy game.

Re:Explain this to me

[tomstdenis]

Yeah like screwing up the phone.

My V220 won't boot anymore [never hooked it up to the USB] after I deleted the annoying backgrounds/java games/etc off the phone. Me thinks it deleted something more important... I'd rather have simpler phones that are less likely to screw up in this way.

And of course, there are a million "rogers" booths [my provider] in every mall, corner plaza, etc. Except when you go in there their only mission is to sell you NEW PLANS. They don't care about service or maintenance.

Well, maybe this will work for the rush, but I can imagine 5 years from now all these locations will be closed up after people "already have" cell phones.

Tom

Re:Explain this to me

[lightversusdark]

I, for one, welcome any developments in 3D capabilities for mobile devices. There are many examples of applications that require 3D that would be desirable on a mobile device. One example that I have worked on is in hospitals, where doctors and nurses can pocket a small terminal that is capable of displaying not just a patients medical records, but also MRI, CT & PET imaging, and manipulating the data sets in three dimensions. Previously this was achieved with a render farm pumping full-screen bitmaps over the wireless network to notebook form factor thin clients. Not only is there a central point of failure, but also masses of data-traffic, and an unwieldy device to cart about. Providing staff with phone style devices is a cheaper hardware investment, particularly considering the wireless-ready capabilities of the phones, and can supply several levels of fall-back networking capability (802.11 -> UTMS -> GRPS -> GSM, even Bluetooth: does your notebook have this much support? How much would it cost to add?). Java *does* provide a secure enough platform to handle confidential data on a consumer device, and the patient (in this example) is likely to have access to a similarly capable device to view the data at their leisure - how many Java implementations are there in your house? (Hint: more than you think). I could expound further, but while the games market doubtless drives the nVidia/ATI development cycle, there exist many more uses for 3D visualization than just games. And besides, all the best games are 2D anyway..

Re:Explain this to me

[JensLudolf]

Why people would want 3d on their phones: It looks and sounds cool, and the marketing-people told us so! *must do what those ads told me to do*

I'm sure there are some practical-uses for it as well as entertainment, I know some unnamed car-makers (or at least sub-contractors of car-makers) were looking into 3d-projections of maps on dashboards, and I'm sure it could be cool on a mobile-device (handheld, gps, mobile-phone).

Anyway, having 3d available on mobile-devices need'nt be a bad thing even if it's a power-consuming beast, it's a possibility and I'm sure as it will spread, people will find both cool and useful uses for it. Hopefully there will still be mobile-phones with less gloss available for those that want.

As for power-consumption, it's partly beeing addressed by developing spezialized hardware for 3d-graphics, where one of the design-goals are low power consumption. Having worked as a SA for Falanx Microsystems http://www.falanx.com/ which are designing an IP-core conforming to the OpenGL ES http://www.khronos.org/opengles standard/API, one of their chief design-goals are minimizing power-consumption. I'm sure NVidia, ATI and others designing 3d-hardware, are considering the constraints of their target-platforms. (If my memory serves me right, NVidia has some interests in the mobile-market, and I'm sure the other actors on in the 3d-market are looking at it as well).

-- Kjetil Joergensen

Re:Explain this to me

[clonmult]

I've got an old Siemens SX1. 120mhz ARM cpu, it does 3D gaming very, very nicely. Midtown Madness plays very nicely.

Look at something like the Orange SPV C550 - its running a 220mhz CPU, has a 240x320 resolution screen of a very decent size/quality. Things are developing.

Mobile gaming isn't about playing games with the same depth of play as their desktop equivalents. Its nice to be able to play something like this whilst stuck in the queue at the supermarket, or just bide away a little time during slack points in the working day.

And as other posters have said, it doesn't have to be games - use your imagination to use the 3D engines in other ways.

Re:Explain this to me

[orasio]

<meta-rant>

I don't think you made an insightful comment.

We already knew there were lots of people who didn't care about 3d on their phones. Move along. Nothing for you to see here.

At least you are not one of those whiners who complain about bad service and say that R&D should go into improved their flawed voice phones, instead of useless features.

This is an article for _developers_ who _do_ care about 3d in phones. Maybe _you_ don't have an obvious application for that. Some other people might. Some might like to toy with that. You know how they are, developers, they like to toy with stuff. Sometimes they come up with neat stuff. But they do that _after_ they tinker with stuff other people don't care about.

Anyhow, what i am complaining right now is that I don't enjoy listening to what people don't care about. I come to slashdot, because there are people here that enjoy stuff other people don't care about. Of course, pick any topic, and you will find that most people don't care about it. But I don't think that's what we come here to read. I though we came here to read stuff about people who did have something to say. If you don't have something to say, or you don't care, please, repect your decision, and don't care enough to post. If you want to point out how pointless something is, it's more eloquent to leave it alone, and let it die for itself. Whining about it just spoils the party for the rest of us. In fact, I don't care as much about people whining as I care about moderators that say they are "insightful".

</meta-rant>

What is mobile 3d

[Anonymous Coward]

Does it mean OpenGL is too fat? Why can't I have a lightwigth and fast API on my mobile notebook?

Gaming on the Phone !?

[betasam]

One of the early companies focusing on Mobile Phones was Fathammer. Initially they started out with a ports of Doom engine based classics; now seem to have a nice collection. I believe the stronger driver of applications on phone platforms is the phone hardware. Java 3D API is one more trial at luring in more applications by providing easy-to-use API. But even if Handspring and Palm were to provide 3D programming API for their Treo series (or anyone else does likewise), it still depends on the hardware. Things one would be bothered about would be battery times and audio which actually adds on to gaming experience (and already no one wants to hear loud ringtones everywhere!)

Nokia airs an ad in India which almost drives in a message saying "phones are for talking" while showing a model with a vidcam and video playback. I wonder how many people find time to use the "other" applications on the phone apart from a PIM (Phonebook/Calendar). Further, with 3D games what about an added issue of people getting something akin to Doom Induced Motion Sickness(DIMS)? I have found controls for a 3D game (on my Treo) pretty difficult to use for a 3D racer game, which kind of kills the experience. I wonder how many people play 3D games on their phones comfortably, and where they get them from!

Neat article

[LarsWestergren]

I have some friends who are working with developing Java games. So far the big money is not in developing titles for phone companies portals (or even worse trying to sell them to the end user yourself) but to develop ad games for companies who make them available for free downloads, usually as a part of a competition.

From what I understand, the best part of the job is that since graphics on mobile phones and other limited devices are so cruddy development focus tends to be on addictive gameplay rather than eyecandy. It is also still possible to be a small independent game studio, no need for a big art studio to render hours of CGI, etc.

Worst part is that just about all phone developers are very sloppy when it comes to implementing the J2ME standards and all models tend to have their own quirks. Sony Ericsson and Nokia are probably the best, but that is not saying much. So in this case, it really is "write once, debug everywhere" type java.

Mobile gaming is really taking off, I read on GameDev for instance that mobile game developers Gameloft increased their workforce from 432 to 1375 employees.

Re:Neat article

[XMunkki]

Worst part is that just about all phone developers are very sloppy when it comes to implementing the J2ME standards and all models tend to have their own quirks. Sony Ericsson and Nokia are probably the best, but that is not saying much. So in this case, it really is "write once, debug everywhere" type java.

And this actually really says it all. Most of the effort of doing a J2ME game seems to go on making it work on various devices and conform to operator wishes (and they are plentiful and vary a lot). This is even more so if you really try to stretch the device (as making fun and good looking gameplay may take more power since you're likely doing more under the hood).

And it really doesn't help that many firmwares and phones really handle things differently. Both in performance and compliance. This is why these mobile gaming platforms have really emerged. Still a lot of effort to get a small game done. I'd much rather spend my time honing the game than using 30% of the budget just trying to get it to run on 30 different devices.

Java! That's the answer!

[MBCook]

There! That's it! Java is the solution!

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:Java! That's the answer!

[tomstdenis]

Because java is a waste of time and effort? Because the device runs MIPS processors with limited memory? ???

If anything they should open the platform up. Not like people are not going to buy things like GTA PSP or whatever just because a tetris clone exists. It would get more people in contact with the PSP which will drive up the demand for it.

If course you have to think outside the box for that...

Tom

Re:Java! That's the answer!

[MBCook]

But when you truely open it up, then people can use homebrew code to launch copied games and other things Sony doesn't want them to do. Java prevents that.

As the processor and memory, they will take a hit from running Java but it would still be WORLDS ahead of what even high end cellphones offer. More than enough for most homebrew games and platformers and other fun stuff. Plus you've got the fast 3D hardware which could be exposed (either though Java3D, or a JNI thing for better performance).

I thought of truely opeing it, but we all know it will never happen. I think something like Java would be our best bet. The other option would be to let us run homebrew native code, but keep it in a sandbox/managed environment so people couldn't play copied games/etc (like the did with PS2 Linux). I could see that happening too.

Re:Java! That's the answer!

[tomstdenis]

If people want to go out and manufacture UMDs on their own dime, so be it.

Even in the GBA scene most people don't pirate games despite the fact it's very simple. In fact of all the places I've been *I've* been the only person with a flash cart. All the peeps in airports and on trains I've seen have had legit games.

The homebrew scene is just that, hobbyists. When it comes down to it the vast majority of people still go out and buy games.

Tom

Re:Java! That's the answer!

[MBCook]

I agree, I have a flash cart too which I have used to play and develop home-brew games. But when the suits are probably saying "No" to anything that even opens up the remote possibility that one day someone might use it to steal a game, the "safety" of Java might make it "OK" by them.

It's not an issue of reality, it's an issue of business.

But like I said, they could also give a managed environment like the PS2 had with Linux.

Re:Java! That's the answer!

[tomstdenis]

I think I was making a different point. Yes, there is an active GBA, PSP and DS devel scene but my point was moreso that of all the console owners out there the people with the facilities to actually pirate games is a low percentage.

I mean I can rent games at blockbuster for 5$, rip the game to my HD and then use my flashcart to play the game whenever I want. I don't because it's not worth the trouble. What I do use my gba carts for [other than programs I write myself] are things like PocketNES.

But the point is if the game is actually worth the money people will buy it over a using a flash or other method usually because of the hassle [e.g. having to program the cart which can be a problem when you're not at home]. I'd rather just pay the 40$ for the GBA cart if the game is any decent.

And from what I can tell that includes the vast majority of portable console owners.

Tom

Tom

Re:Java! That's the answer!

[PsyQ]

Fear of piracy? I assume you haven't examined the way the console market works for very long. Console makers want 1. a cut of your profit on every game you sell and 2. a barrier so that not any old dweeb can go make a PSP game featuring George W. Bush and Kofi Annan both wearing women's underwear and being in the same room.

1. Is easy, licensing cost. You can't make UMD discs, you're not allowed to put games on UMD discs, you can't sell them. Sony can, and they will sell each and every one of those discs to you.

2. Is harder. It comes in the form of Q&A tests that EVERY game has to pass. If Sony doesn't like what they see in your game, it won't be released. If it crashes way too often, it won't be released (unless it's called Madden 06). If the menu structure is deemed confusing or if the game contains too many politically sensitive scenes, it's back to the drawing board for the developer. Even if the packaging has the name of the game in the wrong place or doesn't feature all the right logos, it doesn't stand a chance. Though I'm sure Sony's own people help with those graphic design/marketing bits.

That, and they charge around USD 10,000 for a development kit for the average console. I'm not sure what the PSP's costs.

Piracy is surely one factor here, but it's not the only one.

Re:Java! That's the answer!

[Troed]

Uh Tom. No. Java on cellphones is absolutely excellent. From a security perspective it offers user installable applications without the risk of trojans and viruses, and it's quite easy to prototype in. Java ME is also quite suitable for games, and on the current crop of phones (Sony Ericsson K750/W800 as one example) you can get excellent 3D games.

Re:Java! That's the answer!

[tomstdenis]

Tell that to my v220 that somehow got smoked.

You know what works well for a cell phone? Proper software development made possible by not budgeting engineer time on frivolous BULLSHIT features.

Tom

Intersection of these two subjects

[dwalsh]

Here is a Venn diagram showing the interest in Java on mobile devices e.g. phones (MIDP) and Java 3D and the intersection between them:

     _________    _________
    /         \  /         \
   / Java On   \/  Java 3D  \
  /   Phones   /\            \
  \            \/            /
   \           /\           /
    \_________/  \_________/

Hope both of those guys enjoyed the article!
 

Who uses their mobile phone for games?

[digitaldc]

The article is interesting and is very informative.
My only objection is that I do not like playing games on a tiny screen using tiny buttons. Since most games nowadays are not just 'steer and shoot,' the complexity of the controls and intricacy of the graphics plays into the overall fun of the game.
I applaud the efforts to get better 3D graphics for mobile devices, but I don't think I will ever be wasting my time playing games on my cell phone. It is much more enjoyable to play a console system on a large projection TV. But of course that is just MY opinion.

Re:Who uses their mobile phone for games?

[JensLudolf]

Agreed that the gaming-experience are much more fun and enjoyable on consoles or computers. Consoles are after all designed with a good gaming-experience in mind (at least to some extent). The regular cell-phone isn't designed to be a gaming-platform, it's mostly a phone. The exception may be nokias N-gage, tho I don't have any personal experience with it.

I am however guilty of playing some of my cell-phone-games, when I have nothing better to do, and nothing at all available to fiddle with. While i.e. forgetting to bring something to read while taking a dump or sitting on a bus.

I don't think mobile-phone-games will be a good "replacement" for console-gaming or pc-gaming anytime soon, but they serve their purposes.

--
Kjetil Joergensen

Re:Who uses their mobile phone for games?

[tshuma]

Well, gamers are not developpers.. there are more million!!! mobile gamers around the world, probably they are the targeted market ;)

Re:Who uses their mobile phone for games?

[Nightspirit]

I do.

My samsung i730 screen is about as big as a gameboy SP, so screen size isn't really an issue.

Although honestly I can only think of a few solid games for the pocket pc.
Warfare inc (C&C clone), age of empires, skyforce, and a couple of pinball games. Definitely not as wide of a selection of games, but decent enough so that I don't have to carry a gameboy around.

If anyone knows of any other solid games for the pocket PC I'd be happy to hear about them.

PSP Whoring?

[Anonymous Coward]

I move to strike the "PSP" comment from this posting... this post has nothing to do with the PSP by its own admission. This is just gratuitous PSP-mentioning.

John Carmack

[vasqzr]

He made a comment a while back:

"The biggest problem is that Java is really slow. On a pure cpu / memory / display / communications level, most modern cell phones should be considerably better gaming platforms than a Game Boy Advanced. With Java, on most phones you are left with about the CPU power of an original 4.77 mhz IBM PC, and lousy control over everything."

Re:John Carmack

[Anonymous Coward]

Oh, the Prophet has spoken. I guess that settles everything...

Re:John Carmack

[Anonymous Coward]

Amen!

Re:John Carmack

[Anonymous Coward]

Thats my experience too. Watch all the random /.ers contradict Carmack tho... cause -they- know better. So many java-weenies, so few bullets...

Re:John Carmack

[Anonymous Coward]

Wow, I was ironic and you didn't even get it. /AC who posted the "prophet has spoken" comment...

Ha! 3D...

[GiorgioG]

I'm still waiting for a sub-$200 phone that'll integrate with *SOME* calendaring system from Sprint.

Commodore games would be better

[aphaenogaster]

Just get all of the old commodore 64 games on the phone and you would make a ton of cash. M.U.L.E. for starters. Archon, Ultima, hell they are still better than most modern games.

Re:Commodore games would be better

[Craggles]

I have a Commodore 64 emulator running on my phone (Nokia 6630). Pretty cool to show people Jumpman! Get a bluetooth keyboard for it, and the old games are quite playable. I keep a keyboard in the car in case I need to do remote support (using s2putty), so whilst waiting at the airport to pick someone up, I fire up the Commodore 64, and play LodeRunner :)

Frodo is the emulator for Symbian phones.

http://e32frodo.sourceforge.net/

And here is pretty much any C64 game you can think of.

http://www.c64.com/

Opensource 3D on every phone ? possible (*caugh* )

[rzr]

Just to let you know, that 3D is possible on most java phones
with my embryonic diet3d library :
http://rzr.online.fr.nyud.net:8090/java.htm

OK lot of work to be done to be M3G compliant... (btw, i am open to contribs)

But what is bugging me : is J2ME the only alternative to WinCE or symbian ?
since most Linux handset doesnt not provide other API (beside QTopia and his friends)

Re:Linux is hard to install

[77Punker]

This troll has had such a mistake for such a long time. It should be 1%.

Right Tool for the Job

[Ranger]

It's all about choosing the right language for the right job. 3D Java would be perfect for that 3D glacier screensaver I had in mind. You'd be able to watch it travel down the mountain and melt. Don't worry. Java is fast enough to still be realistic when you take global warming into account.

The problem with Java...

[amightywind]

Perhaps I have misunderstood, but I thought that Java 3D made OpenGL calls under the covers. Is this the case. Java's fatal flaw has always been that it must use low level NMI modules written in C or C++ to get anything done. When Jim Gosling choose not to have pointers he basically decapitated the language. Therefore, all Java programs that need to manipulate memory mapped registers are a kludge by design.

Last meaningful Java UI advance?

[galtenberg]

When was the last time Java made a meaningful advance on the UI front?

I guess I'm still jaded from the 3 years I spent in the Java applet paradigm, trying to bring a vision of mine to the web, only to find I was working in the "last gasp" of client-side Java - an era marked by the release of Swing and then... nothing.

Re:Last meaningful Java UI advance?

[polyp2000]

I have a friend who works for a company who sells the whole spectrum of mobile phone gimmicks from ringtones to games. The general consensus is that despite the fact that we have lovely things such as symbian - there are so many different types of phone and OS that the write once, deploy everywhere concept falls on its back. Unless of course you start looking at the J2ME stuff. Which while maybe not as powerful as writing for the native platform means you are not as hindered when it comes to moving onto different handsets.

You really dont need to look to the PSP to see what ordinary nokia's are capable of with a bit of skill decent 3d games are here now the N-Gage for example I've been able to play several N-Gage games on other nokia's such as the 6680. Elite fan's should check out Darxide if you have a series 60 phone! While not quite as wonderful as the PSP , being able to play Tomb-Raider and Tony Hawks in 3d on a phone still impresses friends down the pub especially when they realise that you dont need a silly looking n-gage to play them. These games have staying power and are worth playing.

The trouble is that most of the "really cool stuff" is not written using j2me . Most of the java games i've seen are just crap by comparison! Compare Tiger Woods for symbian (N-gage) to the java version for example. The other problem is that it simply isnt worth the time or effort for these companies to do anything more. The latest java game has about as much lasting power as the latest Crazy Frog ringtone. For the people that sell this shit at £1.50 a throw they are guaranteed a good return. But little jonny is'nt going to complain when he finds out that the game has jonly 3 levels and is exactly the same as the sideways scrolling batman platformer he downloaded last month but with a different tile-set. Its a license to print money really . Fashion concious teenagers will be taken in by it every time just like they will with the latest boy/girl band single (tm) out on monday at leading record stores.

Thing is nvidia have something in the pipeline called goForce, its going to end up in lots of mobile devices and phones (almost certainly the next generation of nokia's). What remains to be seen is how much market penetration it's going to have and if it will fragment the mobile gaming camps or bring them together.

Another problem with gaming on phones are not the development issues they are the form-factor, screen-size/orientation and button configuration. Nokia tried to address these issues with the N-Gage but the design was slated, we all remember the "Taco Shell" comments. I think a landscape clamshell design might perhaps be a better idea - something that looks / acts like a phone when i'ts shut - but open up the clam and there something really funky inside.

We will all just have to wait and see what the future holds.

Nick ...

Real Need

[Anonymous Coward]

Forget about Java 3D on cell phones. What we need is a Java interface to DirectX and OpenGL. I'd do it myself if I thought there was actually still any way to make money by developing software. Today all the money goes to CEOs and not developers, so I have no incentives to spend the time doing this myself.

3d user interfaces

[Goodbyte]

I have just had my final lecture in a course on Mobile Computer Graphics and there is a lot more to mobile 3d graphics than producing nice games. Especially there was one lecturer from TAT that makes user interfaces for mobile devices, and the possibilities for creating more userfriendly interfaces are endless with 3d graphics. I am not just speaking of eye candy, but useful animations that help the user navigate the menu tree.

It's not "Java3D", it's an OpenGL wrapper in Java

[Animats]

This isn't Sun's badly designed Java3D, which is now abandonware. It's just a wrapper for a subset of OpenGL embedded devices. That's reasonable enough. It helps to keep OpenGL alive. Microsoft would like to force everyone to use Direct-X.

The base embedded subset of OpenGL leaves out display lists, any geometry more complicated than a triangle, and all the new programmable shader stuff. It's basically what an SGI machine had twenty years ago.

This may or may not be useful for cell phones, but it will be useful for things like car navigation systems and other embedded devices.

Only for JIT VMs

[Viol8]

What are the odds that mobile phone manufacturers will bother
with JIT systems for 101 different CPU types out there that the
phones use? Pretty slim I reckon. So it'll be a standard
interpreter type JVM with the accompanying slowdown.

Re:Only for JIT VMs

[Dan Farina]

Don't many mobile/embedded devices use processors that very closely match the java bytecode as actual machine instructions?

Re:Only for JIT VMs

[Hal_Porter]

Sort of. Most of the ARM9 cores in mobile phones have a very clever hack that lets them execute 80-90% of byte codes in a single cycle by mapping them to a Arm instruction with an extra stage on the front of the normal Arm pipeline. The rest trap to ARM code that emulates them.

http://www.arm.com/pdfs/JazelleWhitePaper.pdf

The real ARM instruction set is nothing like Java BTW, it's a slick Risc chip where all instructions are conditional, and you get shifts for free, whereas the Java VM is stack based.

http://en.wikipedia.org/wiki/Acorn_RISC_Machine

On a phone screen even Mr Do looks crap

[Viol8]

So what chance does a 3D game have of looking even remotely decent on
something a few inches square? OMG! WATCH OUT FOR THE .... errr... 4
pixel squidge coming at you ... no wait ... thats a coffee spot ...

Re:It's not "Java3D", it's an OpenGL wrapper in Ja

[seanellis]

I'm afraid that this is incorrect. M3G does, intentionally, borrow concepts from OpenGL and is implementable on top of OpenGL, but M3G is not just OpenGL/ES wrappers for Java. (That's JSR-231 and JSR-239.)

The article in the original post is part 1 of 2. Part 2 will show the scene tree manipulation functions and the high-level stuff. This includes file loading, animation, alignment, etc.

cost about the same ...

[hany]

They would cost about the same.

... if measured by money.

But IMO it isn't true if we measure the "price" in time or nerves you spend "wrestling" with you "smart", "feature packed" and whatever phone while trying to make something which should be easy on the mobile phone, like making a call or sending a text message. :)

Because I suspect software for phones (that part of software which we can call "smart", i.e. not that part which handles signal processing etc. but those calendars, games, address books, ...) is done "as ussual" thus it is done quickly, looks nice ... but has bugs, is slow, ...

Given few years, it'll improve. But by that time there will be another round of new features and they may be again "done quickly". :)

I just hope that there are enought people willing to buy "simple" (but quick, stable, ...) phones for "free market" to deliver some.

3D Handsets = Sidetalkin'

[Anonymous Coward]

Alas, they are not real gamers unless their phone supports Sidetalkin'.

Hey, can the effect be emulated through some Java 3D Audio library even on a phone without actual hardware Sidetalkin'? I smell a business opportunity here!

Sad benchmarks

[can56]

Insightfull my ass!

lp goes through the loop X times (2 or 4 billion?) and who fucking knows where ilp started. And for what it's worth, the 5-billion loop code takes 10 to 13 seconds (gcc -O2 ...) to execute on an AMD 3000+ box, using ints, doubles, or long doubles for lp and ilp.

And only f-tards use floats as loop counters.

Re:It's not "Java3D", it's an OpenGL wrapper in Ja

[Animats]

Yes, M3G has a file loader and a scene graph mode. The M3G file loader is a bit too powerful, because it can load general Java objects, so it has virus potential.

Scene graph systems are somewhat out of favor in the game developer community. They're not powerful enough to be a game engine, and they're overkill for a 3D drawing engine. There have been many scene graph systems, SGI's Inventor being the first big success. They're nice for simple little games, but they usually scale up badly. For the small screen, they might work for low-end games.

Here's an example of the problem with scene graph systems. M3G has no collision detection. If you add collision detection, you'll need a separate set of data structures, organized for collision detection. Then you have to keep those in sync with M3G's scene graph. It's usually easier to have only one representation of the scene and draw in non-retained mode.

It's one of those things where the extremes are more useful than the middle. A full game engine, with collisions, physics, and triggers is useful. A non-retained mode 3D graphics API is useful. Most of the stops in the middle are not too useful.

Still, maybe for the small screen...

C or C++ is a better choise for mobile phones.

[more]

I have implemented a chess engine for mobile phones in Java, and a similar engine in C++ and Python. My Java engine is the fastest on the market and licensed by two companies, selling in ten thousands of copies. If I run it in a normal computer, the java engine is about 1/4 of the speed of the c++ engine. However, mobile phones do not afford JIT, because it would eat batteries and resources. Thus, JIT is off, leading to about 3 % of the speed that could have been achieved by C++.

Java is not an enabling technology for mobile phones. A good portable C or C++ library would have been an enabling technology.

Also, they should try to agree on certaing pixel size standards, like VGA, SVGA, XGA etc. were for computers. For small screens this is even more important.

If we had screen size standards and a reasonably good C-library for mobile phones, we would be years ahead in development and consumer level application adoptation. Symbian does not have a proper posix-like API. The developers are really waiting for that.

Another blocking thing has been that the bugs in APIs (JAVA or C) have not been published. The mobile phone manufacturers work in complete secrecy and do not publish their bugs nor the fixes to the bugs. Each ISV has to find out all the bugs on their own. This is really bad.

Re:It's not "Java3D", it's an OpenGL wrapper in Ja

[seanellis]

The M3G file loader is a bit too powerful, because it can load general Java objects

This is incorrect. The file loader allows loading of the M3G scene objects, plus a hash table of string/string pairs. That's all. There is no "virus" issue.

Plus, loading Java objects isn't a security hole in the first place. Loading external Java classes might be, but that's not enabled on any of the MIDP platforms.

Scene graph systems are somewhat out of favor in the game developer community.

In the console developer community, maybe. With C or C++, there's no performance differential between code you wrote to do your scene management, and code the middleware people wrote. You can always write a specialized scene mahagement/traversal engine that works faster for your one game than the general purpose middleware one, and you have space to burn on your CD.

In mobile Java, scene graphs can be very useful. Using them allows you to move all your scene graph management code into native code. And since the native code is already on the handset, you free up space from your precious 256K download budget for more actual game code.

Re:It's not "Java3D", it's an OpenGL wrapper in Ja

[Animats]

While the M3G file format doesn't contain code, the M3G loader in JSR 184 will load any serialized class that descends from Object3D. Exploits, here we come!

3d on mobiles in java

[danmoore22]

really, don't read this if you have an aversion to windows.
right, i'm getting to be an old fart (and this is going to talk about some windows and worse...) and i can remember loads of up-their-own-**** C++ guys banging on about how slooooow VB was, erm mid-90s, when all it was doing was windows dialogs, all video blits really.
suffice to say they had lots of fun sending MFC WM_OPEN_THE_WINDOW_WITH_A_BLEEP messages to some grim looping CPU hogger while some dumbass VB programmer would type formHello.open() or whatever... the VB guys were a bit lost with the multi-threading but actually got a lot more work done.
end of the day, if you wanted to be precise about shit, you didn't use VB. if you want to be really fast about shit, don't use java. but if you ain't a fricking superstar, don't get hung up on C++ (since when is complex good? oops...) because you're probably screwing things up yourself much worse than any language ever did... most of us just aren't good enough, use what's simple and availabe, imho.
thing is, there's a frickin LOT of people with java compatible phones, on them all the time, there's a lot to think about beyond computing perfection here...
sorry, had beers, i just re-read and that was rubbish, but i'm not a bad person, honest,
i use linux everyday,
i think google is broken,
um, whatever else is cool,
dan.

Re:It's not "Java3D", it's an OpenGL wrapper in Ja

[seanellis]

In the article you refer to, Mikael Baros writes: The best one is that the Loader class can load much more than M3G files, it can basically deserialize any class that inherits from Object3D.

If true, this would open up a security hole. Fortunately, he is incorrect. The Loader will only deserialize the classes in the spec that are derived from Object3D. That's a very different claim.

The file format does not use standard Java serialization and instead uses a compact binary encoding of the specific data from the classes defined in the spec. Loading the file consists of reading the type ID for each object, verifying that that ID corresponds to one of the 24 known object types, and if so creating an object of that type using an internal factory function. The new object can then be populated using the following chunk of data.

Since the factory does not have a method of creating arbitrary classes outside the set of 24 mandated by the specification, the loader cannot be used for exploits in the way you describe.