Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Bryan maybe there's not icon on the midlet ?

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I tried it again with sudo gainroot and now it has an image.

Maybe you need to add "sudo" somewhere in your script.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Did you add savegame support in the last version? because now it saves the game :)

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Davy: did u add the sound support? becouse mine doesnt work

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

No sound support yet from what I can tell - there was a dummy hack to avoid crash.

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I looked into the issue with this game (which was not that obvious without having access to the source code).

Based on my observations, this seems to be an issue with the game itself rather than with the VM. The game is not capable of resizing its canvas and changing the layout whenever the available screen real estate changes (e.g. display height increases when going full screen).

I think the game basically detects the width and height at the start of the game, and then assumes they stay that way. Perhaps the midlet was targeted to a particular device for which this is true, but for the N900 this assumption is not valid.

The only fix for the game is to have it support dynamic re-layouting (like e.g. Opera Mini which also uses a canvas to render its stuff).

Cheers,
Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

I did not do anything particular to support savegames. Perhaps it was a side effect of another bug fix. I am guessing this game is using record stores to save games statuses, and that this previously failed due to write permission errors.

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

No, to add proper sound support I have to implement the JSR 135 spec (at least the audio playback part), and this takes (a lot of) time.

For now, the implementation only provides dummy methods so that at least some games can be played without sound (otherwise they might complain about missing classes and missing methods).

Davy

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

Can we help you in some way? you are doing a big work, we want to have a nice JVM (yet it is) but we miss some features, we want to help you in some way becouse you need time and you cannot do everything alone

Re: [TESTING] PhoneME Advanced (Java Mobile) prototype release
 

The biggest problem is there are many JSR specifications, but only few open source implementations. Many others do not exist or are closed source (the Mobile 3D Graphics API JSR 184 comes to mind which is often used in high end games). For those for which we do have an implementation, there is usually only an implementation for Windows or Linux on x86 systems. The biggest amount of work is making this work on other mobile platforms. Based on my experience with WinCE/Windows Mobile, Android and now Maemo, I can say that the most difficult part is bridging the JSR APIs with the underlying platform libraries (for the N900/N9 this would be a.o. Qt4, liblocation, etc.) and making sure that:

1) it works reliably for not just one midlet but for all midlets (in the sense that midlets may have different ways to achieve certain things and you have to support them all) as I don't have access to the Java ME Technology Compatibility Kit to test for compliance.

2) you have a framework in place that allows you to bridge new JSR apis more easily with the platform APIs. This decreases the amount of work later on if you add support for new APIs, but requires more effort at the start the get the proper foundations and abstractions right. It also helps with portability to new platforms or new platform editions.

Now, for this you need to be somewhat familiar with JavaME specs and how to compile and integrate new (platform specific) stuff in phoneME so that all features are available from Java source code (i.e. the midlet code), while ensuring there is no (significant) performance bottleneck. I have learned this the hard way through trial and error during the several years I was doing the WinMo and Android ports. Mapping Java ME text rendering methods on those that Qt4 provides is a notable example. You need to figure out how to write text on a 16-bit RGB array while avoiding copying back and forth large RGB buffers between JavaME and Qt4 because it slows down the overall rendering process.

The best way for the community to help me out is to help with the testing. I now have a N900 which at least helps me to test for performance bottlenecks (thanks again donators). However, I only use a few (freely available) midlets. So if the community can help with testing other midlets as well, that would be nice. The biggest problem is usually that we do not have the source code of commercial midlets to figure out why they don't work. Sometimes they make use of an API that is currently not yet supported, sometimes it is a bug in my port.

I am also much interested in feedback from N9 owners, because there seems to be some subtle differences with this platform compared to the N900. Various libraries (e.g. those for GPS that I need for JSR 179/Location API) are either not available or do not work on the emulators. So I only have the N900 to test on and hope that they will also work on the N9.

Another way to help me integrate new features is to provide pointers to small working examples in C or C++. For example, to support JSR 179, I need to know how to access the GPS. I spent some time looking for simple minimalistic applications with source code that I can easily compile showing how get to the data. Such example applications make it a bit easier to figure out how to integrate this code in the JavaME vm. So just pointers to the API documentations of Qt4 don't really help (I can google myself :-)). Also, I like to avoid dependencies as much as possible (so e.g. no pointers to GPS daemons written in Python). Too many components in the middle cause too much overhead and latency, and makes it very difficult to pinpoint the location of a bug when a midlet does not work the way it is supposed to. At this point I already have such examples for GPS and simple (file based) audio playback. So hopefully support for these features will soon be integrated in next release. Stay tuned!

Damn, this post is longer than I intended it to be :-)

Cheers,
Davy