cocos2dx 大地图分块加载的研究(初)

本文转自http://blog.csdn.net/dinko321/article/details/46739563

 

项目里面需要加载一个很大的地图，目测最少是4096x4096的分辨率。

 

        先不考虑什么引擎最大支持多大的图啊，大图加载效率啊等等这些问题，光是4k x 4k的分辨率，ARGB8888，加载进去，就是64M的内存，这还只是一个背景。再来点其他七七八八的东西，轻松超过120，这个内存在某些设备上就已经很危险了。

 

        为了实现这个目标，处理的方式大概有2种：

        一、资源重用。也就是类似于tiled这种方法，把地图上面的一些图块，反复使用，通过有限的纹理，来拼接出地图。但是这种方法的确定是地图会比较死板

        二、分块加载。就是把一个大图切成若干小块，每次只加载需要显示的图块。看上去很美，现在主要说这个。

 

        先说切图，肯定是切小方块，按照二的幂的原则，一般有这么几个备选：32、64、128、256、512。

        用切的图块来铺满一个屏幕，不一定能恰好填满，可能会多出一部分（少一部分就会留黑，肯定不行），从这个上面上来说，肯定是切的越小越好，因为这样就算有浪费，最多也就浪费一个图块的宽度。但是图切的太碎，会对渲染效率产生影响。从调试信息可以看到有个GLVerts，verts越多，显示效率就越低。

        但是如果切太大，内存又会有影响，比如我切个512的方块，假设屏幕是960X640，那么极限情况下，最多会同时显示4块（请自行想象在田字格的中间放一个方框，方框就是屏幕），这样就达不到节约内存的目的。

        一般128或者256应该就差不多了。

        然后把大图切小，分别命名。这图怎么切，当然是叫美工用PS切啊，命名，手动啊。。。当然这是开玩笑，你要真这么弄，美工不把你砍死。。。作为程序员，就是要会偷懒嘛，写个程序就切了，python的。虽然我也不是很会python，只会基本语法。但是python库多啊

 

[python] view plaincopy
 
  1. import Image    
  2. import sys    
  3. import os.path    
  4. from  datetime  import  *      
  5. import random    
  6. import time    
  7.     
  8.   
  9. IMAGE_PATH = "map.png"  
  10.   
  11. xIndex = 0  
  12. yIndex = 0  
  13. cropSize = 256  
  14. xNum = 0  
  15. yNum = 0  
  16.     
  17. im = Image.open(IMAGE_PATH) #打开图片句柄    
  18. pSize = im.size  
  19.   
  20. xNum = pSize[0]/cropSize  
  21. yNum = pSize[1]/cropSize  
  22.   
  23. print "size  " ,xNum,'  ',yNum  
  24.   
  25. for yIndex in range(yNum):  
  26.     for xIndex in range(xNum):  
  27.         print "pic : " , xIndex , "_" , yIndex  
  28.         box = (xIndex*cropSize,yIndex*cropSize,(xIndex+1)*cropSize,(yIndex+1)*cropSize) #设定裁剪区域    
  29.         region = im.crop(box)  #裁剪图片，并获取句柄region   
  30.         name = "/Users/apple/Desktop/result/map%s_%s.png" % (xIndex,yNum-1-yIndex)  
  31.         region.save(name) #保存图片    
  32.         # xIndex = xIndex+1  
  33.         # yIndex = yIndex+1  
  34.         print int(time.time());    
  35.     

        这样图就切好了，名字也起好了，而且还不用和美工撕逼或者装孙子。。。

 

 

        再说铺砖，也就是把图块放在地图上的方法。

        这里会有2个需要区别的东西，一个是坐标，就是offset的那个坐标。一个是index，就是图块的index。因为按照上面的图块命名，坐标是map0_0 ，map0_1这样的规则。

        大概思路应该是这样的，首先，获取winSize，计算横竖2个方向需要多少图块才能铺满，向上取整。

 

[cpp] view plaincopy
 
  1. xTileNum = winSize.width/tileSize;  
  2. yTileNum = winSize.height/tileSize;  
  3. xTileNum+=1;  
  4. yTileNum+=1;  

        然后，根据scrollView的offset，取得左下角那个图块的index，知道这一点应该用那一块来铺。

 

 

[cpp] view plaincopy
 
  1. Vec2 offset = view->getContentOffset();  
  2.   
  3. offset.x = fabsf(offset.x);  
  4. offset.y = fabsf(offset.y);  
  5.   
  6. int xStartIdx = offset.x/tileSize;  
  7. int yStartIdx = offset.y/tileSize;  

        然后，在横方向，和竖方向上，铺满

 

 

