Quick COCOS2DX 3.x Configuration Win32 Engineering

The main part of the company project is in C + +, while the UI part is written in Lua, so the quick framework is chosen. Project first developed the IOS/MAC version, these two days try to configure their Win32 project, encountered some problems, record (pure C + + version Cocos2dx configuration method should be similar).

Start with Debug mode:

Add C + + files to the project and configure the search path for C + + files in the attached include directory. Then the compilation will encounter some problems:

One, Win32 under the FULLPATHFORFILENAME function and Ios/mac behavior inconsistent problem.

Fullpathforfilename when the parameter passed in is a folder path, IOS/MAC behaves differently under Win32.

Under Ios/mac fullpathforfilename If the parameter passed in is a folder path and the path exists, the correct full path will be returned. But under Win32, if the parameter passed in is a folder path, the passed-in parameter is returned as-is.

Because Fullpathforfilename is used in the project to get the full path of the folder, it is normal under IOS/MAC and does not get the correct result under Win32. Solution See: http://www.cnblogs.com/wantnon/p/4295876.html

Second, the PDB debug information error is not found.

Sets the debug information format, general-C + +, for properties---(/z7) to C7 compatibility.

Three, copy the resource script.

At this point the program will start normally, but the process will crash due to resources not found because some resources do not appear in the working directory $ (OutDir). /.. /.. /.. /runtime/win32, the fact that the working directory is empty, is at a certain stage in the process of compiling the program, and the resource is copied from the folder under which it is located to the working directory . You can see the following script in the command line, build events-----pre-build events, properties:

If not exist "$ (localdebuggerworkingdirectory)" mkdir "$ (localdebuggerworkingdirectory)"

mkdir "$ (localdebuggerworkingdirectory) \src"
mkdir "$ (localdebuggerworkingdirectory) \res"
xcopy "$ (ProjectDir): \.. \.. \src "" $ (localdebuggerworkingdirectory) \src "/e/y
xcopy "$ (ProjectDir): \.. \.. \res "" $ (localdebuggerworkingdirectory) \res "/e/y
Copy "$ (ProjectDir): \.. \.. \config.json "" $ (localdebuggerworkingdirectory) \config.json "/y

You can go to the Edit dialog box and click Macro (M) >> to open the macro list to see the definitions for $ (localdebuggerworkingdirectory) and $ (ProjectDir).

The difference between Xcopy and copy: xcopy can copy directories and files, copy only files.

In quick cocos2dx, the Lua file is placed by default in "$ (projectdir). \.. \.. \src ", the resource file is placed by default in" $ (ProjectDir): \.. \.. \res "under.

In our project, a subset of the resources are not placed in "$ (ProjectDir)" in this specification. \.. \.. \res ", but placed under their own directory myres, so you need to add a script to copy this part of the resources to the working directory, add the following two sentences:

mkdir "$ (localdebuggerworkingdirectory) \myres"
xcopy "$ (ProjectDir): \.. \.. \c3dtoolkit\toolkitres "" $ (localdebuggerworkingdirectory) \myres "/e/y

At this point the debug can be run correctly.

To configure release mode again:

The release mode is also configured as described above and found to not function correctly.

four,. c File Error .

Some third-party libraries, such as SQLITE3.C, which are written in pure C, will report some grammatical errors, such as void* cannot be implicitly converted to char*, and struct B, defined inside struct A, is used externally if it is not written as a struct a::b and only as struct B is not found. The reason for these errors is obviously that the compiler compiled C in accordance with C + + standards, of course, the C syntax in these. c files can be solved by rewriting it as C + +, but the method of changing to C + + syntax is not realistic because there are so many places where large files such as sqlite3.c need to be modified. Later found in the properties->c/c++, high-level compiler can choose to "compile to C + + code (/TP)" or "compiled to C code (/TC)", and this property can be set separately for each file, look at the debug mode settings, found to be The "compile as" property of the entire project is set to "compile to C + + code", while the "compile as" property of a pure C file such as SQLITE3.C is set to "default", and the "mandatory include file" property of the entire project is set to "algorithm", and "sqlite3.c" such as pure C files such as " Force the Include file property to be empty. (if the "force include file" property of a pure C file is pail empty and set to "algorithm", error C2054 is reported: "(") should be entered after "using". The release mode also follows this setting, then the problem is resolved.

Five, error lnk2005:xxx is already defined in Lua51.lib (Lua51.dll).

Compare additional dependencies, input, connector, debug and Release properties, Which release under a lua51.lib, and debug without this one, will release under the Lua51.lib removed, no longer reported this error.

Six, "Working directory" and "command".

Properties, debugging, properties, debugging and working directory, these two release is not the same as the debug configuration, because the Debug configuration is sure to be feasible, simply change the release configuration to the same as debug:

Command: $ (OutDir). /.. /.. /.. /runtime/win32/$ (TargetFileName)

Working directory: $ (OutDir). /.. /.. /.. /runtime/win32

Where "command" is the path to the executable program, "working directory" is the resource directory.

You can see that the $ (localdebuggerworkingdirectory) is consistent with the working directory by looking at the macro value.

Seven, the problem of missing DLL.

Compile pass, but eject "cannot start this program because the computer is missing Xxx.dll" error.

is because the DLL is not copied to the working directory . View the Generate events, post-build events, properties, in debug mode, and find the following script:

xcopy/y/q "$ (OutDir) *.dll" "$ (ProjectDir): \.. \.. \runtime\win32\ "

The release mode does not have this script, so the same script added to release mode, the problem can be resolved.

Eight, project and dependent project release mode to compile the optimization settings.

In general, debug mode will completely turn off the compilation optimization. For release mode, because the goal is to generate a fast executable program, you should select the Compile optimization option to "Maximize speed", and also do not forget to check the dependent items (libbox2d,libcocos2d,libluacocos2d, Libspine) Release mode is also set to "Maximize speed", because I found that the release mode of my Project the compilation optimization of the dependent projects is not set to "Maximize speed" by default.

Quick COCOS2DX 3.x Configuration Win32 Engineering