Image Processing in j2s games

Image resources are the coat of a game, which directly affects whether a game looks beautiful. In the development of a j2-based game, image use is greatly restricted due to the limited capacity and memory. In this environment, it is even more important to handle the usage of images.
This article describes the basic methods of image processing for the game based on the size and memory.

1. Reduce image capacity

Method 1: integrate multiple PNG images into one image.
This is the most basic and most effective way to reduce the size of PNG images. For example, if you have 10 PNG images, each of which is 10x15, you can integrate them into a 100x15, 10x150, or x image. The size of this large PNG image is much smaller than the total size of 10 PNG images. This is because nine image file headers, end data blocks, and so on are saved, and the color palette is merged (if the color palette of 10 images is exactly the same, this saves the size of the 9-picture palette! This is not a small number)

Method 2: Reduce the number of colors
How can we reduce the color? What I want to say is when to subtract and who to subtract. If the game finds that the capacity exceeds the limit, the optimization tool is used to reduce the color. Although the image capacity can be reduced, the image effect may not be satisfactory to you. Therefore, the number of colors to be used must be determined during the construction by the artist. Mobile Games use pixel maps, that is, images from one pixel to one pixel, therefore, you can specify the number of colors in the color palette in advance. However, the final optimization tool is also useful. Sometimes the difference is one or two colors, but the effect difference is not big, but the capacity can be reduced. It is indeed a method to reduce the color.

Method 3: Use rotation and flip as much as possible
This does not need to be explained.

Method 4: Use color palette technology and custom image format
If the first two methods do not meet your capacity requirements, and many monsters with different colors are used in your game, try the color palette technology. The cell phone must support at least images in PNG format. Each PNG has a color palette. If the two images have the same color (including the number of colors, you only need to save the palette of one image and other images, which saves a lot of capacity compared with storing multiple images. However, this method is quite troublesome. You need to understand the PNG file format, and then make a tool to extract the offset of the color palette data and the color palette data block in the PNG file. The image is still used for saving images in the memory. If you want to change the color palette, read the PNG file into a byte array, according to the offset of the color palette data block in PNG, use a new color palette to replace the original color palette data, and then use this byte array to create an image after the color change. You may think it is a waste to save a PNG and N-part color palette data. At least one more palette data is saved! If we extract image data directly and add n pieces of color palette data, it will not save more capacity. However, with the above method, we can also use drawimage rendering. If you customize the image format in this way, you only need to write a rendering function. This is fine, but the speed of put pixel is very slow on some machines. Alternatively, you can construct PNG data and then use image. if you really want to do this, I have another small suggestion: Do not compress the image data, zip compression is better than the compression algorithm you write in most cases (For details, refer to the Development notes of j2_game-compression or not compression ). A friend on the Forum mentioned using BMP format instead of PNG format. It is also true that the image size in jar is smaller.

2. Reduce memory occupied by images

1 Calculation of memory occupied by images
The memory occupied by PNG images does not correspond to the image capacity. The memory occupied by the image is calculated as: width * height * BPP. BPP is the number of built-in color digits. Taking Nokia 6600 as an example, the pixel format is 565 in a total of 16 bits. Therefore, a 100*100 image occupies 100*100 * (16/8) = 20000 bytes, which is about KB of memory. The pixel format is fixed and cannot be changed. Therefore, only by reducing the image width and height can the memory consumption be reduced.

2. Reducing the number of image objects saves a lot of memory
Reducing the number of image objects is not equal to reducing the number of images. I mean, save an integrated graph in an image object and use the setclip method to select the image rendering you need from this iamge object. However, this method sacrifices a little speed, and each frame is slower than the rendering speed without any reduction in the image of the integrated image. However, it is okay to use this method for rendering with a small number, such as genie. Another problem with this method is that you cannot release images that are not needed in the integration diagram, which depends on the degree of integration. From the perspective of image capacity and memory management, I generally use secondary integration. For example, if there are n genie, first integrate all the images of each genie into an integrated graph to obtain n integrated graphs, then integrate the n Integration diagrams into a larger integration diagram. In this way, only one integration graph exists in the jar. When using this function, you must first split the large integrated graph and load it into N image objects. In this way, the images of various genie can be managed separately.

3 use rotation and flip
Save only one original image and rotate or flip it if needed

Postscript:
This article only talks about the capacity and memory from the aspect of images. All the points mentioned here are common methods. You can understand them at a glance and refer to them for reference. Reducing the memory size and memory size of the game is indeed a question worth exploring. The picture is only one of them. To achieve better results, you must start with resource code and other aspects, and the relationship between capacity, speed, memory, memory peak, wait time, and so on must be well handled. the final solution is often the result of balancing various factors.