有时会发生「无法确保位图用内存/…」或「Cannot allocate memory for Bitmap：……」这样的错误。
由于画面分辨率变高等而发生的情况似乎变多了。
吉里吉里Z与2相比，虽然难以发生但并不是不发生的错误。
但是，通过设定可以减少发生。
原因
游戏中出现这个错误与其说是内存真的不够，还不如说是内存碎片造成的。
如果将需要图像等大块的内存占用与小类和字符串等内存占用混在一起的话，就容易发生内存的碎片化。
如果内存碎片化发生的话，就不能分配大块内存，想要分配位图用内存等大块内存就会失败。
对策
根据内存管理算法的种类不同，也有不容易发生碎片化的算法，所以采用它也是一种方法，Windows Vista以后采用了不容易发生碎片化的算法，碎片化概率被降低了。
在XP中启用LFH也有类似的效果（吉里吉里Z在Vista和更高版本始终启用）。
但是，即使启用该功能，也会发生这种情况，因此还有执行内存压缩和分离图像用的内存区域的对策。
压缩
压缩是指连接与内存相邻的空闲区域，使其成为大的连续的空闲区域。
内存的分配/释放在多次进行的情况下，在某种程度上负荷会变高，所以请偶尔执行。
吉里吉里Z通过附加-ghcompact选项（可以从引擎设定中指定），在调用System.doCompact的时机进行全局堆的压缩。
由于这是一个稍有负担的处理，因此默认设置为无效。
如果在作为目标配置的下限CPU中启用也能无压力地运行的话，作为默认启用发布没有问题。
分割堆
通过将只确保较大领域的位图用内存与其他内存分离，防止碎片化的发生。
可以从引擎设定中指定。
默认设置是从进程堆中确保的，多数情况下这样没有问题。
如果测试时发生错误的话就尝试一下，要减少错误的话就把分割堆作为默认设定比较好。
调用GC
在脚本中，场景切换的后台转换时等呼叫System.doCompact会有一点效果。
不使用图像缓存
不使用图像缓存，或者尽量减少容量，这对抑制内存碎片有效果。
即使采取上述对策，效果不显著的话，不使用图形缓存也是值得探讨的。
如果不使用图形缓存，特别是在快进的时候会明显感觉到负载很重，但是在最近CPU和SSD配置的环境中并没有那么令人担心，所以没有缓存应该也没有问题。
使用64位版本
进行上述全部对策也没有效果的情况下，最好讨论使用64bit版这一终极对策。
可以充分利用堆积的内存，也可以消除大量分配内存却发生错误的不满。
渐渐地，无论在哪个环境下，64bit都是理所当然的，所以不谈内存不足，今后最好也准备好64bit。