Mobile/Cell phone programming, which API?

First of all - you are forgetting one other major player: BREW. It's a platform that's quite similar to Mophun, but it does have a bigger market share AFAIK.
Second of all - when you say J2ME you really mean MIDP. J2ME is an "umbrella term" that encompasses many configurations and profiles. But when we talk about developing for mobile phones, the profile in question is usually MIDP.

Now for some answers:

a) Open standard vs proprietary: MIDP is a completely open standard. You can get all the tools you need to develop, test, and deploy your apps for no money at all. You don't need any special developer phones, any phone will do. BREW and Mophun on the other hand are proprietary standards. You can get the basic tools for free, and you can write apps that will run on emulators, but once you want to actually see something on the phone itself, you'll have to shell out some big bucks. And the deployment is completely centralized, you can't just upload an app to the web and have people download it from there like with MIDP, you need to go through the BREW/Mophun deployment systems (unless you can get your hands on a developer phone).

b) Performance: BREW and Mophun are written in C/C++, while MIDP is Java. This has approximately the same repercussions as it has in the PC world. C/C++ makes it a bit harder to develop apps, but you gain performance. You also have more "control" of what's going on. In general, through BREW and Mophun you have better access to the phone's native functionality; but this is slowly improving on the MIDP front as well.

c) Market share: MIDP is the hands-down winner in this aspect. There are much more handsets out there that support MIDP as there are for BREW and Mophun combined (just blowing smoke here actually, since I don't have any hard figures, but it's a pretty safe bet).

d) Portability: MIDP is more portable. In theory it should be completely portable, but of course, as has happened with Java on the PC front, this is not 100% true. With different form factors to consider and a big difference in capabilities of different phones, complete portability is even more of a pipe dream. But with some smart designing, you can have the bulk of your code completely portable. And with a basic app, you can have one build running on almost every compatible handsets. With BREW/Mophun you'll need a different build for every single handset. Of course, you can still write your code cleverly enough so that most of your codebase is quite portable.

All in all, for a hobbyist or someone just starting out, MIDP is the obvious choice (because of the $$$).

And one last thing, don't judge the performance of MIDP by your T610. That phone has an absolutely horrible MIDP implementation, specially in anything graphics-related. Most handsets perform much better.

shmoove

PS: Of course that I'm a MIDP developer, with only some limited knowledge of BREW, so my views might be a bit biased.

[edited by - shmoove on April 18, 2004 1:06:57 PM]

There are proprietry things like the two mentioned to date. These probably give better performance and greater control over the device, but at a cost of much less device portability and may not be as robust (i.e. easier to crash the phone with native code (if indeed that''s what they use))

J2ME support isn''t particularly fast on the SE t610, but it does work (you can do simple stuff with it). But in other respects its support is fairly good (UI works, screen has lots of colours etc).

And I guess the tools are probably better for J2ME (there are lots of vendors and some free tools too) (I haven''t used anything for Mophun etc, but I imagine it''s lousy since provided by only one vendor who has no competition)

Mark

Thing is I''m proficient in C, and looking at the SDK, it looks quite easy to learn.

However, because of the portability issues and the wider market base with MIDP, I think I''ll give it a go for now.

I suppose as well that if it runs on my Ericsson, it will run on anything

quote:

---

Original post by OklyDokly
I suppose as well that if it runs on my Ericsson, it will run on anything

---

Not true at all I''m afraid.

Although it is perfectly possible to make games that work on multiple MIDP platforms, it is usually undesirable to do so.

This is because the different screen sizes (/ colour depths, keypad layout etc) sometimes mean you have to implement things differently in terms of game layout, sprite size etc.

You *could* write several implementations of the screen layout and sprite size and choose between them at runtime based on the capabilities of the device, but for size reasons I suspect vendors typically choose not to.

Mark

Oh, and there is one more reason I forgot why MIDP is a better choice when you''re starting up: the community. Tutorials, articles, specialized web-sites, many forums.
On both of the proprietary platforms, you''re pretty much on your own.

