类型： BUG
平台： Win32
版本： cocos3d-x-3.0
关键字: 内存泄漏严重
描述: vld检测HelloWorld工程存在大量的内存泄漏
如果按照58楼的说法，为每个构造函数使用二段构造从而定义两个方法（一个是init，一个是create），不嫌麻烦吗，会比构造函数有更大的优势吗。java的语言特性使其用静态工厂方法替代构造函数成为一件意义的事情，但是在C++是一件非常恶心的事情，究其根本原因仍然在于语言差异，cocos2d-x的二段构造就是没有解决引用计数而形成的累赘，我相信这么说不过分吧，你看看现在的二段构造的静态工厂都做了些什么，仅仅为了塞一个autorelease！如果没有引用计数，你cocos2dx会用个毛线的二段构造！！
但是现在来说引用计数似乎为时已晚，首先引用计数被设计出来旨在解决释放内存，但是不能解决所有问题，比如循环引用；其次它不见得比手动控制内存强到哪去，你总得记得成对调用retain和release吧，C++的内存管理也要求成对使用new和delete。回到刚才的语言差异上来，我来告诉你为什么引用计数并不如想象的那么好，并说明一个你从未想过的C++问题。
java的内存是由虚拟机管理的，所以无论怎样你都不需要关心内存的来源问题，而C++的内存是由程序员管理的，作为C++程序员，他们会操作来源于不同内存的对象，比如同一个类型的一个实例有可能产生于A内存池，另一个实例却产生于B内存池，当你同时得到这两个实例时，必须从不同的内存池释放他们，否则系统就会crash。再来看看cocos2d-x的做法，所有CCObject及其子类对象都假定由全局new和delete进行内存分配和释放，这表示在当前的程序中，我们所有CCObject对象都来自于我当前规定的内存（如果你重定义全局new和delete，或者来自于默认的C的malloc），如果我集成了第三方的涉及到cocos2d-x的库，那么我不能很坦然的对生成于该库里面的CCObject及其子类对象放到我自己的程序中进行释放，尤其是那些在自己程序中new出来的CCObject对象，因为很显然，你并不知道第三方库的new和delete是否已被改写，内存来自于何方，所以在自己程序里进行释放是一个从理论上必须坚决予以否定的做法。我想，现在你应该知道为什么cocos2d-x为什么要搞二段构造了吧，同志们，睁大你们的眼睛仔细看看CCObject这个类吧，看看release里面有啥，是的，有delete，但是new在哪里呢，God！在子类的各个静态的create中！程序员当然有这个权力不使用create而使用new来创建这个对象，但是一旦继续调用autorelease，那么你必须承担来自于未知内存池的释放行为，你的程序就有可能 嘣！crash了。
delete存在于实例方法release中，但new无法存在于该类的另一个实例方法中（这毫无意义）。然而new和delete必须成对出现，因此cocos2d-x把new放到了静态的create中，这难道不是个障眼法，几乎蒙蔽了所有人（当然不包括我），但是官方却美其名曰：哦！这是二段构造，它有123456个优点，去死吧。所以，cocos2d-x的内存管理实质上是有缺陷的。一个比较安全、不做大改的做法（当然依然很恶心，因为仅仅是为了处理引用计数），是仅让用户使用create，而不去使用new，也就是把所有CCObject及其子类的构造函数设为protected访问权限，但是官方是否愿意去做呢。并且这不是根本性的解决方案，因为用户可以自定义子类。
虽然，各位搞cocos2d-x开发的程序员们99.99%不会遇到上述问题，但这也不表示作为一个引擎不应该去关心这样的问题，毕竟是涉及到内存管理的，C++80%以上的问题都是内存问题，这么说不过分吧。所以我在这里继续吐槽二段构造和引用计数，但问题是：虽然官网不解决该问题并无大碍（从实用角度考虑，那些bug才是真正的困扰），但从学术角度考虑，你们真正能解决这个问题吗？（3.x的Ref类的release做了少许修改，但显然还是没有涉及到该问题）
类型： BUG
平台： all
版本： cocos2d-x 2.x
关键字: tableview menu
描述: tableview中添加menu按钮滑动tableview的时候 如果滑到menu添加的menuitem上面事件被吞噬了 好多版本都这样
类型：吐槽/bug/
平台： ios 7.0
版本： cocos2d-x v3.0
关键字：glScissor
描述：在 3.0 正式版中重载 visit t(Renderer* renderer, const kmMat4 & parentTransform, bool parentTransformUpdated) 函数
void XXXLayer::visit(Renderer* renderer, const kmMat4 & parentTransform, bool parentTransformUpdated)
{
glEnable(GL_SCISSOR_TEST);
Point origin = convertToWorldSpace(Point::ZERO);
glScissor(origin.x, origin.y, _contentSize.width * _scaleX, _contentSize.height * _scaleY);
Layer::visit(renderer, parentTransform, parentTransformUpdated);
glDisable(GL_SCISSOR_TEST);
}
无效
在之前版本中按上述方式重载 visit()，可以达到裁减掉指定区域之外的效果！！
严重同意10楼的建议，“每次更新都修改太多方法名字了，老项目基本上不敢升级引擎。建议：各种名字和调用方式不要每个版本改一点，要么一次到位，要么别着急改”。
ps：提个跟这相似问题方面的建议：
类型：建议
关键字：cocos2d-x版本更新时间频率问题
描述：差不多平均每个月你们都更新一个版本，关键是更新都修改了各种的细节，导致每个版本之间又不是很兼容。写项目的时候遇到问题，查找各种资料就很恐怖了。好不容易找到类似问题的解决方法，可整老半天下来，靠！这个又搞不了，因为不同版本的引擎！又改了！！然后又得重新找解决方法。很是浪费时间，降低效率！
每每使用的cocos2d-x引擎的感慨都是，靠妖！又改了！累觉不爱！！！
建议：严重希望半年或者一年更新一次就可以了！呜呜……
建议把动画整合一下，每次写一个plist动画，都需要那么多代码，如果太多动画，代码就太多了
北京手游公司招聘
cocos2d是主程 18-20K 优秀者可提升 3年经验+
u3d是普通工程师 15K左右 2年经验
后端JAVA 12K -13K 2年经验
资深UI 15-20K 优秀者可提升
主美术 18-20K 优秀者可提升 成都一线游戏公司 招聘 3Dleader 10-20K
成都一线外资游戏公司，招聘
U3D 10-20K
3D美术leader 10-20K
如有意愿，请发简历到：thomas@kanof.net
或者qq联系：596053605
手机：18600876055
猎头焦先生
能不能直接出apk包啊
我只想说,我之前刚用过unity3d,更用过vs…
‘s’<
类型：bug
关键字：动态链接库
描述：为什么不用动态链接库了？而且生成的 libcocos2d.pdb文件200+兆啊，有木有，经常出现 error C3130: 内部编译器错误 啊有没有，
建议：这种坑人的东西赶紧解决啊
关键字：命名
描述：每次升级都改接口，改函数使用方法，又没有个准谱？
建议：别老改名了，求你们了
我认为cocos sdudio应该往unity这样的集成软件发展，而不是UI,动画,场景，数据，代码，发布等都分开。最好是可以直接像unity一样，可以创建场景，创建ui和动画，支持lua,js脚本及调试，能快速创建和发布项目到多个平台
类型：建议
平台： android
版本： cocos2d-x v2.2.3
关键字：flash播放
描述：现有版本的cocos2d-x不支持flash播放
建议：你好，我是一名使用cocos2d-x（2.2.3版本）的游戏开发者，最近遇到一个问题就是若想在cocos2d-x中播放flash动画的话没有相应的接口函数，也没有一个完善的解决方案。若采用flash动画拆分帧再导入的话，效率很低，且效果不好。
因为一个完善的游戏有时候会遇到播放一个完整动画或者视频的时候，例如宣传游戏的游戏CG。所以建议cocos2d-x引擎开发团队考虑一下这个问题，希望下一个版本能看到这个问题的解决方案。
至此，多谢查看。
类型：建议
关键字：GUI
描述：IOS有xib，unity有 NGUI， 2dx 有ccb？跟前面比起来弱爆了啊
建议：跪求可视化！
类型：cocos studio文档
关键字： 示例老旧
描述：引用的示例都是2.x的，还不标明下，3.x呢？我该引用哪个.h啊？我该在加入哪个库的引用啊？难道studio不是游戏开发的标配吗，cocos new出来的工程为啥就没有libCocosStudio啥的呢？
建议：举几个例子比啥都实惠，另外赶紧把3.x的示例放上来，也就不到1个小时的工作量，为啥就是不更新呢？难到预示着又有大变？
win7旗舰版 编译程序后 都无界面 但进程里有 - -|
类型： bug
平台： android 4.x
版本： cocos2d-x v3.1
关键字：多个精灵(大图19201080)在layer里面渲染时，无法正确显示
描述：android机器上多个精灵(大图19201080)在layer里面渲染时，无法正确显示，设置zorder也没效，部分消失，但能响应点击
建议：火速解BUG
类型：兼容性问题
关键字：ScrollView 跟 MenuItem
描述：自从升级到3.0以后，ScrollView 跟 MenuItem 的兼容性就一直存在问题，触摸优先级各种调整都不对，都过了这么久了，官方都不知道呢？还是无意无修复，要是无意去修复，还放着这个控件干嘛？
建议：希望尽快修复 ScrollView 跟 MenuItem 的兼容性问题