Talk about what the younger brother has done recently (lgame WP Development Progress Report)

The time passed so fast that it was approaching the Lunar New Year in a twinkling of an eye, and the younger brother did not show up on his blog for a long time. He took this opportunity to get out, so that he would not be misunderstood to go back to his hometown to get married ......

In fact, the younger brother did not appear recently. It does not mean that he gave up this blog, but it does not mean that the updates of this blog will be slow. On the contrary, the younger brother has not been no longer active recently, but has been secretly engaged in conspiracy tricks (^ )~ The SVN javase and Android version of The LGame-0.3.3 have been updated several times, the document also secretly write a part, C # version of the extension package is also soon written (the core package was completed last year ), the C/C ++ version is nearly half done. After all these steps are done, the younger brother will have a hard time working on the Internet.

Two lgame architecture sketches in this document:

Next, let's talk about lgame's WP version, namely C.

Actually mentioned lgame C # version, but is a lgame for xNa version, referred to as "lfx" (version and lgame Java latest version of synchronization, the first version is the LFX-0.3.3 ). Because this version is encapsulated in xNa at the underlying layer, it can be used not only on the WP platform, but also on Windows or xbox360 environments. (Mono can be used in a wider range ).

The following table lists the differences between C # and Java:

1. C # is not a cross-platform version of Java syntax, but an API-level architecture migration. Therefore, although it is consistent with the basic architecture of Java, the differences in details still need to be handled by itself (for example, in C #, the first letter of the function is capitalized, the heavy load method, and common data types are used, keyword ). Later versions, the younger brother will provide syntax escape tools to enable syntax interchange between Java and C.

2. C # does not have all Android-specific APIs (-_-| ......), However, most commonly used Java APIs can be called through the javaruntime class library provided by this version (the function is counterfeited and there is no mandatory requirement if it is not used, so more than 150 kb of code is used here ).

3. the C # core package does not use any support libraries that are not introduced with references by default, so as to avoid problems when generating windows or xbox360 games. For example, the C # version of the store package is implemented using system. Data. LINQ, and the reference does not exist by default. Therefore, the reference is temporarily excluded from the core package and exists as a separate package.

PS: in this regard, the younger brother may recently move the store package code of the javase version here, use isolatedstoragefile to implement another text storage, and then let the two implement automatic matching. That is, the environment allows the use of datacontext, and the use of plain text when not, so that you do not have to external. However, there is an improvement compared with the Android version, that is, the C # core package directly has a built-in box2d interface, without calling the extension package (only the box2d API used by the Android version, use C # to rewrite the implementation ).

4. The default screen size in the android lgame is 480x320 (The vertical screen is 320x480 ), the C # version is changed to 800x480 (to take care of the default size of the WP simulator and the requirements of the Microsoft Food Market). to transplant the android project, please use the maxscreen function to revise it, otherwise, the screen size of the lgame C # version will be different from the screen size of the Android version directly transplanted (in fact, because the current examples are all transplanted from the Android version, therefore, during the running of the porting example, all images are scaled, that is, maxscreen (480,320) is set )).

5. C # version will not have any gles interface (this is something from Microsoft ......), The glex class cannot return gl10 or gl11 calls for Android, but only graphicsdevice and spritebatch (however, there are still common OpenGL interfaces ).

6. In fact, using Version C # Of lgame never means giving up xNa, because Version C #'s execution class lfxplus is the subclass of game, its APIs include the lgame Android version lgameandroid2dactivity and xNa Microsoft. xNa. framework. all functions of the game class can perform normal xNa operations and switch freely between them and standard lgame operations (C # provides a special xnagame class, the API and the standard xNa game class can be switched directly like switching screen ).

7. Due to environment restrictions, C # is more difficult to configure than Android. Therefore, an xnaconfig class not available for Android is added to C, it is used to simplify the process by pre-configuring resources, in order to easily manage resource file switching such as spritefont, which will be detailed at the official release.

Shows the structure of the C # initial class code (because lfxplus is a subclass of game, inheriting lfxplus is equivalent to inheriting game ):

