J2ME, Symbian C++, QT or Android :: Why & Where?

"Once upon a time there was a language called J2ME", you will not be surprise if you hear this few years later. But it should not be forgotten that each of these languages have its own context or domain which can vary according to the needs of the customer.

Why & Where...

A well known truth about J2ME is that it is a sandbox language. I.e. It always needs to stand on top of a another language stack (OS) & hence J2ME is always restricted to access some kernel level functionalities of limited devices because of this 3rd party behavior. For instances one can not write an app which can be auto-started in device boot up without using some other party interaction like push registry. Of course by using push registry one can write an app which will auto-start but via a timer, sms or http like interaction signaled by an outsider. Therefore without any interaction auto-start in boot up is impossible in J2ME. Another scenario is accessing device key pad for locking and unlocking purposes is also impossible as J2ME is not allowed to access locking API of the device. Actually J2ME does not even has such an API for locking. One more thing to notice is that every mobile device has a settings programme which is responsible for managing installed applications. In J2ME context you can never write an app to get the control of this settings app which is silently handled as a device kernel level programme.

As mentioned the primery reason for this is J2ME is a third party language pre-configured and installed on top of another core language stack of the device. For example simply consider Nokia mobile phone which claims to support for J2ME. But the fact is Nokia has its own language stack as the core of the device called Symbian.  Symbian OS has its own rich APIs to directly interact with hardware level and other core functionalities of the device. Symbians S40, S60, Symbain 3 are examples for such Symbian OS APIs equipped with SDKs to leverage developers for developing apps. Both the carbide.C++ and the later added framework called QT C++ can be used for writing applications for Symbian OS. Above mentioned impossible scenarios in J2ME can be achieved via these two implementation frameworks.

But as J2ME hides internal complexities from developer, for developing some typical enterprise level apps, J2ME is apparently efficient and easier than using Carbide or QT. Hence language depends on requirements as always. Focusing on Android here is irrelevant because it is that big buzz word everybody talks about these days. To be it as this much of huge buzz, its complete OS stack has played an incredible role. Because of this perfect organization from ground level APIs to higher level APIs in its OS stack, developers have been able to develop apps without considering dependencies, hardware abstractions, library couplings etc. But there is an one little problem with Android. I.e. its fast growing development life cycle. Not like any other OS versions of other devices, Android does not provide long term service for once released version. They tend to grow fast and if earlier version can not tolerate with the later version, bad luck for the users those who have that earlier version of device. But generally people rarely open their mouths up on this.

Therefore Why and Where is a decision made by developers.

Tips & Tricks to J2ME 3D Gaming...

Here I am going to share some experience that I had to face during my short j2me 3d gaming life. Actually I still do many mistakes while coding and consumes several hours sometimes for to catch them. So It is better for me and those who are new to this field to write down some important points which we all forget to focus or neglect to address.

**important:: you better have some considerable knowledge to understand these points because I am not going to explain them in detail.

1. After loading any image or drawing any object or font do not forget to call flushGraphic(). Otherwise No errors will come but relevant images or objects will not draw on the screen.

2. When using Gaming Canvas there are some restrictions regarding key events of the phone according to the way you call gameCanvas’s super class constructor. That means if you call in your constructor as “super (true) “it tells suppress some key events which calls from your class to it’s super class. If you want to assign events for every key then you have to call as “super (false)”. By default gameCanvas support for gaming keys only.

3. When dealing with sprites, specify their proportions correctly. That means if you are going to specify width and height for the sprite, it should be divided in to equivalent segments.

Ex: Suppose you want 10 by 10 sprites to move and total size of your image is 100 by 10. Then when specifying the width you should give 10 exactly to have 10 equal segments. Otherwise image will not load.

4. Use whatever updating code parts earlier than drawing code parts. Suppose in your game loop you first call draw method which takes care of drawing your stuff on the screen and then you call update method. Update method simply update positions of your objects, handle AI etc. If you call update after the draw function then those updates will apply in the next game loop. Actually it does not add much different to the game. But in some cases like low processing power phones it can be felt if your update method is complicated. So it is just better to use this as a best practice.

5. m3g world that you are going to load in to the phone memory can be a large one. It may contain lot of polygons. So when loading it to the screen and rendering it while in the game play, frames might not be smooth enough or game tends to be slow. So use separate m3g worlds and load them only when need. Try to reduce unwanted polygons in mesh objects as much as you can.

6. If you did load worlds as above you should definitely keep remember to null the unnecessary world objects later. Because you load those worlds and extract their objects and add them to a final one world. After that earlier world objects become use less. Otherwise it adds unwanted weight to the game and in some phones it causes to throw out of memory errors.

7. You load m3g world perfectly according to your code. But when you run it it only displays an empty screen with no errors. This is because some textures of your world might be lost or naming mistakes of images.

8. Reduce far clipping frame of your setPerspective method if you want to add some realistic view to the game such as loading distance objects when you are moving towards them. It also adds a little bit of speed to the game.

9. Use image of alphabet font in which fonts have been packed optimally. Use these fonts for menus, alerts and everything rather than using drawFont method because if you use drawFont, that font size and type may vary according to the phone and may not support as well. But if it is an image of course you can call each font separately and create your own messages.

10. Finally do not apply java’s object oriented concept much more. Because if you have written so many classes for each object then your game loop has to switch back and forth for retrieving objects and calling functions. This leads to consume some performance of the game in limited devices.