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
Hope it’s clear what I’m trying to say here 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.