时隔半年，模拟器一直没有更新，那么这半年到底发生了什么？
除了日常的相亲任务(误)和求生任务以外以及为了测试新买的显卡而玩起了打枪游戏……
不过模拟器这部分的开发进度相比之前虽受影响，但并未中止。
现阶段大致的开发计划如下：
※目标是实现EmoteD3D
←需要实现其依赖的drawdeviceD3D
←新版的drawdeviceD3D使用了部分krkrz的新特性
←为在代码层面兼容krkrz，决定从底层重构整个基本架构
←需要调整兼容性的模块包括图形渲染，音频，视频，线程管理，字体，文件系统
音频、文件系统与原krkr2相比变化不大，很简单就适配完成。
线程管理变化也不大，不过在适配过程中发现了1.2.0版本后带来的一个bug，有低概率随机崩溃，狂汗……
krkrz的字体系统也引入了freetype的支持，于是我自己实现的那一套就作废了，改用krkrz的方式。
视频回放模块整个重写了，之前参考ffplay的设计，虽然简单快捷但是对硬件解码不友好，于是趁此机会做好对支持硬件解码的准备，现阶段已重新实现软件解码(ffmpeg)的回放，硬件解码的支持计划在未来的版本中更新。虽然目前还没支持硬解，但新的设计可以利用shader实现覆盖(overlay)模式下的yuv420图像数据的直接上屏，少了转换像素格式的步骤，也能在一定程度上提高回放的流畅度吧。
渲染系统是整个工程里最复杂的部分了，在写这篇日志时渲染系统的适配还未完成。漫长的开发过程中总是忍不住尝试一些新的想法，导致日程表一再拖延……
其中之一就是动态纹理压缩。ogl渲染下的高内存占用实在是一大痛点，现有的简单粗暴的纹理压缩，其实是纹理分辨率劣化，直接糊你一脸。因此更佳的手段就是混合使用真正的压缩纹理。在加载大图片后，在后台慢慢压缩成etc或者pvrtc格式（视GPU而定，见http://tieba.baidu.com/p/3992246625），并缓存在sd卡上备用以减少CPU的重复劳动。当然这个功能会是可选的。
另一个更加重要的就是高级混合(advanced blend)。这个特性在opengl es3里比较普遍，但es2里也能以扩展的方式利用。阅读了一番khronos官网的资料后，得知两个重要的信息：
1.es2是es3的子集，就算声明设备运行在es3标准下，依然可以无痛移植基于es2设计的代码。
2.es3的大多数特性可以在es2下以扩展的形式使用，因此基于es2设计的代码可以顺利过度到es3下，并通过检查对指定扩展是否支持来实现对旧标准的兼容。
3.（这条不是标准提的，是谷歌提的）安卓在升级到4.3以后都有对es3的支持，而这一版本以上的系统已经占领了大部分市场。至于iOS，苹果表示在6.0以上的系统都已早早支持。现在还能用的iOS设备估计都是7.0起跳的了吧。
综上，es3带来的优势已经非常值得将其特性的支持加入开发计划中，而其中的高级混合这个特性，能迫切满足之前困扰已久的SxD→D的渲染流程（见http://tieba.baidu.com/p/3753222696），从而解决大部分的掉帧问题。
在调研了一段时间es3的特性清单后，意外发现了一个早在2006年NV就提出的古老扩展，着色器帧缓存存取(shader framebuffer fetch)，用可编程的着色器同样可以实现高级混合。相隔十年才到来的邂逅，实在相见恨晚。这个特性覆盖了绝大部分es2设备的gpu，已知的包括ARM的Mali系列，PowerVR系列，NV的Tegra系列，高通的Adreno系列等。
至于实在是渣到想摔的设备，也可以用保底的“渲染到纹理”（就是现在用的……）技术保证效果正确，但是效率就不敢保证了……
下一版本模拟器因为改动较大，决定提升副版本号一位到1.3.0，并因为使用高级混合，将去除渲染器选项里的“复制目标纹理”，因为基本上没什么设备同时不支持上述两个特性，就算有，估计也无法保证目标纹理的同时读写。
先到此为止，我都觉得够贪心了，下个版本先把这些都测稳定了再谈别的吧。
嗯……最初的计划是什么来着？