Develop easy-to-transplant j2s games

Porting is a problem in the development of the j2-based game. The screen size, buttons, APIs, and performance of various mobile phones are different. It is not easy to run around for a single development. This article briefly discusses how to develop an easy-to-transplant j2_game from several aspects. Each section corresponds to a specific issue.

A Small Size Problem

1. What are the screen sizes? Think of it as a variable!
The first problem is the size of the screen. Mobile phones of different brands and models have different screen sizes. The size changes must be taken into account during rendering. The variables screenwidth and screenheight are regarded as two variables, which are substituted into the formula of coordinates during rendering. In this way, the screen size will change, but the desired effect will not change. For a simple example, to draw a logo image in the center, you only need to set the rendering coordinates to: x = (screenwidth-imagewidth)/2; y = (screenheight-imageheight) /2. Let's take an example of creating a map in an RPG Game. If the tile size is 16*16 and the screen size is 128*128, a screen will display 8*8 tile, however, if you use 8x8 times to draw the tile, the program will die. If the screen size changes (change to a model or use full screen) or the tile size changes, these areas need to be changed. The correct method is to regard the size as a variable. You can define the width and height of tile as a constant. In this way, the number of tile to be drawn is screenwidth/tilewidth * screenheight/tileheight. Now you can correctly display your map on screens of all sizes. There are many such examples, not only the screen size that needs to be considered as a variable, but also the portability of all values that may be changed and defined as variables or constants. In addition, relative coordinates can also improve portability. For example, to draw the number of gold coins in super Mary, we need to display a diagram of the gold coins and then write a number behind it. Well, set the coordinates of the gold coins to gold_x, and the starting coordinate of the numbers is gold_x + width of the gold coins icon + 1. I wrote 1 here, but it doesn't matter. I just want to separate a pixel from the gold coin icon when displaying a number, if we want to move the display of the number of coins from the left to the right, we only need to change the value of gold_x. What if we want to display the number of gold coins on the rightmost side of the screen? Set gold_x to screenwidth-width of the gold coin icon-1-stringwidth (string (number of gold coins )). Well, that's it. This is a pseudo code. The point is that we have calculated the length of the number representing the number of gold coins. Because different machines have different character sizes.

2. What is the text size? Think of it as a variable!
When it comes to text, everyone may be very depressed, because Chinese is generally relatively large, so that the phone is not beautiful. Of course there are also some, the small font of nokias40 looks pretty good. Here I think of one thing. When I set the font to large, the real machine of the motorolav600 displays a small font! Haha, it was originally set to small, but it is a big font. Okay. Let's get started. Since the text size is not equal, we still regard it as a variable. The font class has two methods: getheight and stringwidth, which can help us. If you only use one font in the game, you only need to call getheight at the beginning to record the font height. Of course, remember setfont in paint! Stringwidth can calculate the length of a string, which is very useful because the English font in the mobile phone is generally not of the same width, in addition, when Chinese and English numbers are mixed, the length of the string cannot be calculated by the number of characters * character width. With this function, we can accurately know the length of the drawn string. Here, a typical application is to wrap a line when text is displayed. Using stringwidth, you can calculate whether text needs to wrap. For another small example, I wrote a tool function to display the Left and Right soft key menus.
Public static void drawsoftkeymenu (Graphics g, string leftkey, string rightkey, int color, int style)
{
Drawstring (G, leftkey, 0, canvasheight-mainfontheight, color, style, GLT );
Drawstring (G, rightkey, canvaswidth-stringwidth (rightkey), canvasheight-mainfontheight, color, style, GLT );
}
Of course, you cannot use this function directly. It uses several self-encapsulated functions, but the meaning is quite clear. The coordinates for drawing the left soft key menu are (0, canvasheight-mainfontheight), and the coordinates for drawing the right soft key menu are (canvaswidth-stringwidth (rightkey), canvasheight-mainfontheight) java mobile network [www.cnjm.net]

Java mobile network [www.cnjm.net]

