|
Hi!
I attended the Sun Tech Days in Stockholm again this year. During your Java ME (J2ME)
presentation I was pleasantly surprised to see my old MIDP-Man game being used to
showcase Nokia's new phone. At the time I couldn't come up with any good question,
so I hope it's OK to ask one or two now instead.
But let me start with a little something that pretty much sums up my feelings about
Java ME (J2ME) programming.
Sun: "Here you go -- a free copy of our Micro Gourmet Meal Development Kit (TM). You
can use this to prepare dinner for our guests that will arrive tonight."
Developer: "Cool! What ingredients do I have to work with?"
Sun: "We're proud to announce that you have both a pound of instant coffee and a
bucket of apples."
Developer: "Just coffee and apples? Well, I guess I could make _something_ out of
that."
Sun: "As long as you don't forget that the same meal has to be suitable for any type
of guests -- from sumo wrestlers to infants."
Developer: "Uhm ... that makes it kind of difficult, but I'll see what I can do."
Sun: "And by the way, some of our guests are allergic to apples."
Enough has been said about the shortcomings of the MIDP standard, particularly its
very limited graphics manipulation tools. That was the first obstacle for MIDP
developers and since you were using MIDP-Man (from November 2000) as an example
at the January 2002 Tech Days, a reasonable estimate is that the fundamental
weaknesses of MIDP have cost Sun a year's worth of goodwill and development
efforts.
The second obstacle was made very clear by Nokia's representative. Developers have
to make sure that their MIDlets look good on anything from a full-color 640x200
display down to a stamp-sized black-and-white 96x55. Though it's not impossible, it
does require a ridiculously huge effort considering the limited quality of the final
product. And I'm somewhat discouraged by the fact that only one or two of Sun's own
sample MIDlet games work on all the emulated devices.
I became aware of a third obstacle when I started collecting emulators from other
companies. Siemens' SL45i felt particularly interesting, because like the Motorola i85s
it's something that exists today and will probably be one of the most important
platforms to support. The problem is that it doesn't work -- or rather that it doesn't
work the same way as other platforms.
Attached below is a combined screenshot of the SL45i emulator next to the
Java ME (J2ME)WTK-emulated i85s. I've run the same little test MIDlet on both devices, which
loads a relatively wide image, draws it onto another image the size of the display and
then draws the result on the screen. The i85s behaves normally, but drawImage on
the SL45i _scales_ the image to fit the drawable area. Although that may be practical
in some cases, it's not how most other MIDP platforms work and -- more importantly --
it's not how most developers _expect_ Java to work.
The ability to draw a larger image onto a smaller one and get it _cropped_, not
scaled, is a fundamental requirement when making the type of games that become
size independent by scrolling the playing field. (As you might expect, MIDP-Man
doesn't work properly on the SL45i. The labyrinth gets scaled down and squeezed
into the top left corner, whereas the ghosts and Pac-Man keep their original sizes and
positions.) It's also the only way around having to store and load every individual
image in a game as a separate PNG file. Lots of people use that technique in games
that are being developed today. All of them will look like hell on a Siemens phone.
There are other graphical discrepancies as well. For example, on an actual SL45i
device, the drawString method wraps text to fit the drawable region. On the SL45i
emulator and most other emulators it doesn't.
My question to you is, what is Sun doing to fix this?
And as a follow-up question, what can the consumers do to put some pressure on
manufacturers of mobile Java devices? If I buy a Siemens phone, do I have the right
to a refund when the KVM consistently misbehaves?
Sincerely,
Karl Hörnell
| 
