Visual Studio 2019

If any VS users haven’t switched to VS2019 yet, then just so you know there is a really good reason why you probably should. The build times are significantly faster for Cocos2d-x C++, especially when using the /Z7 switch for the debugging info.

An explanation for why this is so is here.

3 Likes

Thank you for the suggestion, I second this post and more reasons can be found here explained by VS itself

Did you check if cocos2d-x. 3.17.1 compile and work with VS2019?

Yes, of course, 3.17.1 builds perfectly fine in VS2019, with the v142 toolset as well.

To create the project, use this command:

cmake .. -G "Visual Studio 16 2019" -A Win32

More cmake options for VS2019 project generation here.

Yes, of course, 3.17.1 builds perfectly fine in VS2019, with the v142 toolset as well.

Did you try 3.17.1 with VS2019 in release mode?

To me it works great (compiles very fast!) in debug mode, but in release mode the compilation always gets stuck at CCTweenFunction.cpp.

The problem applies to both 3.17.1 and 3.17.2. But it works with older versions like 3.11.

I just tried 3.17.1 and 3.17.2 in release mode, and both compiled and ran fine. The release projects were created using the following command:

cmake … -G “Visual Studio 16 2019” -A Win32 -DCMAKE_BUILD_TYPE=Release

Are there any warnings or errors that appear when it hits that file? Have you updated to the latest version of VS2019 (16.1.3)?

For some reason the issue you’re having looks so familiar, but I can’t quite remember why. If you have a virus scanner running, like Windows Defender, try adding your development folder to the exclusion list. For instance, I have everything in X:\Dev… so I’ve added that path to the exclusion list since I trust what is in there, just so it doesn’t scan every file during the build process.

1 Like

I have latest VS2019 (16.1.3) Professional. I tried adding the project folder as an exclusion in Windows Defender but it didn’t help.

I just downloaded the cocos2d-x release versions from https://cocos2d-x.org/download, ran cocos new -l cpp name, double clicked on the .sln to open the project in VS2019, switched to release mode and hit Build Solution. It always stops on the same file, CCTweenFunction.cpp.

There is no warning or error message. The compiler takes up one CPU core for ever.

It works fine in VS2017 so I figure it is something related with VS2019.

If you have any other ideas then please let me know.

That solution file is old, and I personally don’t use it, and perhaps it’s the reason you’re having problems. You should generate a new one using CMake, as this guide specifically instructs you to.

So, for instance:

cd [your game folder]
mkdir win32-build && cd win32-build
cmake .. -G "Visual Studio 16 2019" -A Win32 -DCMAKE_BUILD_TYPE=Release

or for debug:

cd [your game folder]
mkdir win32-build && cd win32-build
cmake .. -G "Visual Studio 16 2019" -A Win32 -DCMAKE_BUILD_TYPE=Debug

You can change the folder names for each build folder, so win32-debug and win32-release if that helps. This build folder and solution can be regenerated any time, so you don’t check it into your source control, and no need to make a backup of it etc…

The root CMakeLists.txt file that is in your application folder is the one you need to update with references to your source code.

2 Likes

It compiles now. Many thanks.

Correction: It works with 3.17.1. With 3.17.2 compile still hangs, but on another file now (LocalStorage.cpp).

Also, with 3.17.2 the build type parameter should not be specified as both debug and release are created automatically.

Ok, recall I mentioned how this was so familiar a few posts back, and now I’ve realised why. It has to do with optimizations being turned on for the cocos2d library (not the game project, just cocos2d project), specifically when set to /O1 or /O2 or /Ox. If you turn off optimization (/Od), or set it to Custom, then it works fine, and it’s exactly what I did to this test project when I was testing 3.17.2 after it was released, and the reason that my project compiled fine earlier.

I’m sorry that I completely forgot I had made those changes to it, and only discovered it when I created a new test project now to try and reproduce the issue you’re seeing.

If you set optimizations to Custom, then you can turn on a few items and it will still compile fine, like what you see here:

This issue has happened a few times with previous versions of Visual Studio, and it’s not specific to Cocos2d-x.

@larsven An alternative solution is to add the following lines to CCController-linux-win32.cpp (which seems to be the actual cause of this issue, and not LocalStorage.cpp):

#pragma optimize( "", off ) // Add this before the class declaration 
class CC_DLL ControllerImpl
{
..
..
..
};

#pragma optimize( "", on ) // Add this at the end of class declaration (approx. line 4908)

Then you can leave the optimization set to /O2 and it will compile fine, just skipping the code that is included in those files. I’m curious if this fixes the issue for you too.

1 Like

@R101 Both the first and the alternative solution work fine!

Perhaps this change to CCController-linux-win32.cpp is warranted and should be merged into the repository, with checks for usage VS2019 toolset v142 before it is applied, at least until Microsoft fix the issue on their end at some point. It’s better than turning off the /O2 speed optimizations over the whole cocos2d library.

I believe it is warranted, yes. Are you familiar with the process of merging it into the repository?

Yes I can create a pull request for it, once I look into it a bit more to see if it is the only possible fix for this, and how to actually check for the toolset being used, since it only affects v142 at the moment.

EDIT: So, here is what seems to be happening. It’s only one of the optimization options that is actually causing this issue, which is global optimization (/Og, which is automatically turned on when /O1 or /O2 are enabled).

From here:

This table shows the specific options that are set by /O1 and /O2:
/O1 (Minimize Size) 	/Og /Os /Oy /Ob2 /GF /Gy
/O2 (Maximize Speed) 	/Og /Oi /Ot /Oy /Ob2 /GF /Gy

So, in order to get the CCController-linux-win32.cpp code compiling properly, we don’t need to switch off all optimizations, but just the one that’s causing the problem:

#pragma optimize( "g", off ) // Disable global optimizations.
class CC_DLL ControllerImpl
{
	public:
...
...
};
#pragma optimize( "", on ) // resets the optimizations to those that you specified with the /O compiler option

Github issue and PR created for this: https://github.com/cocos2d/cocos2d-x/issues/19836

1 Like