Add a check to the CCNode destructor to catch a common cocos2d-x programming mistake - forgetting to call base class onExit() in derived class onExit() implementations. We can check for this invalid API usage by checking if the node is still marked as running on destruction. If the node still thinks it's running then it's likely the cleanup logic performed by Node::onExit() was not done.
1: Add a fix to prevent events from being sent to scene nodes which are destroyed. Previously when a node was being destroyed it would try to unregister any event listeners it would have. This process would fail however in the case where event dispatching was already underway because we can't modify the listeners list while we are iterating through it. This is a pretty common occurrence since we often tear down & switch scenes in response to button clicks etc. Fix the problem by nulling out the slot for the listener we are removing in this case, so that it's node no longer receives any events after it is destroyed. The event dispatching code will cleanup this unused/nulled slot once the event processing loop has terminated.
2: When removing an event listener in cocos2d::EventDispatcher, ensure immediately it gets removed from the node priority map and dirty nodes set in order to ensure we don't inadvertently access any dangling pointers to nodes.
3: Add debug checks to ensure nodes have no associated event listeners after they are destroyed. This check will catch the problem fixed by (1) if it is still present.
4: Add some extra debug sanity checks in the event dispatcher to ensure nodes are not added to the lists twice and that they are being properly removed from the lists under certain conditions.
5: In cocos2d::Node's destructor NULL out members after releasing them in case they somehow happen to be accessed during the destructor. Move the release of the event dispatcher to the very end, since we need to check against it in debug.
This funciton is useful, but the code is buggy.
In should check the parents' position instead of Director::Size()
Let's do it correctly, and then re-add this function
* Timer is an abstract class now.
* Adds three new timers ( `TimerTargetSelector`, `TimerTargetCallback`, `TimerScriptHandler`) which are inherited from Timer.
* Adds new API 'scheduleCallback` / `unscheduleCallbackForKey', and callback's target could be any classes since we're using `void*` to identify target.
* `Scheduler::scheduleCallback` use `std::function`, therefore, it supports passing `lambda`, `member_function` and `global_function`.
* The old selector API is still kept since it's very useful when schedule callback is a member function, it doesn't need a `key` to identify the callback function. (+1 squashed commit)
* Adds relevant test cases.
`visit()` and `draw()` are improved.
they both receive:
- `Renderer`
- `kmMat4` for transformation
- `bool` whether or not the transform changed from the previous frame
Although `draw` and `visit` are not using the 3 new parameters,
they will start using it in the coming days (or weeks, or months).
Those parameters are needed for:
- `Renderer` shouldn't be a singleton. There should be one renderer per Director. There could be more than one renderer
- we should get rid of `kmGLXXX` functions since nodoby knows what is happening. the `kmMat4` is for that.
- whenever possible, we should try to optimize the multiplications. the `dirty` flag is for that.
We need those changes, so, it is better to change the API now, and not right after v3.0-final is released.
James Chen