(keitai-l) Doja limitations

From: Douglas MacDougall <mac_at_gnajp.com>
Date: 11/30/01
Message-ID: <005501c1799c$359375c0$060119ac@gna.gnajp.com>
Hello,

I am an American CTO of a Japanese corporation. I've read a lot of the archives but this is my first
time posting. We develop web applications, but have just begun probing the iAppli market. I am
trying to develop a tile based rendering engine, but cannot find any tolerable way to do this with
the Doja Graphics class. The project requires that the user download lots of scenes and I have
developed a method to reduce the packet transfer to the bare minimum, but there is no way to render
the graphical data except using Graphics.drawLine(). I read the specs on the KVM and it basically
states that the DoJa layer provides an interface to the KVM which implements the native calls.

What I need is a lower level access into the phone API. From what I have read in the public docs
this is not possible, but perhaps someone here has hacked in deeper. I haven't had enough time to
research this field thoroughly but tentatively I can only find two solutions. One is that there is a
way to override the DoJa supplied classes and get direct access to the KVM calls to the native
firmware. The other less effective method would be to bypass the .java->.class step and just write
bytecode using a hex editor. By optimizing the bytecode to do what would likely generate compiler
errors, you may be able to speed up the code enough to actually render separate tiles.

What I want to be able to do is to generate images from within the iAppli by decoding tile data read
from bitstreams. I can do this on any hardware that supplies a decent graphics API, but with DoJa I
so far have only been able to draw an image which is read from a file (either resource:// or
http://). This is highly inefficient and completely unacceptable for the level of application I am
attempting to build. By the time the maps, tiling and sprites are loaded and rendered there won't be
enough app memory space to actually do anything with the graphics.

I am not a fan of Java and never use it in any other development project, but as far as I can tell,
none of the phones provide a native API. Why the phone makers don't use assembly or at least a tight
c api is completely beyond me except that Java carries marketing weight. The whole "standards" theme
is a joke considering the fact that near every phone has different size, color, memory and native
calls. In any event, that debate is a lost cause. Perhaps some of you who have more Java experience
know of ways to take it to the limits?

If there is anyone out there developing bleeding edge iAppli's please respond. What are the
limitations of the DoJa model, and can they be overridden? Is there any way to build your own
instance of an Image object without using MediaManager? Does anyone know where I can get the KVM
specs, I searched around sun.com but to no avail. Obviously the hardware makers have this info, so
it must be floating around somewhere. I plan to email Sun on this one, but if anyone here has them,
I would love a peak.

Douglas MacDougall
GNA Inc. Japan



[ Need archives? How to unsubscribe? http://www.appelsiini.net/keitai-l/ ]
Received on Fri Nov 30 14:53:28 2001