Bug @ Debugging environment for Cocos2d-x on Windows / MSVC

cocos2d-x C++
#1

COCOS2D_DEBUG never gets defined on Windows builds of Cocos2d-x. It is used in the XCode project files on the Mac, so I guess it’s a good idea to enable it for MSVC as well, as it’s really useful to figure out why a resource file doesn’t want to be loaded :slight_smile:

Can be fixed by replacing the following line in $cocos2dx_root/cocos2dx/proj.win32/cocos2d-win32.vcproj:

PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;COCOS2DXWIN32_EXPORTS;GL_GLEXT_PROTOTYPES"

…with this one:

PreprocessorDefinitions="WIN32;_DEBUG;_WINDOWS;_USRDLL;COCOS2DXWIN32_EXPORTS;GL_GLEXT_PROTOTYPES;COCOS2D_DEBUG=1"

I think it would be nice to add it to the MSVC App Wizard as well. In $cocos2dx_root/cocos2d-x/template/CCXAppWiz.vs/CCXAppWiz/Scripts/1033/default.js, replace this:

if (bDebug)
    strDefines += "_DEBUG";

else
    strDefines += "NDEBUG";

…with the following code, and life will be much better for newly generated Cocos2d-x apps :slight_smile:

if (bDebug)
    strDefines += "_DEBUG;COCOS2D_DEBUG=1";

else
    strDefines += "NDEBUG";
#2

A cool idea.
For cocos2d vcproj, COCOS2D_DEBUG=1 will output too much noise, you can’t find the logs from your game sources. So I keep my opinion, close this switch as default.
Fpr templates, I modified the templates in this commit. Both win32 & uphone new projects will open the switch for CCLOG in debug version. It’s a good improvement.
Thank you for your suggestion!

#3

After a few hours of using COCOS2D_DEBUG=1 I tend to agree with you. There’s a lot of noise indeed!

The reason I was suggesting it is because it’s used in UIImage::initWithContentsOfFile(…) @ $cocos2dx_root/cocos2dx/platform/win32/CCXUIImage_win32.cpp, to pop up an error dialog whenever an image file cannot be loaded.

I think it’s very useful for a developer to get these kind of messages when using the debug version of the Cocos2d-x library without being required to recompile it (and after that, recompile again once the resource issue is solved, to get rid of the redundant log messages). It kind of defeats the purpose of adding the extra code for showing the popup dialog in there if you’re never going to see it without performing a bunch of extra steps. One might as well just use the debugger instead of doing the added work to get that dialog :slight_smile:

Hope it’s clear what I’m trying to say here :slight_smile: If not, try to create a Cocos2d-x app (without the COCOS2D_DEBUG variable defined for the library), load a sprite and intentionally forget to copy the (correct) resource file for the sprite into the resources directory. When you run the app, it will just hang in there without doing anything, even when it’s using the debug version of the Cocos2d-x library. With COCOS2D_DEBUG defined for the library, it would just tell the developer it cannot find the resource, saving him/her a lot of time to figure out what went wrong.

Perhaps I’ve got a better idea: what do you think about using the DEBUG variable in UIImage::initWithContentsOfFile instead of COCOS2D_DEBUG? That way, developers can still see when their resources won’t load when using the debug version of the Cocos2d-x library, but without the noise.
Another idea would be to use an assertion test for checking if bRet in UIImage::initWithContentsOfFile == true, without using COCOS2D_DEBUG orDEBUG at all. That would be a perfectly fine solution as well, I think.

#4

You can read the history of CCXUIImage_win32.cpp https://github.com/cocos2d/cocos2d-x/commits/master/cocos2dx/platform/win32/CCXUIImage_win32.cpp
Before this commit at Dec.18,2010, the engine always pop up a dialog to tell you “image file cannot load”, both in release and debug without any preprocessor defines.
But my guys met a problem in particle system. In plist file for particle system, they are running this flow

textureName = getNameFromXML("textureFileName");
imageData = loadImageFromFile("textureName");
if (imageData == NULL)
{
    imageData = loadImageFromXML("textureImageData");
}

You can find these codes in CCParticleSystem.cpp, line 240~268

So when invoking CCXUIImage to loadImageFromFile failed, they don’t want the dialog pop out at this situation, because the image data may load succeessfully from XML file.

I will consider a better way to resolve this conflict, e.g, read data from xml first, or add a method for the sepecial operation.
issue #328. It’s sunday here, I will dicuss with my guys tomorrow.

#5

Hmm, that’s a though one indeed.

Tried to think up something nice, but all I can think of is to split up some parts of CCTextureCache::addImage(…) into a method for caching while popping up an error on failure, and another method (not part of CCTextureCache) to load the image. That way, you could temporarily bypass the cache while loading the particle images and not have the error dialog from the image loader.

But I’m afraid that would result in the code being refactored too much (diverging away from the Cocos2d “standard”), so you might want to forget about what I said there :slight_smile: