langresser的专栏

        首先我得说Unity3D已经做的很好了，搞这些东西意义真心不大。具体Unity3D有什么优势我之前也写过两篇文章来阐述自己的想法。        如果我的下一份工作是U3D的话，估计我就不会有这些想法或者研究了。不过谁让我又重新转回cocos2d了呢。我的新的工作大概就是写一个cocos2d-x的2.5D游戏。如果按照我自己的想法，那肯定是U3D来做，不过我在技术上从来

个人一直认为，文字绘制是cocos2d-x最薄弱的环节。对于愤怒的小鸟之类的游戏，cocos2d提供的文字绘制功能已足够使用。但是对于一个mmo来说，则完全不够。一个优秀的mmo客户端必然会对其有进行优化和再封装的操作。        cocos2d-x支持两种文字绘制方式（均支持中英文），一种是CCLabelTTF，一种是CCLabelBmpFont。        CCLabelTTF

Cocos2d Particle Builder.http://blog.youkuaiyun.com/jebe7282/article/details/8051899下载地址(http://www.cr173.com/soft/58380.html)

参考这里 (http://www.himigame.com/iphone-cocos2dx/1289.html)cocos2d-x + Lua在lua代码中调用 node:getChildByTag(2)，这样的代码，随机出现获取为空，或者获取到的不是想要的控件（比如获取的是一个CCLabelTTF c++中调用正常，但是lua中返回的对象无法调用setString函数）。一开始我

cocos2d-x里面有CCSprite的绘制显示范围的代码（详见CCSprite的draw函数）。但是有的时候我们希望绘制CCNode或者CCLayer的boundingBox。例如GUI界面显示或测试的时候，如果可以显示boundingBox的话，会方便很多。尤其是加上锚点（anchor point）的时候，有boundingBox显示可以更加直观的查看其坐标，偏移，旋转等等。  点击的时

cocos2d-x出来很长时间了，受到的评价还是很不错的，有很多创业团队被它的跨平台特性吸引，开始用它来做IOS/Android上的游戏。虽然cocos2d-x已经足够优秀，程序员的工作却还有很多，而作为一个研发团队，有件事情必须在项目开始之前就考虑清楚：换皮／山寨／原创不久之前，一个换皮团队的主程跟我抱怨说老板不明白为什么他们的程序部可以只用一个月就让产品上线但增加一个系统两个月都搞

iOS6的旋屏控制技巧在iOS5.1 和 之前的版本中， 我们通常利用 shouldAutorotateToInterfaceOrientation: 来单独控制某个UIViewController的旋屏方向支持，比如：[cpp] view plaincopyprint?- (BOOL)shouldAutoro

In App Purchase代码完成后，拿iOS5设备（无论越狱与否）和未越狱的iOS6设备测试没有问题，但是iOS6越狱后的设备会出现 Cannot connect to iTunes Store的错误（error code 为0）。连提示购买金额的提示框也没有。     google了下发现是越狱后设备安装了App Sync，安装了这个会导致无法在沙盒模式下测试IAP（注意，只是沙盒模式

1、Could not change executable permissions on the application      原因是创建了多个target，并且这些target共用一个bundle id。  当设备已经装过一个target的程序时，在运行另外一个target 的程序就会出现这个错误提示。  解决方法很简单，设备上卸载原来安装的程序就可以了。2、。。。。

android系统下，切入后台，则纹理全部失效，从后台切到前台，cocos2d-x会重新加载纹理。这样有两个问题：1、如果纹理较多的话，加载纹理会卡很长时间，就像死机一样。  变通解决方法是修改引擎代码，增加一个进度条提示。2、文字描边等用到RenderTexture的地方会出现异常纹理，文字会花掉。  暂时不知道原因，无解。这里提供一个解决方案，解决掉纹理失效的问题，初步测试

如果cocos2d-x进化成一个2.5d游戏引擎的话，那应该会比现在更加强大。 纯3d的估计不会比Unity做的更好了，但是2.5d的应用还是具有很大的现实意义。比如，小场景3d应用（3d立体童话书，3d麻将，3d水果忍者，3d魔方等等），2d地图加入3d 模型的2.5dmmo应用（这个不确定会不会比2d骨骼动画更有表现力或者是开发效率更高），小型3d mmo的开发（比如龙之召唤类卡牌游戏，这

转载自ufolr的博客 原文连接：http://blog.youkuaiyun.com/ufolr/article/details/7447773        在cocos2d中，系统提供了CCMove、CCJump、CCBezier（贝塞尔曲线）等让精灵移动的action，但是有时候，为了让程序看上不不是那么的呆板，或者为了实现某些特定的功能，我们需要让精灵按照我们自己设定的路径（曲线

使用Unity的动态字体绘制文字的时候，打开两个ui界面的时候，后面的文字会显示破碎（完全乱掉）。我使用的ui插件是Daikon Forge，由于其label的更新机制问题，最终表现的结果可能比一个文本显示破碎更加糟糕。很可能文本控件会不停的刷新，要打开的新界面也显示不出来。         这个从根本上说，是由于Unity的Dynamic Font实现的不够智能。理论上NGUI也会有这样的问

1、未完成，待补充，完善后会上传完整代码（包含ffmpeg）.目标平台暂定ios，完善后会完美跨平台。2、实用价值跟遇到的困难不成正比，研究价值更大。3、我们需要一个通用的，可嵌入到游戏内部的视频播放控件。 现有的解决方案都是android和iOS各自实用系统控件进行封装。好处是实现简单，一般情况下稳定，并且解码效率高。 缺点是无法与游戏真正契合在一起，毕竟是作为只能悬浮在游戏之上，并且i

1、ETC1图片是android下通用的压缩纹理，几乎所有的android机器都支持，是opengles2.0的标准。不像pvrtc4只是部分powervr的显卡支持。      ETC1图片不支持半透明（有替代方案可以使etc1图片兼容半透明显示），内存占用只有正常RGBA8888的八分之一（一个像素0.5个字节），并且具备极高的加载速度。ETC1的图片大小只跟图片尺寸相关，在大小上无法媲美

新版本的cocos2d-x使用了luajit来替代原始的lua，好处一是可以极大的提高运行速度（android下可以开jit，运行速度提高10~60倍，ios下不可以开jit，运行速度也可以提高2~3倍）。 二是luajit编译的字节码现阶段来说无法反编译，也就是说无法破解。 这里对luajit进行详细的说明。       1、基本使用。这个很简单，不用修改任何代码，与lua5.1完全兼容。

先上代码function luautil.serialize(t, sort_parent, sort_child) local mark={} local assign={} local function ser_table(tbl,parent) mark[tbl]=parent local tmp={} local sortList = {}; for k,v

严格说来，这个不能算cocos2d-x CCEditBox的bug。但是使用时不注意，确实会被一些恶心的问题纠结掉。        CCEditBox的原理是结合系统原生控件和cocos2d-x自带的CCLabelTTF，实现输入和显示效率的完美结合。需要输入的时候显示的是系统控件，可以兼容各种输入法，平常显示时使用的是CCLabelTTF。        我在测试的时候，发现iOS版本C

之前写过一些纹理与内存优化的文章，本质说的就是图片格式的选用问题。这里记录一些最近开发中关于图片优化的经验和心得。       1、纹理压缩。  就像windows下的dds图片一样，使用纹理压缩可以极大的减少图片加载时间（意味着不会有图片加载时的卡顿），内存消耗（以pvrtc4为例，内存直接减少到原来的八分之一），和游戏渲染性能。   ios下毫无疑问是pvr了（pvrtc4）  ,andr

所谓调色板就是保存256个颜色数据的数组，然后图片数据使用这256个数组中的索引表示，这样一个颜色就只占8位，同时大多数情况下还能够达到真彩色的效果。但是调色板毕竟不是真彩色，在现在的游戏做的越来越绚丽，并且显卡越来越牛x的时代，调色板就没有太大存在价值了。        原本现代游戏引擎已经基本抛弃调色板的使用了，但是手机游戏的兴起和最近png8的使用让我有了一个新的想法。       

cocos2d-x CCTableView动态的插入删除元素有bug，表现异常。  并且我在使用的时候还想添加动画表现（就像UITableView一样，reloadWithAnimation）。 一开始我以为会很复杂，但是测试后发现需要修改的地方并不是很多。 代码只是满足个人的需求，觉得接口不够漂亮的可以再自行修改。void insertCellAtIndex(unsigned int idx

1、现有的cocos2d-x的ui和点击事件分派机制是无法适应mmo的ui逻辑的。 mmo的ui元素很多，一两百个界面是很正常的。 规则既单一又复杂，这些界面肯定是由简单的对话框组成的，不会有什么amazing的东西，但是这些对话框之间的遮挡、层级关系又是复杂的。如果把这些东西丢给写ui或者写逻辑的程序员去操心，那就等着无穷无尽的bug吧。而且即便维护好现有的代码，这些代码结构也是脆弱的，每添加一

1、不是一个完整的模块，所以不提供完整代码，只提供思路和核心代码。  思路很简单，给每个纹理维护一个生命周期和上次渲染时间，每次渲染的时候更新这个渲染时间，CCTextureCache中每隔一定时间（15秒）遍历一下当前纹理集合，如果发现有纹理超过生命周期指定时间没有渲染，则释放此纹理。  CCTexture2D中的getName函数就是很好的更新渲染时间以及释放纹理重新加载的入口。  因为CCT

（未完成）1、2d游戏最占内存的无疑是图片资源。2、cocos2d-x不同平台读取纹理的机制不同。ios下面使用CGImage,android和windows下是直接调用png库。我测试了下，使用png库直接读取png会比CGImage还要节约1mb左右内存（图片所占内存4mb）但是速度要比CGImage慢一倍。时间和空间如何取舍就看实际情况了。不过最佳的选择似乎是pvr（即使androi

通过崩溃捕获和收集，可以收集到已发布应用（游戏）的异常，以便开发人员发现和修改bug，对于提高软件质量有着极大的帮助。本文介绍了iOS和android平台下崩溃捕获和收集的原理及步骤，不过如果是个人开发应用或者没有特殊限制的话，就不用往下看了，直接把友盟sdk（一个统计分析sdk）加入到工程中就万事大吉了，其中的错误日志功能完全能够满足需求，而且不需要额外准备接收服务器。  但是如果你对其原理更感

好吧，其实真正最高效的xml使用方式是不使用xml，使用json或者是ini或者是自定义格式都要比xml快很多。如果使用xml格式的话，可以考虑对xml进行二进制压缩，即把xml当做内存数据直接读到结构体里面。（参考ogre cocosbuilder的实现）不过这样就需要xml与程序严格匹配。原始xml解析库的话，rapidxml是最快的。  我测试了cocs2d-x使用的libxml2（

iPhone Push Notification，一个吹得天花乱坠，却又不断跳票的功能，终于在OS3.0上实现。虽然体验糟糕（Tweetie和IM+之间反复切换，每次都需要等待这两个软件加载数据，这种脑残的使用方式能代替多任务？)，但是我终于可以在使用Tweetie的同时，挂着MSN了。既然BB，Nokia，Palm都先后支持了Push，那么它们之间的比较不可避免。Handspring兄有

这个问题也轮到我遇到了。google很多次还是没有解决。今天先总结一下。问题的主要根源貌似是苹果的版本管理存在一个bug.以下信息来自stackflow.1.apple会删除版本中数字先头的0。例如：1.02,实际上会当作1.2来处理。所以从1.02升级到1.1时就会出错。应为1.12.apple有时候会很晕糊，会把你当前上传的版本，和你其他的app的版本作比较。这

首先是一些基础概念和经验分享：1、OpenGL是一个跨平台的图形渲染标准2、OpenGL ES (OpenGL for Embedded Systems) 是 OpenGL 三维图形 API 的子集，针对手机、PDA和游戏主机等嵌入式设备而设计。该API由Khronos集团定义推广，Khronos是一个图形软硬件行业协会，该协会主要关注图形和多媒体方面的开放标准。OpenGL ES

问题描述iPad1因为内存不足而频繁崩溃。在1.x版本中，iPad1上是勉强可以运行；在2.x因为新增了很多功能，加入两个UITextField控件，并且有新职业，导致内存上涨了10mb+，iPad1会出现频繁崩溃的情况。原因分析 iPad2几乎不用关心内存问题，占用个150mb+都不会内存不足（当然，浪费是可耻的，能够优化就尽量优化）；iPad1可用内存只有80mb左

优化iPad征服的输入处理，获取更好的用户体验原因分析在iPad征服1.x版本中，输入方式是自己实现UITextInput协议。通过协议接口获得用户小键盘的输入信息，直接将数据传递给客户端的Edit控件。这样做的好处是与windows平台结构类似（windows平台也是通过OnChar获取字符串，然后传递给Edit控件），更加灵活高效（因为不使用苹果UIKit控件，没有控件本身

Dnf资源包格式分析，参考的是这篇文章：http://blog.youkuaiyun.com/leexuany/article/details/3849051      提取工具的代码我放到github上了：https://github.com/langresser/dnfextrator      虽然上文已经有比较详尽的分析了，但是真正实现好一个资源提取工具还是花了我两天的时间。这里把需要

基于linux命令行程序axel。支持window（尚有bug待调整）linux, mac，ios和android。ios和android已经调试完毕，功能正常。支持特性：1、跨平台，代码简洁2、多线程下载3、支持断点续传代码托管于github：https://github.com/langresser/libdownload

游戏资源打包几乎是一个网络游戏客户端必备的功能。页游和微端根据实际需求可能不打包资源或者使用小包。资源打包有这么几个好处：1、加快客户端安装时间。拷贝3000个1mb文件所消耗的时间要远大于拷贝一个3g的文件所消耗的时间2、客户端更加整洁，也可以“稍微”避免游戏资源被他人使用。3、ios和android上面可以避免文件名大小写不一致造成的文件读取失败。或者说包内可以做到全平台大小写

iOS和android（还有linux）都是文件名大小写敏感的，windows是大小写不敏感的。        这样游戏开发的时候就会出现这样的问题，windows下测试正常的游戏（包括mac下的iOS模拟器运行正常的游戏，因为Mac系统也是文件名大小写不敏感的）,放到实际设备上运行可能各种崩溃。其中十有八九是配置文件名和实际文件名不匹配造成的。        解决方法有：

依照惯例，先上代码：#pragma once#ifdef WIN32#include #include #else#include #include #include #include #include #define SOCKET int#define SOCKET_ERROR -1#define INVALID_SOCKET -1#endif#ifnde

最开始想iOS和Android都做了，后面尝试了下android上面的崩溃收集，困难程度超出我的想象，也可以说几乎不可能实现像iOS下面一样实用且方便的崩溃收集系统（1.有堆栈等信息，不会产生卡死等副作用。  2.专指jni崩溃，java的崩溃很容易处理）。  这个有一点要反思一下，在困难的地方浪费时间不如把简单的东西做好，那么多赚大钱的游戏也是各种不完美，但是玩家不会在意程序是否牛x，技术是否高

主要目的是完成游戏客户端内的事件处理。这里要明确几件事情：1、同样一个方案在小项目中可能是漂亮的解决方案，但是在大项目中就是很不灵活的处理方法。游戏客户端无论如何都是小项目，不会像windows一样几千位工程师负责上千个dll，一起开发一个操作系统。所以，对我的需求而言，把模块分的很细，很独立意义不是很大，点到即止。2、这样一个事件分发机制主要是处理业务逻辑对gui的控制，或者是不同的界面

cocos2d-x最新支持了webp图片格式，google在2010年发布的这个图片格式具备比jpg和png更高的压缩比，并且支持alpha通道。图片体积对比：原始图片（map_008_BG_2.png   1024*1024的一张背景图）   大小910k压缩为png8      369k压缩为webp（-q 90）  115k可见，webp在图片体积的压缩上是非常有

（未完成）        cocos2d-x并不是一个适合网游客户端（mmo）的游戏引擎，越是大型游戏，这个小引擎就越无法驾驭（虽然它非常受欢迎）。 之前我在原来的公司使用的是自主研发的C3引擎，已经对外开放（尚未开源），后面如果我有提到c3引擎，那么指的就是这个2.5d游戏引擎。         我想起我上个月刚离职的时候，c3的首席研究员（应该也是引擎圈内的一个大牛）对我说cocos2