But now I’m trying to migrate a v3.2 app to v3.5 and I’m failling. As far as I can tell I’ve made all the neccesary changes (the game does work just fine in the browser with cocos run -p web), but when I open compile the win32 and run it in my desktop I only see the following:
I’ve noticed there are a few warinings in the compile proccess for win32, but they appear unrelated, and as far as I can tell the android build reports no problems.
So, I’ve narrowed it down a bit, althought I still can’t get my game to work, here’s a list of thing I’m finding out break the game when compiled (althoght they work just fine in the browser):
Using ñ in variable names. JavaScript can handle it without problems, but I guess the cocos runtime somehow can’t?
Using private (preceded by a _) properties in objects
What baffles me most is that there’s no debug information regarding these errors anywhere, I found the source pretty much by chance, I had to start cutting out pieces of my code until I managed to get a small piece that worked (i.e. Chipmunk boilerplate), and from that point on started adding bits of my code… But this proccess looks like it’s gonna take ages until I manage to leave the source from my project into a state that can actually run… Isn’t there anyway to debug this thing? I tried running the project from Visual Studio, but it shows no mention of the JS code and not even a warning or hint as to why the screen is still appearing black.
I’m unable to connect my android device at this moment, is logcat available if I’m not running connected with a device via USB? I have the same issue with the win32 build, is there any way to debug that? I’ve tried running from visual studio but there’s no info.
Update: I’ve ported an older game from v2.2.3 to v3.5 now and, using Cocos Code IDE v1.1.0 I can make the win32 debug work for this project! But If I compile the game for release I get the same black (well, gray in this case) green with FPS counter (altohught it should be disabled from the configs) scenario…
OK, final bump before giving up on compiling (and possibly entering the windows contest):
Does anyone have any clue on something I could do to debug this? Any diagnostics tool? Something I may be needing to update? I can’t figure out why the hell would my project work in the browser without any warnings and simply fail like this when compiled…
OK, so, I’ve resolved to just start a new project from scratch and test in all platforms every step of the way.
I’ve been building a prototype for a few days now like this, and I’ve found that one of the biggest problems is scope.
The way that JS scope works in browsers appears to be uncanningly different from the way JS scope seems to work in compiled applications, particularly when dealing with Cocos’ classes.
I want to write an example here, but I’m honestly having a little trouble trying to wrap my head around the problem. All I can say for now is that what you are trying to accomplish is inside a callback and/or some other nested function that requires you to do a var that = this; in order to have access to the outer scope within that inner function, then you can use that's methods that you’ve defined, and all of it’s properties, but you can’t rely on it’s cocos2d-api methods directly.
So, this will fai with an “unvalid native object” error Cocos Code IDE’s console:
//... within, let's say, a Layer
foo : function(){
var that = this;
var myCallback = function(){
that.removeChild(that.someSprite);
};
}
But this will work just fine:
//... within, let's say, a Layer
foo : function(){
var that = this;
var myCallback = function(){
that.bar(that.someSprite);
};
},
bar: function(child){
this.removeChild(child);
}
I am not sure about this but I think that the native cocos garbage collector does not respect the function scope of variables when the variables contain cocos objects. You need to call retain() on such objects that need to be referenced like this.
For now I’m focusing in “cleaning up” my code, maybe it’d be best to adhere to certain coding practices as a standard rather than relying on these JS quirks tht just work but may not be palatable to the compiler.
I had a “black screen” issue when deploying an APK to a Android 5 OS that was packaged with an outdated NDK version. Switching your NDK build environment to r10c should fix it if thats the problem.
Yeah, anything that sticks to the way scope works in most object-oriented languages that aren’t as insane as JS seems to work just fine for dealing with cocos objects