The picture resources are the coat of the game, directly affecting whether a game looks beautiful. In J2ME game development, the image use is greatly limited due to the two restrictions received by capacity and memory. In this environment, it is more important to handle the use of pictures. This article discloses the basic method of J2ME game image processing from two aspects of capacity and memory.
A reduction of picture capacity
Method 1: Integrate multiple PNG images to a picture. This is the most basic and most effective way to reduce PNG picture capacity. For example, you have 10 PNG images, each 10 × 15, now you can integrate it into a 100 × 15 or 10 × 150 or X × X picture. This large PNG picture has a lot of total capacity than 10 PNG images. This is because the file header of 9 images, the file end data block, etc., and combined with the palette (if the palette of 10 pictures is just the same, save 9 pictures of the palette " Accounting capacity! This is a small number)
Method 2: Reducing the number of color numbers to reduce color is also a way? What I want to say when I decrease? If the capacity is exceeded after the game is completed, the color is reduced in this time, although the picture capacity can be reduced, but the picture effect may not be satisfied. Therefore, in the US working map, it is necessary to determine the number of colors used, and the mobile game is used as a pixel map, which is an image of a pixel one pixel point, so pre-specify the number of palette colors can be done. However, the ultimate use of optimization tools is also useful, sometimes the difference is one or two colors, but the effect is not large, but the capacity can be smaller. Oh, reducing the color is indeed a way.
Method 3: Use rotation as much as possible and flip this without explanation
Method 4: Using the Tonance Sliding Call Technology and Custom Image Format If the first two methods don't meet your requirements for capacity, and your game is just using a lot of color different monsters, then you can try the color toning. Plate technology. In the J2ME specification, the mobile phone can at least support PNG format, each PNG has palette data. If the two images are different, other (including the number of colors) are exactly the same, as long as you save a picture and another picture The palette, which saves a lot of capacity relative to saving multiple images. However, this method is very troublesome, you have to understand the PNG file format, then make a tool to extract the offset of the palette data and the palette data block in the PNG file. The save image is still used in memory. If you want to change the palette, you read the PNG file into a byte array. According to the offset of the palette data block in the PNG, replace the original use with the new palette. Palette data, then create a changed image with this byte array. Maybe you think that the method of saving a PNG and N-copy palette data is a bit waste. At least 1 color palette data is saved! If you pick up the image data directly, add N-shaped palette data, it is not a more capacity. But use the above method, we can also rendering it with DrawImage. If you have custom image format, then you write a rendering function, this is OK, but PUT Pixel is very slow on some machines. Or construct the PNG format data, use image. If you really have to decide to do this, I still have a small suggestion, do not compress the image data, Zip compression is better than you write compression algorithms (see J2ME Game development notes - Compression or no compression). There is a friend on the forum to use the BMP format instead of the PNG format, and the picture capacity in JAR is smaller and a truth.
Secondary reduction picture preservation
1 Picture The calculated memory of the PNG picture does not correspond to the picture capacity. The calculation of the memory occupied by the image is: width * height * bpp. BPP is the number of color bits built into the system. Take NOKIA 6600 as an example, the pixel format is 565 a total of 16 bits. Therefore, a picture of 100 * 100 occupies 100 * 100 * (16/8) = 20000 bytes, about 19.5K memory. The pixel format is a fixed could not change, so there is only the width and high to reduce the width and high to reduce the memory consumed. 2 Reduce the number of image objects can save a large amount of memory to reduce the number of image objects is not equal to reducing the number of pictures. I mean, save an integration map in an Image object, select the image rendering you need from this IAMGE object by SetClip method. However, this method sacrifices a point speed, and each frame is slower than the rendering of the image in the integrated figure image than the rendering of no reduction. But there are not many rendering, such as the elves, using this method. This method has a problem that it is not to release images that are not needed in the integrated map, which is to see your integration. From the perspective of image capacity and memory management, I usually use a secondary integration method. For example, there are n wizards, first integrate all the pictures of the wizards into an integration diagram, get the N-shaped set diagram, and then integrate this N-set map to a larger integrated figure. This is existing in JAR only in an integration map. When using, you can load large integration diagrams to be loaded into N IMAGE objects. This picture of each elf can be managed separately.
3 Use rotation and flip only to save an original image, rotate or flip when needed
Postscript: This article only talks about capacity and memory from the picture, and what is the general method, the inner people can understand, and I can refer to the novice. Reducing J2ME Game Capacity and Memory is indeed a question that is explored, and the picture is just one. Want to have a good effect must be started from the resource code, and this must handle the relationship between capacity, speed, memory, memory peak, wait time, etc., and the final plan is often balanced. result.
