安卓上写游戏工具库真的不多,写个游戏全是用OPENGL ES编码实在是写的蛋疼,所以搞必要的封装是必须的。
目前NDK已经支持纯C/C++的开发,当然哥感觉只是GOOGLE将一个叫nativeActivity的类封到SDK而已,不过已经比以前好很多了。
初次接触OPENGL开发,感觉比DX好用,只要有3D数学基础就可以用,但直接用有点太麻烦,所以哥决定对ES版的进行二次封装。
啄木鸟图形框架构思
为了搞这个库,哥参考了大量开源的代码的设计理念,比如cocos2d,orge,osg等的设计理念。
数据结构库
框架提供自己的数据结构库,类似于STL的库,不过我针对性的优化过,使用一定程度上使用了内存池,同时也支持像STL那样自定义ALLOCATOR的方式分配内存。
目前库有2种主要的容器,线性容器和树形容器,线性容器有动态数组两种分别是使用连续内存空间的扩展和缩小,和使用不连续连续内存空间扩展和缩小的动态数据,双向链表也有两种不共享内存池和共享内存池。
树形容器有使用三叉平衡搜索树实现的MAP,功能跟STL的MAP一样,但不会跟STL那样插入删除都要对数据进行排序,平衡方式使用AVL的平衡方式(有些人问为啥不跟STL一样用黑红树,原因很简单,这个实现简单,而且主要目的是快速搜索,针对数据流作为索引的操作,而且需要平衡的节点并不会跟STL那样庞大,在使用1个BYTE作为记录的字符串的时候最大只要8次翻转(lg2(256)),当然这个比较极端了,大部分情况下都只需0~3次翻转就能实现平衡),数据排序使用遍历的方式获取,支持通过索引顶点输出排序序列。特别要说的是对于线性流特征的索引(比如字符串,数字串)有超神速的查找速度(复杂度在最坏的情况下是m*lg2(n),平均情况是m+lg2(n),最好的情况就是m,m是数据串的长度,n是字符集的大小,最好情况下将字符串数一次就能得到结果),对于在有限集大数据索引情况下,搜索速度不亚于HASH表,甚至超过HASH表。MAP跟STL的一样不支持同一索引多个值,所以有MULMAP来实现,原理简单,使用MAP+某一线性容器实现。在使用字符串做搜索索引的时候速度在STL的5倍设置以上,哥分别用6K个英语单词,80000输入法字库(生成大约250000节点),320000搜索字符(大约1000000节点),均做测试,哥的索引性能稳定,搜索速度,插入删除速度均在STL的MAP 5倍以上(插入删除原则上应是STL的快,因为黑红树统计性能更高,原因在于STL要做排序,挪动内存),方便查找以某数据串开头的所有数据,算法复杂度是在搜索复杂度的基础上加上符合数据的数量。
数据结构库目前是第3个版本,考虑使用怎么样的开源协议开源。
底层管理库
主要是内存管理等操作,分配地址对齐内存,内存池管理等
使用自己的内存管理,使用上面动态不连续的数组加MAP和HASH数组实现,动态不连续数据可以设置步长等操作,通过参数设置分配内存的大小,将内存分为256B,512B,1KB,2KB,4KB,8KB,16KB,1MB,2MB,4MB的分块进行管理,当然这个也可以通过参数自定义设置,内存不会一次分配太多,当需要的时候才分配,分配完后不会释放,删除内存只删除MAP或者HASH数组中的索引,下次分配的时候优先从被删掉节点中获得,当然这样系统内存实在没用或者你感觉程序用的太多的时候,可以使用类提供的整理内存的方法释放没用的内存块,同时将内存整理到一起,当然这个比较花时间。
平台库
将操作系统的相关的操作放在这,主要是窗口,输入输出设备等,提供接口。
图形库
分3部分,图形中间件驱动,渲染系统,3D数学库
使用图形中间件驱动与渲染系统分离,这样能灵活更改底层图形渲染库,比如将原来是OPENGL版的库移植到WINDOWS平台,并使用DX渲染,对整个框架的改动量小,这样扩展性非常强,但整个系统的性能会受中间件驱动影响,所以这个驱动要做的性能足够的高,目前哥已经改到第2个版本,计划在第3个版本的时候发布。目前第2版的库只要的封装是VBO,FBO,RBO,VERTEX BUFF,INDEX BUFF,纹理对象和一些状态和标志的封装类,使用时需要3D数学基础,对状态的管理更改人性化,减少平时维护OPENGL状态的一些蛋疼的操作。
渲染系统是个设计成完全平台无关的库,使用中间件驱动提供的接口,对渲染对象进一步封装,目前哥只开始写第1个版本,还没搞完,里面只要有的封装:
摄像机类,计算维护3D坐标转换等操作当然只有世界坐标,投影坐标,视图坐标而已,最后会算出个矩阵扔给显卡做顶点计算。
精灵类,维护一些纹理操作,以及这些纹理绑定的顶点。
网格类,主要是维护顶点间关系,纹理中坐标关系等操作。
工具类,提供画线,画2维简单图形(三角形,正方形,圆形等),3维简单图形,图形染色等操作。
画板类,是一个场景管理类,管理当前所有的渲染对象,哥还没想好用八叉树,二叉树,还是自己搞个渲染方式,八叉树貌似用于实时3D渲染压力很大,搞不好还只能自己搞个。
场景扩展接口,提供一个接口让写应用程序的人按实际应用实现。
当然搞完这后渲染就基本可以比较简单的做了,只要输入模型的坐标,设置好摄像机就能做。
数学库目前也是第1个版本,考虑在第2个版本开源。
目前库还在设计中....扩展设计有什么不合理的地方欢迎指教