And, on the 3 BREW handsets I''ve seen, the performance isn''t any better than MIDP. Mophun games did out-perform MIDP games though.

shmoove

PS: There are firmware upgrades for the T610 that improve the MIDP performance a bit, maybe you should contact your SE dealer.

Are you able to recommend some of these resources schmoove

Thanks for your help

Chris

Sites and articles:
http://java.sun.com/j2me/
http://bellsouthpwp.net/m/c/mcpierce/j2mefaq.html
http://www.gamedev.net/reference/articles/article1949.asp
http://xdobs.com/learning-j2me.html
http://www.benhui.net/
http://www.j2megamer.com/
http://www.microjava.com/
http://www.jroller.com/page/shareme/J2MEResources
http://www.forum.nokia.com/main.html
http://developer.sonyericsson.com/site/global/home/techintro/java/p_java.jsp
https://communication-market.siemens.de/portal/main.aspx?pid=1
http://developers.motorola.com/developers/default.asp

Forums with most traffic:
http://forum.java.sun.com/forum.jsp?forum=76
http://nkn.forum.nokia.com/forum/forumdisplay.php?forumid=3

That should get you going.

shmoove

Im also looking into mobile phone game development at the moment and from my research and experience i have this to share:

1) Java MIDP
Pros: Should be your number 1 choice if you want to support 90% of the phones released in the last year.
Most widely supported cross-platform solution.
Almost all the colour phones shipped in the last 1 year support MIDP.

Cons: Extremely limited functionality. (More on that later)
Extremely slow as compared to natively compiled code for a particular phone.
Unlike the PC where we have JIT, Java is interpretted on handphones and is therefore alot slower.

2) Native code for a particular phone
Pros: Get access to all the capabilities of the phone.(Camera/Bluetooth/etc..)
Way faster than MIDP.
Cons: Limited to only that phone.
Not cross-platform at all.

3) Symbian OS
Pros: Supported by all major Handphone manufacturers.
Nokia/Motorola/Siemens/Sony-Ericsson/Panasonic/Samsung
Phones using Symbian
Likely to be the "Windows" of new/future phones.
Supports coding in C++/Java.
Extremely fast.
Cross-platform across all similar series phones.(Compile once run anywhere including for C++ binaries because they use the same processors)
Get access to all functionality of the phone if coded in C++. (Direct Access to screen/support for Hardware acceleration in future phones with gfx chips)In Java, you still get far more functionality than using MIDP.

Cons: Currently only the newer or high end phones use Symbian OS. Most other phones in the market use custom OS''es.

Currently the only games you could do with MIDP(keeping in mind the lower end MIDP phones) are games where you only redraw a small portion of the screen every frame. Puzzle games/non-action games come to mind.

If you are targetting any of the newer phones, you might as well go with Symbian and code in C++/assembly if you need the speed. Even if you use Java with Symbian, you will get access to DirectScreen blitting support and will get far better framerates as compared to MIDP.

I tried developing for symbian but without a symbian phone, it seems impossible because my program seems to run on the emulator but not on a friends phone. So i am shifting to MIDP for the moment since i own a M55 which is comparatively older.

Basically, if Symbian gets the type of penetration Windows has in PCs, MIDP will pratically become useless in the near future.

quote:

---

Original post by GamerSg
Currently the only games you could do with MIDP(keeping in mind the lower end MIDP phones) are games where you only redraw a small portion of the screen every frame. Puzzle games/non-action games come to mind.

---

Not really true.

Simple action games are possible even on the t610 and work quite nicely if you program them well.

Although the graphics performance is not high, it''s enough to have several small objects moving over a stored background and updated every frame (at a lowish framerate say 10-20 fps)

Hardware double buffering means you don''t need as many graphics operations as you might think. MIDP 1.0 does not (require) support transparency, but most MIDP1.0 colour phones do (including the t610 and some Nokias).

