Skip to main content

LIME blues

1 reply [Last post]
msc2000
Offline
Joined: 2008-05-26
Points: 0

Hi,

I'm trying to integrate our JSR 184 & prototype JSR 297 implementations into phoneME on Win32. I want to use the phoneME plugin in JME SDK 3.0 to run and test everything. To do so I need to understand the MIDP graphics set up and how the pixels get delivered to the screen. I have the following difficulty.

The Javacall APIs javacall_lcd_init and javacall_lcd_flush (& etc.) are making what appear to be RPC calls through LIME. I write "appear" because one of the parameters passed to the "drawRGB16" RP is a pointer to the off-screen buffer which was allocated by a regular malloc call. I have not been able to find the recipient of these LIME calls. I need to modify the part that gets the pixels to the screen as well as the MIDP graphics so need to understand the complete chain.

Is the recipient of these LIME calls the binary only emulator.exe (one of which is included in both the phoneME emulator package and the JME SDK package)?

If not, where is it?

If so, can I use win32app_export.c (which looks like it will display the emulator screen itself) instead of jcapp_export.c and still run with the JME SDK IDE? How do I build and run using win32app_export.c?

There are no details of the implementation of jcapp_export.c and use of LIME in any of the phoneME or commercial documentation or this forum.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
msc2000
Offline
Joined: 2008-05-26
Points: 0

To answer my own question:

The lcd functions in jcapp_export.c are indeed sending screen data to the JME SDK emulator.exe, which is a Java application running as a separate process from the phoneme_feature CLDC VM. emulator.exe displays the data on the screen.

I now have our JSR 184 implementation fully functional in phoneME. In this integration our Renderion OpenGL ES 1.1 implementation renders directly to the offscreen screen & Image object buffers of the CLDC VM. Unfortunately the work is a bit wasted. It is only useful for internal development as this integration is very different than we will need in a real device.