Shows the C # screen structure:

Shows the actual game running screen (avg module running ):

The most depressing aspect of WP is that the feature of closed space forces people to only put extra resources into a network or xap file (compile the file generated by the WP project, that is, xap, like Android APK), but it is more difficult to set up than Android or IOS, because in the WP environment, the simulator will play "system. methodaccessexception. load, but this product does not support text and compressed files. |) Many resource loading methods are not available at all, although it is likely due to the permissions of the simulator, however, the younger brother is not at ease (he is not sure about Microsoft's conspiracy ......), Currently, we have to follow the minimum environment. lgame will only support loading declared resource file data streams.

That is to say, C # version lgame must manually declare the compilation type of the resource (that is, load non-content. load supported, such as texture, spritefont, model and other types of resources), in order to load data normally (including def. loon file ).

Specifically, lgame data stream loading supports "build action" to set resources to be built in the content or resource mode. However, pay attention to the following two points:

1. If the resource type is set to content, the copy output directory cannot be do not copy. Otherwise, the resources cannot be packaged into the xap generated by compilation.

2. If the resource type is set to Resource, system must be introduced. windows support (this support library is loaded by default for standard WP applications, standard Silverlight applications, and even Silverlight and xNa hybrid applications. This is not supported by standard xNa by default, by default, the younger brother is afraid to store Resources in the DLL, for fear that cross-platform problems may occur, or there is no need to configure additional resources for deployment). Otherwise, the DLL files cannot be read.

3. If you drag or add a non-standard file directly to the automatically generated content project (this item is automatically generated by Microsoft when an xNa-based WP project is created for comrades who have never used WP, for storing resources, compilation may fail. (the default content project of WP can only introduce files supported by several pipelines. I have to say, WP has been granted permissions by Saipan ). Therefore, the above operations are recommended in the main project.

PS: however, if you run resource compilation in content mode, the directory is consistent with the content folder (that is, you can create a "content" folder in the main project and then put the resources below ), the packaged file directory will also be in the default content directory, and there will be no special circumstances during the runtime. I do not know what Microsoft limits. |.

Additionally, Microsoft's xap package is a standard ZIP file that cannot be used as a standard. After decompression, it decompress all game resources including DLL and decompile the DLL with reflector, the source code is sufficient to directly generate the original project. I tested several popular WP games and applications and can run them directly with a little configuration ...... Xap is not inferior to the APK package because the code is secure. (It is difficult to generate available Java projects by decompiling the APK source code ~ Xap will kill reflector in seconds to become available C # project ~), Ah.

Therefore, if you use WP, please make more effort on resource protection. Otherwise, each time you release an application, you also upload a 100% open source project.

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

To be honest, the C # version of lgame should be released today.Because the core package has been fully able to run normally in the WP environment (it is okay to generate a Windows game, xbox360 has no environment, and cannot be tested. Theoretically, it is no problem ). Before I posted this blog post, I thought twice about whether to release it first today. However, I haven't dealt with a small problem (there is a hidden bug in the sprg module, and the new RTS module has not been written), so it is not released for the moment ...... But it will be solved soon.

In fact, encapsulating xNa as an engine is much simpler than directly using Java as a game engine (well, the younger brother admitted that C # And C ++ have contributed to the recent rise in the language rankings, when you search for relevant information on Google, the result will also be affected ). In the last few days, we will first get the C # version completely, and then we will be able to do the C/C ++ version practically. In other words, Java and C # Have strong restrictions on the platform, and it is a little troublesome to use Java, C #, C/C ++ at the same time. If you want to port it more easily, always rely on the C/C ++ version for full platform support (the core of the C/C ++ version of The lgame is the secondary encapsulation of SDL, And it is okay to run the PSP (TEST )).

Porting and development is really easy. You don't have to worry about logic issues or algorithms. You only need to do code escape and copy. However, by the end of the year, the younger brother base's bit rate naturally drops to 50% of its normal performance, so it took a long time ~