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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[@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?

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

[Taladar]

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

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

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

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

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

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

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

[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

[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>

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.

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

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)

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

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.

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.

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.

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.