×

Porting

  1. The Android version of the game uses Activity and SurfaceView classes to start the game and to draw to the screen. These were mapped to MIDlet and GameCanvas classes in Java ME.

  2. The Android version uses Activity#onSaveInstanceState(Bundle outState) method for saving the state of the game. In Java ME, RMS is used.

  3. Android activities have an options menu, but Java ME does not provide any similar functionality, so a new menu screen was implemented.

  4. In Android, Bitmap.createScaledBitmap method can be used when bitmaps are scaled. Java ME does not provide any methods for scaling bitmaps, so some custom algorithms were implemented.

  5. Canvas#rotate is used in Android to draw rotated images, but in Java ME canvas or images cannot be rotated. In this project only one bitmap needed rotating and the number of steps was small, so the image was rotated in an image editor and the game just loads all the rotated images.

  6. The background image used in the Android version was too large for some Java ME devices, so it was cropped and modified to a smaller size. Also some other images were modified to better support Java ME style.

  7. The original fonts are a bit unclear when the resolution is small, so a new font was created.

  8. The Android version uses ogg files for sounds, but Java ME does not support ogg, so all the audio files were converted to wav files. Java ME also has a totally different logic for playing audio files, so the whole sound manager was rewritten.

Figure 1. Option menu in Android (left) and settings menu in Java ME (right)

Figure 2. Background in Android (left) and in Java ME (right)

Figure 3. Original font (left) and new font (right)

When porting a game which has been implemented with Java on Android, the game logic probably does not need that many changes. The main differences are how the application is started, how user's input can be mapped to the game logic, and through which classes drawing to the screen is done.

Conclusions

  • Change how the application is started; instead of Activity class, use MIDlet class.

  • If Android specific control items like menus are used, implement menus to Java ME port.

  • In Android Surfaces are used to draw directly to the screen, in Java ME GameCanvas can be used.

  • Java ME does not provide real time scaling of images, so everything needs to be scaled in initialization.

  • Custom scaling algorithms must be used in JME, as the platform does not provide any.

  • Java ME platform does not provide utilities for rotating images (except in 90 degree steps), so if the game needs to rotate sprites, code changes are needed.

  • Screen resolutions are usually smaller in Java ME, so if graphics contain any fine details, adjusting might be needed.

  • Java ME devices do not usually have as much memory as Android devices, so resources might need to be downscaled.

  • Some audio formats supported in Android are not supported in Java ME, so re-encoding might be needed.

  • Playing sounds is simpler in Android, as there is more memory to use and sound manager is more abstract, so playing sounds might need some re-designing in Java ME.

  • In Android, saving the state of the application is usually necessary, as many things can affect the life cycle of the activity. In Java ME this is more dependent on how the game works should the state of the game continue when user exits and restarts the game. If saving the state is needed, RMS can be used for saving game data. Usually this feature needs to be re-implemented in Java ME.


Last updated 24 October 2013

Back to top

Was this page helpful?

Your feedback about this content is important. Let us know what you think.

 

Thank you!

We appreciate your feedback.

×