With MIDP2.0, the phones are sufficiently quick that relatively advanced 2d (incl. isometric 3d) graphics should be possible - with loads of things moving around, parallax backgrounds etc.

Of course one problem with all this is display latency (no API gets around this unfortunately). But in some cases it actually creates cool effects.

Mark

Thanks for your advice guys.

By the way, have you noticed that Sony Ericsson have set up a development challenge for the new MIDP enabled phones. Do you think it''s worth entering, or do you think the competition will be way out of a single developers league?

MIDP applets are horribly unportable. You have to do all kinds of special cases, and weird stuff in order to get them to work on multiple SKUs.

The problem areas are:

Key bindings: these are all over the place in Java phones

Sounds: these are all over the place as well. We have like 5 different sound managers: one for each of Sprint, Nokia, Motorola, the S105, and MIDP20.

Screen sizes: all over the place too, but I guess that''s more a function of the number of supported phones than a problem with the environment.

But as far as other environments, I don''t know why BREW keeps getting the shaft - in any discussion about cell phone games, people so seldomly mention BREW. It definitely gets better overall performance than J2ME.

quote:

---

Key bindings: these are all over the place in Java phones

---

Well, there are the Canvas game action codes, you can use constant and just change the declaration, or add an option for the user to define his own keycodes. Not a real problem IMO.

quote:

---

Sounds: these are all over the place as well.

---

If you have a class that handles sounds, it has it''s own interface (which you define), and implement it''s functionality with any of the available APIs, or just empty stubs if there is no API (vanilla MIDP 1.0). Same goes for vibrations and lights. A slightly bigger problem, but still very manageable.

quote:

---

Screen sizes: all over the place too

---

Again, some clever coding and smart use of defined constants (or even calculated at realtime from the screen dimensions) can really ease the portability issues.

One build to rule them all is a pipe dream, but horribly unportable they''re not.

shmoove

quote:

---

Well, there are the Canvas game action codes, you can use constant and just change the declaration, or add an option for the user to define his own keycodes. Not a real problem IMO.

---

Yeah, but Canvas.FIRE is not always the button you would expect it to be. And the soft keys are sometimes there, sometimes not, and sometimes they are mapped to different things. When you need to write different key mappings for each phone, then that means it''s not portable.

I agree that the unportability problems on MIDP are relatively superficial. But just because they''re superficial, doesn''t mean they''re not a PITA.

Here''s a claim that I''m prepared to defend: it''s easier to port a BREW app across SKUs than it is to port a MIDP app. Portability is not one of MIDP''s strong points.

I''m not saying that porting is a walk in the park. Hardly. But the main problems aren''t with the issues you mentioned. You are aware of those issues before you start development and with some care you can glide through them. The same can be said for BREW on this point.
The real problems that arise when porting the applications are much less obvious. Bugs in the different implementation. Issues with memory fragmentation. That''s when things start to get painful. And the same can be said for BREW. I have had plenty of experience porting MIDP apps, so I know what I''m talking about, and from what I saw from the desk next to me (where the BREW guy pounds the keyboard), BREW phones are no better off.
I don''t think that portability is the thing that really sets these two technologies apart. It''s more about available devices (BREW might have an slight edge in the US, MIDP rules the rest of the world); and last and definitely not least, the fact that to deploy a BREW application you have to shell out some serious cash.

shmoove

Ah, stored backgrounds are good because you only need 1 function call to fill the screen, what i meant was scrollable tile-based games like mario which are usually unplayable on MIDP 1.0 phones. I have a commercial RPG game which uses scrolling and i get like 3-5 fps because it has to redraw every freaking tile everytime i move and that just makes the game totally unplayable on my phone. Perhaps it was intended to be played on Nokia phones(usually faster processors).


Eh another thing, does this mean MIDP doesnt even have sound support???




[edited by - GamerSg on April 19, 2004 11:49:34 PM]

You might also want to check out X-Forge, which is a cross-platform game engine and provides environment for creating advanced 2D and 3D games.