Android and javase game engine LGame-0.3.1 edition officially released

LGame-0.3.1-Update 2011-07-03:

(Contains the source code, jar, and nine different types of game examples ):Http://loon-simple.googlecode.com/files/LGame-0.3.1.7z

1. Since version 0.3.1, Image Rendering in javase and Android versions has been converted to OpenGL (ES). In most Android models that support gles hardware rendering, the framework performance may be improved by at least 20%-50%. However, in a few models that only support gles software rendering, the performance will be reduced by 20%-50% (including Simulator-| )......

2. In order not to damage the original framework structure and give full play to OpenGL Performance, the rendering method is changed as follows on the basis of retaining the original limage, lfont, lcolor, lgraphics and other drawing classes:

2.1. The original basic game canvas is changed from lgraphics to glex. This class is integrated with common rendering APIs of OpenGL (es), javase, and javame, even if users do not fully understand the OpenGL rendering mechanism, you can also use lgraphics. In addition, although this class no longer allows direct rendering of Android bitmap and javase images, it can directly render limage like the old lgraphics, and the new dedicated texture class ltexture, it can also be generated through lpixmap, limage, bitmap, and image conversion.

2.2 To adapt to the OpenGL color mechanism, the old version of the lcolor class is not allowed to be directly used on glex, but only to use the new glcolor class. However, this type of API is actually the same as the original lcolor (the internal part is to divide the color component by 255 and convert it to the floating point value used by OpenGL ||| ). Finally, the old lfont is still used in the glex class, and there is no difference between the other part and the old version.

3. The Android and javase Human-Computer Interaction device interfaces are encapsulated in a unified manner. All Keyboard Events are encapsulated in the lkey class, And all mouse events are encapsulated in the ltouch class, the WP7 version will be released soon.

4. To prevent the framework from expanding too quickly, the lgame core jar no longer has a built-in open JDK Geom package since version 0.3.1, which will slightly reduce the lgraphics class functions of Android, however, since the core rendering class has been converted to glex, the impact on the old version users can be very small. In addition, because the image shape automatically generated by lgame depends on this package, it is not abandoned, but transferred to the physics extension package.

5. To reduce the frame size as much as possible, the structure of this version of the Framework is slightly changed. All the shape components under the original map package are placed under the old Geom package, and the original window package is renamed as component, all the classes in the original window package and its sub-packages are included in this package, and four new component packages including task, input, OpenGL, and particle are added and related classes.

6. Fixed all detected bugs in earlier versions and fine-tuned the frame display mode to meet the running requirements of most models as much as possible.

Precautions for using opengles:

1. opengles is not a panacea for the Android system. Even if the code is optimized well, it does not mean that all Android phones can achieve the same ideal speed and effect. In fact, the efficiency of opengles is only reflected in the mobile phone models that support hardware rendering, while the machine that only supports software rendering is completely powerless. For this mobile phone, gles rendering speed is even less efficient than canvas drawing.

Speaking of the most popular gles software rendering implementation on Android phones, Google's Android pixelflinger (currently up to version 1.4) is first introduced ), if you see "android pixelflinger" in "only" when you get the gl_renderer parameter through the opengles of the real machine, it means this machine must be out of connection with gles development. Please use another mobile phone, you can also change it back to canvas Development (you can also make two versions for your choice ). In fact, you can see android in some low-end models of HTC, some low-end models of LG, some low-end models of archos, and all models that use an early Chinese star solution.
Pixelflinger "appeared separately". If anyone chooses gles for game development on these low-end mobile phones, the choice would make the carriage-drawn train run as horrible.

Furthermore, gles hardware rendering provided by different vendors also has different effects to varying degrees (do not think that all vendors are fully compliant with OpenGL specifications ), younger brother here recommended http://www.glbenchmark.com this more authoritative site for related queries, which provides the vast majority of common intelligent machine GL, EGL parameter list, and with a variety of models of real machine FPS test data. You need to know that "a thousand miles are missing". If the OpenGL Performance of the mobile phone itself is dog shit, most of the things running on shit will become shit.

2. Using opengles for game programming means that you must discard the use of simulators in most cases, but can only develop with a real machine or a PC framework. Because the android simulator is based on Android pixelflinger by default, the gles rendering speed of the software is not fast. When it comes to the simulator, you will be more angry with the computer.

3. To take care of the canvas Implementation of the old version, the current version only completes the OpenGL of the lgame rendering kernel, that is, the old version of the API is basically continued, and only the specific implementation code of the function is changed. However, since OpenGL and canvas have some differences in the operating mechanism, rendering efficiency is obviously not the optimal choice. Therefore, there is still a huge space for optimization in the future. (For example, a x bitmap image is displayed on a canvas in any model, although it will be slow, it will never compress FPS to a single digit. However, in some models, if a texture of this size is loaded with gles, it is likely that the FPS will be lower than 10 in an instant, but the same machine will run several x512 textures at the same time, the speed is still swaying at 50-60, which is the embodiment of the difference. In other words, 0.3.2, one of the key points of improvement is "automatically Merging Small images into a unified texture, and automatically decomposing large images into a reasonable number of Textures ")

4. the canvas Implementation of the old version is not completely abolished. The canvas version is no longer updated as a special version (that is, the version is 0.3 no matter how it is changed ), if you use gles for development is not smooth, you can switch back to the old version. It still provides bug fixes and development support ......

PS: this revision does not affect the code structure of the original program, so the original examples can all be used in the new version, such as the srpg example released not long ago (such as running images in the new version ).

In addition, this revision adds an additional act game example (in fact, it was modified from a similar example posted in the previous blog post ......), In view of the problem that many netizens have asked about sound effect playback, this example is used for demonstration (running images in the new version are shown in figure ).

(Contains the source code, jar and nine different types of game examples): http://loon-simple.googlecode.com/files/LGame-0.3.1.7z

------------------------------

In addition to the Android version, the lgame WP7 and iPhone versions are also under development. The WP7 version directly uses the xNa package, which saves time for porting exceptions. In addition, the syntaxes are basically the same, so there is no problem with the release at the end of the year; the iPhone is used for C/C ++ Migration (the objective-C syntax is really intolerable |). It is equivalent to restructuring the original code and is expected to be completed by the beginning of next year.

There are also two platforms in preparation. One is HTML5. Considering the future development of webgl technology, the demand for web game engines will increase, and the complexity will increase. At this time, it is time to take the initiative; the other is javafx. The development direction of this tool since the reconstruction of Version 2.0 is unknown. If Oracle is still playing hard, I am pessimistic about it, let's look at Java's face preparation ......

PS: I haven't been online for a long time. I found that the csdn Blog system has been revised and won't be used. If the performance of my younger brother's article is incorrect, I would like to look at Hai Han and learn more ......