问道资源提取

问道的资源都位于client.dbfs中，这个文件是以2K(0x800)为单位，如果一个文件的长度小于0x7e6则放在一块内，否则放在多个块。块有各种类型，主要处理文件头块，文件数据块，文件结尾块。这三种块的头信息如下，头信息长度为0x1A，格式如下 偏移长度 说明 04 00 00 00 00 固定内容 44 01 00 00 00 固定内容 84 块序号，从0开始编号 124 前一块数据的块序号，如果是0，则该块可能是头数据块 164 后一块数据的块序号，如果是0，则该块可能是末数据块 202 01 00 固定内容 222 有效数据长度，如果大于0x7e6，则这块不是数据块(可能是目录块) 242 00 07 固定内容 26变长有效数据内容，如果长度不足0x7e6，则补足对于头数据，开头的20字节是问道自己的一个文件头，结构如下 偏移 长度说明 04 未知数据，不理会 44 可能是时间戳1 84 可能是时间戳2 124 可能是一个原始文件长度 164 文件真实长度一般只处理时间戳1=时间戳2的头，原始长度也必须=真实长度。原始长度!=真实长度的文件，里面被塞了一堆FF，不知道如何看。问道的图片大部分都是JPEG，部分是TGA，小部分是BMP，结出来的图片有些不能直接浏览，需要处理后才能浏览。看了问道的资源原始资源文件大概有1w8多，其中有的人物动作图片资源，最多似乎有90多帧。感觉2D MMORPG对于图片资源的依赖是一个很大的问题，一个人物如果要支持走，跑，逃，站，物攻，魔攻，挨打，再加上换装，换物品，对图片的需求量是非常大的，问道每个角色，不能换装，不能换武器尚且这么多资源。怪不得春秋Q传，巨人都开始采用3D人物模型+贴图的方式来支持换装，换武器了。任务形象动作比之问道要丰富很多但是安装文件都要小（巨人春秋的资源都是压缩过的，也有一定关系）。而且现在大家都开始采用有损压缩的图片，问道都是采用JPEG，春秋采用DDS，都是为了降低资源尺寸。不知道问道的JPEG是如何处理Alpha通道的，单纯根据一个LowColorKey, HiColorKey，似乎不足以精确处理边缘透明，而且没看到人物的影子，可能问道这块采用了一些特殊的技巧来处理吧。用户越来越挑剔，肯定是越来越喜欢更加丰富的换装，换武器，换宠物的MMO，类似春秋，巨人这种固定视觉的简3D，伪2D，新一代的2.5D前端引擎，应该是更加有竞争力的。至于纯粹依靠贴图的，如果有人做出一套2D的，支持人物的运动，贴图的高级动态Avatar系统，生存的可能会更长久一些。问道的JPG+Alpha昨天猜测问道的人物序列应该是由PNG序列生成的，图像数据转化为JPG，Alpha通道单独压缩保存,今天验证了一下，问道的人物序列文件确实如此，前面56字节的文件头，描述了序列的信息，诸如帧数。后面就是帧数个数据块，每个数据块short xOffset; / 帧对齐偏移short yOffset; / 帧对齐偏移short width; / 图像宽度short height; / 图像高度int tag1; / 不理会int dataLength; / JPEG+Alpha数据长度int tag2; / 不理会int jpegLength; / JPEG图像数据长度bytejpegLength jpegData; / JPEG图像数据bytedataLength-jpegLength-8 alphaData; / alpha通道数据jpegData是完整的JFIF数据，从FF D8 到 FF D9alphaData是inflate压缩的，原始长度