[cpp] view plaincopy
 
  1. for (int i = 0 ; i<xTileNum ; i++)  
  2. {  
  3.     for (int j=0; j<yTileNum; j++)  
  4.     {  
  5.         int xIdx = xStartIdx+i;  
  6.         int yIdx = yStartIdx+j;  
  7.           
  8.         char name[128];  
  9.         sprintf(name, "result/map%d_%d.png",xIdx,yIdx);  
  10.         Sprite* tile = Sprite::create(name);  
  11.         tile->ignoreAnchorPointForPosition(true);  
  12.         int posX = tileSize*xIdx;  
  13.         int posY = tileSize*yIdx;  
  14.         tile->setPosition(posX,posY);  
  15.         contentLayer->addChild(tile);  
  16.     }  
  17. }  

        这样，就铺满一屏幕了。

 

        然后来说说滚动的时候的处理方法。

        上图很清楚，要补充的是绿色区域，要去掉的是左上的那2条，中间的是不用动的。这个地方能想出一万种算法来做。我用的是一种简单直接的，但是绝对不是效率最高的。因为最后你会发现这点效率完全没有什么卵用。。。。
 
        首先需要这么几个东西
[cpp] view plaincopy
 
  1. #include <algorithm>  
  2. #include <unordered_map>  
  3. #include <set>  
  4.   
  5. using namespace std;  
  6.       
  7. unordered_map<string, Sprite*> curTiles;  
  8. set<string> curKeys;  
  9. set<string> newKeys;  
        其实想法和简单，就是把每次加入的图块sprite，放入一个map，然后把移动过后，需要加入的图块，是全部的，不是新增的那一部分，放入一个map，然后对2个map取差集，就可以得出需要添加的部分，和需要删除的部分。
        但是为毛我只写了一个map确用了2个set。。。因为我没试过map能不能用stl的set_difference这个函数。。。大概就是这样
[cpp] view plaincopy
 
  1. // 统计需要显示的图块  
  2. newKeys.clear();  
  3. for (int i = 0 ; i<xTileNum ; i++)  
  4. {  
  5.     for (int j=0; j<yTileNum; j++)  
  6.     {  
  7.         int xIdx = xStartIdx+i;  
  8.         int yIdx = yStartIdx+j;  
  9.           
  10.         if (xIdx>15 || yIdx>15)  
  11.         {  
  12.             continue;  
  13.         }  
  14.           
  15.         char name[128];  
  16.         sprintf(name, "result/map%d_%d.png",xIdx,yIdx);  
  17.           
  18.         string key = string(name);  
  19.         newKeys.insert(key);  
  20.     }  
  21. }  
  22.   
  23. set<string> results;  
  24. //在旧集合中去掉新的集合的元素，得到该移除的部分  
  25. set_difference(curKeys.begin(), curKeys.end(), newKeys.begin(), newKeys.end(), inserter(results, results.begin()));  
  26. for (auto it=results.begin(); it!=results.end(); it++)  
  27. {  
  28.     curTiles[*it]->removeFromParent();  
  29.     curTiles.erase(*it);  
  30. }  
  31.   
  32. //在新集合中去掉旧的集合的元素，得到该添加的部分  
  33. results.clear();  
  34. set_difference(newKeys.begin(), newKeys.end(), curKeys.begin(), curKeys.end(), inserter(results, results.begin()));  
  35. for (auto it=results.begin(); it!=results.end(); it++)  
  36. {  
  37.     Sprite* tile = Sprite::create((*it).c_str());  
  38.     tile->ignoreAnchorPointForPosition(true);  
  39.       
  40.     int xIdx = 0;  
  41.     int yIdx = 0;  
  42.       
  43.     sscanf((*it).c_str(), "result/map%d_%d.png",&xIdx,&yIdx);  
  44.       
  45.     int posX = tileSize*xIdx;  
  46.     int posY = tileSize*yIdx;  
  47.   
  48.     tile->setPosition(posX,posY);  
  49.     contentLayer->addChild(tile);  
  50.   
  51.     curTiles[*it] = tile;  
  52. }  
  53.   
  54. curKeys = newKeys;  
  55. newKeys.clear();  
        然后还有最重要的一步