3. virtual screen-great fun and easy to use
The first problem is about the screen size. We can think of it as a variable to solve the problem of varying screen sizes during transplantation. Here is an advanced technique, which is actually very simple :). Is to use part of the screen as your game screen, I call it a virtual screen. Please believe that it is very interesting and useful. It is easy to use a virtual screen, as long as you think of your coordinate range as: x = 0 ~ Vswidth, y = 0 ~ Vsheight. According to the range of coordinates, do everything as you did before, but at the end of the rendering, convert your coordinates to the real screen coordinates. Real_x = x + vsx, real_y = Y + vxy. So what are the advantages of this virtual screen? First, you can use a simulator with a large screen to develop it. You only need to set a virtual screen on its screen. What should I do with the remaining screens? It can be used to display debugging information or something. Of course, you 'd better define it as a virtual screen. That is to say, you can define n virtual screens. Each screen displays its own content, which does not affect each other. In addition to debugging, it is also useful for developing split-screen games.
The virtual screen mentioned above is simply a piece of digging on the real screen. In fact, we can define it completely according to our own ideas. We can define its size at will and define a 1024x1024 screen. You now have a game area of 1024*1024. you can do everything in it, as long as you map the coordinates of the virtual screen to the real screen during rendering: real_x = x/n + vsx, real_y = y/m + vsy. Here, N and m are proportional coefficients.

Summary: This chapter focuses on the size issue. In a word, it will become a variable. This is not only useful for size, but also for all the quantities used during game development. Even if you are sure it remains the same, use constant definition. Don't worry, obfuscators will put all final static inline.

Java mobile network [www.cnjm.net]

2. Write the easy-to-transplant j2s code
I didn't even think about porting it when I wrote the first j2_game. That is why the game is hard to be transplanted. On the other hand, if you have already planned to transplant it, it will be much easier. This section describes code problems. Think about the differences in code between different mobile phones.
(1) different screen sizes
This has been discussed in the first article, but here we are talking about another problem, namely adaptive control. Controls are menus, text boxes, lists, progress bars, and so on. The size of these controls must be adjusted according to the screen size. According to the method described in the first article, take the screen size as a variable and participate in the calculation of the control size to get the correct size (after adaptive ). The second question is how to draw the correct size. It depends on how your GUI is drawn. If you use a line, it is very simple. If you use an image, you may need to change the image. My controls use image tile and draw line combination, so it is easy to change the size. If the widget is larger, you can increase the number of tiled items during painting. By the way, I only use a class to represent these controls and use them in a parameterized way. After all, we should try to use as few classes as possible.
(2) Different APIs are supported.
If your game is limited to midp1.0, you don't have to worry about porting it. In fact, because we often use image flip, pixel rendering, full screen, etc., we often use the vendor API or midp2.0. Obviously, we need to consider the differences between these Apis when porting them. My solution is to encapsulate these Apis by one layer. For example, if I want to use an API that creates a transparent subgraph, a function createsubimg is encapsulated. 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 midp2.0:
Public static image createsubimg (image IMG, int [] imgrect) Java mobile network [www.cnjm.net]

{
Return image. createimage (IMG, imgrect [0], imgrect [1], imgrect [2], imgrect [3], 0 );
}
For different models, this function has different implementations but has the same functions. Therefore, the code using this function does not need to be modified during transplantation. Of course, this method adds some indirect features, which may reduce the performance.
(3) different key code
We know that MIDP provides game action, which has nothing to do with the key code, but this is not enough. We can define our own game action, but first let's define our own virtual key code. I use bits to record the status of each key. Each bit represents a key, and an int has 32 bits. That's enough. When keypressed occurs, I will note which keys are pressed, and when keyreleased is used to clear the bits used by the released keys. A key, that is, a bit in the keyboard status integer, is a virtual key that I have defined. Of course, its value is always the nth power of 2, and it is completely different from the key code, so we need to map the key code to these virtual keys using a ing function. This function is the key to porting. Each model must rewrite this ing function and enter the correct key code in it. You can define the game action based on the virtual key. You can set Keys in the game to make it more flexible. Java mobile network [www.cnjm.net]

(4) Encapsulation Library
If you want to port a line of code from vodlav600 to Nokia N-gage without changing it, encapsulate different libraries for them. In this way, I transplanted ^-^ in 1 minute. My library contains a game framework class (including game loop and rendering functions, keyboard processing, and several tool functions across models ), A graphics group management class (managing image loading, cutting, rotating, rendering, and animation, a little like Sprite in gameapi) and a control class (containing all the controls I need ). These three classes encapsulate all the differences between different models. I need to rewrite these three classes for each model. Of course, most of the Code is the same. In addition, I also wrote a tool to support the graphic group management class. What you see is what you get to edit animations and manage images-of course, this is also helpful for porting.

Summary:
The above several items must be mentioned, but they are only separated. It is mainly to separate the differences to facilitate changes. However, porting is still depressing, mainly because various models have their own bugs, which requires special handling. When writing code, you must think about the porting problem. Even if you don't transplant it yourself, you must think about it for the transplanted brother ----