自灾后重建以来已经过了一周，随着物资补充并伴随荷包缩水，一切又渐渐地回到正轨（TMD我下个月就搬出这鬼地方）。
代码重构并发布1.2.0后，果然如预料内的bug不断……基本代码有改动到的地方都出bug了，所幸这种事情只做一次就够了。毕竟不用理解别人写的代码，而变作自己完全熟悉并理解的系统（这才是重构的目的？）之后无论要改动还是扩展都容易不少。
beta4发布后感觉这个版本可以稳定下来了，也好继续接下来的新功能开发。
现阶段的模拟器最大的弊病就是内存的占用太多。PC端的游戏基本不用担心内存不足，毕竟有虚拟内存可用，最多变慢，而手机就不行了。特别是内存只有1G的手机，除开操作系统的占用，就只剩下200~300M的内存可用。然而有些情况下还没用到100M就闪退了。因此，有必要在内存利用率上做一些改进。
目前的想法是纹理在内存中存放形式做优化，而这又与渲染器直接相关，软件渲染器与OGL渲染器有不同的方式。
软件渲染器：
·区分只读纹理与可写纹理（存放中间结果），对只读纹理进行压缩；
·选择压缩方法：
1.使用索引表引用重复的行像素（针对重复的图像，比如全白、全黑、上下重复的图片等）
2.使用索引表令纹理行数减半（或更少，简单暴力地牺牲清晰度换取空间）
3.使用RLE或相似的快速压缩算法保存像素数据（简单暴力地牺牲CPU换取空间）
4.未知的外星技术
与现在的渲染器设计相比，唯一需要改动框架的部分，就是纹理需要增加行索引表。这个表的开销并不大，参与渲染时的CPU开销也可以忽略不计，唯一的缺点就是可能与某些插件不相兼容，这很可能成为潜在的需要长期测试并修正的漏洞。
GPU渲染器：
·同样区分只读纹理与可写纹理，并对只读纹理进行压缩
·选择压缩方法：
1.读取纹理而直接分辨率减半（或更少，同上）
2.读取纹理时针对设备的GPU（比如ADRENO系列、MALI系列、PowerVR系列、TEGRA系列……etc）选择对应的纹理压缩算法压缩后再传递给GPU（牺牲加载速度，同样是CPU换取空间的方法）
3.读取纹理后直接传递给GPU，后台利用空闲的CPU时间压缩纹理并更新（这或许不是个好主意，如果短时间内读取大量图片的话内存占用率反而会成倍增长）
4.未知的外星技术
OGL的框架没什么需要改动的地方，最大的问题或许就是各家GPU厂商提供的压缩算法基本都不考虑效率问题。毕竟用压缩纹理的都是在开发阶段用PC生成，再在手机端读取使用，很少有什么游戏或软件会在运行期间进行压缩。有开源的好算法自然最好，没有的话以我的能力是基本不可能改进什么的……
一眼看去这个计划又是一个深坑，是不可能也不适合一次性全部完成的。所以应该是一点点地实现，分散在各个版本中（也好测试出问题并及时修复，免得像这次1.2.0这样集中出现大量bug）。估计这个功能的完成也可以标志着1.3这个大版本更新了。
现暂定下一版本从修改软件渲染器架构支持纹理行索引表做起，到时还指望各位的测试协力了。