[cpp] view plaincopy
 
  1. Director::getInstance()->getTextureCache()->removeUnusedTextures();  


        再说效果。代码这就写完了，然后上甄姬测试吧。
        然后跑起来之后，你就会发现，妈蛋，怎么还是这么卡的不要不要的。还不如全部加载了流畅。
        看几个性能参数，内存，效果很明显，GLVerts，效果也很明显。那为毛还这么卡，一定是我的替换算法写的太渣了。然后在算法的起始和结尾输出时间。发现基本可以说是秒过，完全没有性能瓶颈。
        控制变量法，其他不变，把图块sprite的纹理全部换成一个图，再一跑，发现流畅无比，各项参数都是很牛B的。
        
 
        综上可知，应该是可推测。如果是绘制的问题，那么每次都需要绘制新的图库，都应该一样的卡才对。
        在2次测试中，唯一的区别，就是把每次都去读取新的图片纹理，换成了用缓存中已经存在的纹理。那么推测应该就是在用新纹理创建新的sprite这个地方卡住了。
[cpp] view plaincopy
 
  1. bool Sprite::initWithFile(const std::string& filename)  
  2. {  
  3.     ... ...  
  4.     Texture2D *texture = Director::getInstance()->getTextureCache()->addImage(filename);  
  5.     ... ...  
  6. }  
[cpp] view plaincopy
 
  1. Texture2D * TextureCache::addImage(const std::string &path)  
  2. {  
  3.     ... ...  
  4.     image = new (std::nothrow) Image();  
  5.     ... ...         
  6. }  
        从这里看，在创建新纹理的时候，用到了fileUtil，也就是说读了文件，也就是说这个地方有IO，然而IO是很容易卡的。
        下面是输出时间：
[cpp] view plaincopy
 
  1. -------1--------  
  2. ------- time stamp : 1386769052  
  3. -------2--------  
  4. ------- time stamp : 1386769053  
  5. -------a--------  
  6. ------- time stamp : 1386769053  
  7. -------b--------  
  8. ------- time stamp : 1386769084  
  9. -------a--------  
  10. ------- time stamp : 1386769084  
  11. -------b--------  
  12. ------- time stamp : 1386769115  
  13. -------a--------  
  14. ------- time stamp : 1386769115  
  15. -------b--------  
  16. ------- time stamp : 1386769147  
  17. -------a--------  
  18. ------- time stamp : 1386769147  
  19. -------b--------  
  20. ------- time stamp : 1386769182  
  21. cocos2d: TextureCache: removing unused texture: /private/var/mobile/Containers/Bundle/Application/C85C52CF-396B-4630-A4AE-11A412D8C060/Hello iOS.app/result/map10_3.png  
  22. cocos2d: TextureCache: removing unused texture: /private/var/mobile/Containers/Bundle/Application/C85C52CF-396B-4630-A4AE-11A412D8C060/Hello iOS.app/result/map10_2.png  
  23. cocos2d: TextureCache: removing unused texture: /private/var/mobile/Containers/Bundle/Application/C85C52CF-396B-4630-A4AE-11A412D8C060/Hello iOS.app/result/map10_0.png  
  24. cocos2d: TextureCache: removing unused texture: /private/var/mobile/Containers/Bundle/Application/C85C52CF-396B-4630-A4AE-11A412D8C060/Hello iOS.app/result/map10_1.png  
  25. -------3--------  
  26. ------- time stamp : 1386769184  
        1是开始计算新图块的地方，2是开始添加新图库的地方。3是整个完成。a是创建图库sprite前，b是创建图库sprite之后。
        整个过程耗时132ms，也就是说此时FPS只有10不到。其中最慢的几个地方，都是在ab之间，差不多30ms左右。再次说明和之前那个效率不算太高的替换算法关系不大。。。

 
        本文标题之所以跟了一个“初”，是我觉得这种方式如果优化一下是可行的，虽然我不知道怎么弄，有知道的麻烦通知我：dinko@126.com

 

        所以我觉得这种方式暂时是不靠谱的，还是乖乖用tiled去拼，或者分层来做吧。

 

 

PS:

        其实还有一种做法，类似google map和百度地图那样，在滚动的时候不加载，滚动停了之后再加载。但是人家那是APP啊，游戏这样做你看效果如何。分分钟删游戏

posted on 2015-10-22 14:35  星之白菜  阅读(918)  评论(0)  编辑  收藏  举报
Copyright © 2024 星之白菜
Powered by .NET 9.0 on Kubernetes Powered by: 博客园