cocos2d-js

概述 该单例是为了方便开发者操作文件路径所设计的。定义为 cc.path 的目的是为了跟 nodejs 的 path 保持一致。里面定义的api也基本跟 nodejs 的 path 模块一致，但不全有，今后可能还会继续根据需求添加。同时也加了一些 path 模块没有的pai，例如 cc.path.changeExtname 和 cc.path.changeBasename 。 cc.path.join 路径拼接操作。 参数： name type 可变长度的参数 String cc.path.extname 获取文件路径的后缀名。 参数： name type pathStr String cc.path.basename 获取文件名。 参数： name type remark pathStr String 必填 extname String 选填，指定获取的文件名所要去除的后缀名，不填则认为不去除文件后缀名 cc.path.driname 获取文件所在文件夹路径。 参数： name type remark pathStr String 必填，文件路径 cc.path.changeExtname 改变文件后缀名。 参数： name type remark pathStr String 必填 extname String 指定要修改成的后缀名， 不填是认为不加后缀名 cc.path

cc.saxParser 将cc.SAXParser重构为单例对象：cc.saxParser 删除了 tmxParse ， preloadPlist ， unloadPlist ， getName ， getExt ， getList 等方法。 Parser的统一入口函数规范为 parse ，并且传参内容即为需要解析的文本内容。 cc.plistParser 添加了 cc.plistParser 。 cc.plistParser 继承 cc.saxParser ，用于解析plist文本内容。 这样的改造是为了让Parser的职责更加纯粹，只管解析，也就是对字符串内容的处理，而不需要管资源的加载。资源加载统一被移到 cc.loader 进行管理了。 CCTMXXMLParser.js 关于Parser这点，tilemap也需要改造。目前还未进行改造。 转载请注明：https://blog.csdn.net/qinning199/article/details/41900335 来源： https://www.cnblogs.com/wodehao0808/p/11929613.html

统一引擎内部创建SpriteFrame的数据结构 将Plist的解析工作转移到了cc._plistLoader中去，对SAXParser进行了改造。 统一了引擎创建SpriteFrame的数据结构： { _inited : true, frames : { "a_frame_0.png" : { rect : {x : 0, y : 0, width : 1, height : 1}, rotated : false, offset : { x : 0, y : 0}, size : { width : 1, height : 1} aliases : ["a_f_0"] } }, meta : { image : "a.png" } } 引擎在创建SpriteFrame的时候，读取了plist配置文件的信息后，会将其转换为以上的数据格式。 自定义SpriteFrame的配置文件 采用 cc.loader 的插件机制，我们可以很轻松的自定义自己的配置文件格式。SpriteFrame的各种格式的配置文件，只要转换成对应格式就行了。 例如，我们自定义了一个文件，用于存储原本配置在多个plist( res/ui/tcc_issue_1.plist, res/ui/tcc_issue_2.plist )的SpriteFrame的打包信息， 名为 res/ui/imgs.pkgJson

Web引擎 CCFileUtils.js在Web引擎中已经被删除了，原因是FileUtils在原生平台中的文件检索功能在Web端是无法实现的。 二进制文件获取的方法被转移到了 cc.loader.loadBinary （异步）以及 cc.loader.loadBinarySync （同步）中。 其中， cc.loader.loadBinarySync 方法是极其不推荐使用的，可能在今后版本升级改造中会被废弃掉。希望开发者别滥用。 所有资源加载、获取、释放等操作都统一到 cc.loader 中了。 对于路径字符串拼接操作统一到 cc.path 中了。 JSB 在JSB中，由于FileUtils调用的是原生平台的实现，所以我们将其保留，并将 cc.fileUtils 重命名为 jsb.fileUtils ，这样用户就会知道这是原生平台才有的API。 转载请注明：https://blog.csdn.net/qinning199/article/details/40452199 来源： https://www.cnblogs.com/wodehao0808/p/11929573.html

新增action中的方法 以前，当我们需要重复一个action的时候，我们需要： sprite.runAction(cc.Repeat.create(action, 2)); 上面代码中创建了一个新的Repeat对象重新包装action，这样不管在语义上还是代码上都比较难理解。 为什么我们不能像jQuery一样的简单方便的使用原action呢？ 于是我们在新版本中为action增加了新的方法： sprite.runAction(action.repeat(2)); 要循环action只需要在action后面增加.repeat()，而不需要和以前一样重新生成一个action，是不是更加方便了? ^.^ 另外，我们还针对action的相关类，增加了更加简单的创建方法，通过类名第一个字母改为小写就能创建出一个新的对象： var action = cc.moveBy(2,cc.p(10,10)); 上面代码等同于： var action = cc.MoveBy.create(2, cc.p(10, 10)) 看到这里，大家一定很担心一件事儿~兼容性。。。 其实，大家不必太过于担心，旧的方法依旧是被支持滴。 为什么要新增API 刚刚提到了怎么调用新的方法，但是为什么我们在现有一套比较成熟的方案下还是在新版本中加入了新的方法呢？ 其实这一切都是为了更简单，更符合大家的使用习惯

概述 使用 cc.game 单例代替了原有的 cc.Application 以及 cc.AppControl 。 简化了工程启动代码的编写。 使用 首先在 index.html 中引入 xxx/frameworks/cocos2d-html5/CCBoot.js 。 然后开始进行入口代码编写，一般放在 main.js 中。 项目启动代码的编写较v2版本是大大的精简了，使用起来会更加舒服： cc.game.onStart = function( ){ //load resources cc.LoaderScene.preload(resource_list, function ( ) { cc.director.runScene( new MyScene()); }, this); }; cc.game.run(); 当 run 的时候，引擎会自动读取 project.json 配置文件获取配置信息。 延迟运行 有种需求是先加载完js，游戏主循环并还未开启，等响应了某一事件之后才开始运行游戏，例如： cc.game.onStart = function( ){ //load resources cc.LoaderScene.preload(resource_list, function ( ) { cc.director.runScene( new MyScene()); },