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

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 [superscape.com] 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 [benhui.net].

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!

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 [gamedev.net] for instance that mobile game developers Gameloft increased their workforce from 432 to 1375 employees.

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

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 [nyud.net]

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

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

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

[vidnet]

For a taste of what java can do, try Jake2 [bytonic.de]. 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: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: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.