• Advertisement
Sign in to follow this  

Carmack agrees J2ME is awful

This topic is 4678 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Well these are exactly the same views i had of J2ME a year ago after i started developing a J2ME adventure game and stopped because of the awful speed and total lack of compatibility between different phones. This led me to believe that J2ME was the worst thing that the handset makers had adopted for mobile games. Since we are going to have to tune and recompile for every specific phone model anyway, what are the advantages of J2ME for mobile phones? We have phones with 200-400mhz processors but the Java Games are worst looking than the 16-bit generation consoles like Genesis/Super-NES which had 6mhz/4mhz respectively. The only good thing was that the API was very easy to use and had a clean .NET like interface. But this API could have been easily designed for C/C++. Any comments? Edit: O and here is the link to his Blog Cell phone adventures

Share this post


Link to post
Share on other sites
Advertisement
Yeah, it does suck. But hey, it's the best we have at the moment.

My main complaint with J2ME is that the standard is too conservative; it needs to grow some balls. For example, hell, alpha-ized images aren't even in the MIDP 1.0 standard... they definitely should be as MIDP 2.0 support is total shit (i.e. barely any affordable phones in North America that support it).

Speed? Yeah, I'll complain about it too. However, that's what makes it fun: shoehorning inefficient code onto a small machine. :)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
REPOST

Share this post


Link to post
Share on other sites
Well, on some high-end pones (Symbian OS, Linux, WinCE, Palm OS) you can use C++.
Of cause you have other problems - Palm OS (Treo) and Linux phones have low market penetration, WinCE.. hmm, I just don't llike it, and Symbian OS in the process of closing itself from small third party developers (Symbian Signed programm and ability of the operators to lock the phone from outside applications in the next OS version)

Share this post


Link to post
Share on other sites
I agree it's challenging. The main reason that people moan about J2ME are

- It's limited - which is of course reasonable, considering the severe limitations of the devices - it does tend to go with the lowest spec phone - MIDP2 is better of course.
- It's not compatible enough between devices.

In fact I don't think you're easily going to find a system which allows you to deploy the same build of a game to different devices. This is because they all have different screen resolutions, colour depths and other capabilities.

On such a small screen, developers have to think of exactly how many pixels will be used for what - therefore on different devices, the game may even have to play differently, because of the inherent limitations of a small screen.

In fact as long as you stick to the standard and don't do anything too rediculous, J2ME does work compatibly between devices. It's just that isn't that useful. Most games want to use device-specific features, and push the edge of what that particular device can do in some way.

The API itself is very small and fairly clean - pretty much a subset of J2SE, with some of the strange bits removed, and the really arcane bits (AWT etc) just gone entirely. Yet useful things are still there like threading and collections.

True, some people moan about lack of floating point, but these devices are typically FPU-less so they would be terribly slow anyway.

Carmack is of course doing things rather more ambitious than most with his. He's trying to write software 3d engines in J2ME - which is ambitious in the most.

Perhaps he's played "Frag Island" - a J2SE "port" of Quake which uses software rendering - and realised that it's actually rather fast.

Mark

Share this post


Link to post
Share on other sites
There's nothing wrong with J2ME per se, it's just that:
a) it's often running on very limited devices (no hardware divide!)
b) the JVM is not always well implemented (MIDP2 TiledLayer anyone?)
c) the framerate is often limited by the LCD screen, which is often a very cheap part (to keep costs down) that can only cope with 10fps for example.

But, the biggest problem is that J2ME has a lot of overhead (up to 1K overhead for each class) which goes against the constraints imposed by limited devices (i.e. low memory), which leads to developers not using classes (all my recent work only use three classes: the midlet, a canvas and a runnable) as well as not using other language features (class constants for instance).

To be fair, J2ME/MIDP1 was never designed for games (but MIDP2 is an attempt, although a bit late, to address this) and developers have coerced games into the system, overcoming the problems previously stated.

Skizz

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by markr
Carmack is of course doing things rather more ambitious than most with his. He's trying to write software 3d engines in J2ME - which is ambitious in the most.


I think he said he's making a 2D RPG version of Doom...

Share this post


Link to post
Share on other sites
does it work well with the N-Gage or TapWave? those are technically Cell Phones right?

how hard would it to a)adapt another language/API (ex: Lua or Allegro) to be cross platform for mobiles and b) to make a from-scratch-cross-platform API/SDK for mobiles?

Share this post


Link to post
Share on other sites
Well, I just got a new phone (Ericsson k700i, although apparently the model is some months old) and I was impressed to see that it can run java apps with textured full-3D graphics at a decent frame rate (not quite what you'd call 'fluid' but definitely playable). Talking to the guy at the phone shop he seemed to think that MIDP 2.0 was standard on phones these days - I'm aware that Australia is somewhat ahead of most of the world in uptake of new technology *cough*brag*cough* but from that, I would have thought that MIDP 2.0 phones were relatively common, and given that it might take three months to write a game to run well on MIDP 2.0, by the time the game is released it'll be even more widespread.

Anyone have market penetration figures for higher-end phones?

Share this post


Link to post
Share on other sites
Exactly, the reason why Java was chosen over native code was because it was supposed to bridge the gap between the thousands of different phones and be a cross-platform solution. But since in reality, write once - run anywhere is nowhere near the truth, the compromise in speed by using Java is worthless. Btw, i dug up my old project and ran it on a emulator.

Free Image Hosting at www.ImageShack.us

It did run on my phone at about 20fps. And all i was drawing was 1 fullscreen bitmap and 1 character sprite. No AI, nothing. Just pure drawing code.

My phone has a 54mhz processor in it and i believe on Pcs with this speed, you could play C&C and other old dos games which had far bigger resolutions and many many more sprites, full AI, etc...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by GamerSg
My phone has a 54mhz processor in it and i believe on Pcs with this speed, you could play C&C and other old dos games which had far bigger resolutions and many many more sprites, full AI, etc...


PCs at that time probably had a whole lot more RAM and CPUs with built-in MMUs etc, but good point though on poor CPU usage.

Share this post


Link to post
Share on other sites
Don't forget that clock speed is not equivalent to performance. PC processors in the 486/Pentium I days were designed for generic, fast processing. Cell phone processors are designed for low power consumption, simple cataloging and circuit control tasks, and some small graphics support for the display. There's also the entire underlying architecture to consider - cell phones do not have large amounts of fast, quickly accessible RAM, for example. They also do not (usually) have hundreds of kilobytes worth of instruction and data caches and other such processor performance technology.

The desktop PCs of 10-11 years ago were designed for fast, powerful processing in a fat-client environment. Cell phones of today are designed for small, efficient, mobile processing in a thin-client environment. Comparing performance based solely on processor clock speeds is taking too narrow a view of the situation.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement