Developing J2ME games for easy porting

1. Different screen sizes

The main problem here is the adaptive control. The so-called control, is the menu, text box, list box, progress bar and so on. The size of these controls must be adaptive to the size of the screen. According to the first article, the screen size is taken as a variable to calculate the size of the control to get the correct size (adaptive). The second is to get the correct size and then how to draw it out.

It depends on how your GUI is drawn, if it is drawn with a thread, it is simple; if you use a picture, you may want to change the picture. My controls use picture tiling and drawing lines, so it's easy to resize. If the control is larger, the number of tiles can be increased when drawing.

By the way, these controls I only use a class representation, uses the parameterized method to differentiate uses, after all, we should try to use the class less.

2. The supported APIs are different

If your game is limited to using Midp1.0, then you don't have to think about it when you transplant. In fact, because we often want to use the image flip, pixel drawing, full-screen, and so on, often use the manufacturer API or Midp2.0. Obviously the porting should take into account the differences in these APIs.

My approach is to encapsulate these APIs in one layer, such as I need to use an API to create a transparent child graph, and then encapsulate a function createsubimg. This is the Nokia version:

public static Image createSubImg(Image img,int []imgRect){
Image subImg = DirectUtils.createImage(imgRect[2],imgRect[3],0);
subImg.getGraphics().drawImage(img,-imgRect[0],-imgRect[1],20);
return subImg;
}

This is the Midp2.0 version:

public static Image createSubImg(Image img,int []imgRect){
return Image.createImage(img,imgRect[0],imgRect[1],imgRect[2],imgRect[3],0);
}

For different models, the implementation of the function is different, but the functionality is the same, so code that uses this function needs no modification when porting. Of course, this adds some indirection and is likely to degrade performance.

3. Different key code we know that MIDP provides the game action, not the key code, but that's not enough, we can definitely define our own game action, but first let's define our own virtual keypad. I use a bit to record the status of each key, each bit represents a button, an int has 32 bits so enough. When keypressed occurs, I write down which keys are pressed, and also when keyreleased, the bits of the loosened keys are used 0. A key, which is one of the digits in the keyboard state integer, is a virtual key that I define. Of course its value is always 2 n times, and key code completely does not lap, so we need to use a mapping function to map key code to these virtual keys. This function is the key to porting, each model to rewrite the mapping function, fill in the correct key code. You can define the game Action on the basis of the virtual key, support to set the key in the game, so it is more flexible. (4) Encapsulation Library If you want to migrate from MotorolaV600 to Nokia N-gage without changing a line of code, then encapsulate different libraries for them. That's how I finished the transplant in 1 minutes. My library contains a game framework class with game loops and rendering functions, keyboard processing, as well as a number of tool functions across models, a graphical group management class (manage pictures of the loading cut rotation and animation, etc., somewhat like the sprite in Gameapi) and a control class (containing all the controls I need). These 3 classes encapsulate all the differences in different models, and I need to rewrite the three classes for each model, and most of the code is the same. In addition, I have written a tool to support the graphical group Management class, WYSIWYG edit animation and management picture, of course, this also helps to transplant. Summary: The above several, must say, nothing more than the dismantling and to. The main is to separate out the difference, easy to change. But the transplant is generally still relatively depressed, the main reason is that various models have their own bugs, which requires special treatment. When you write code, you must think of a good transplant problem ah!