阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 zhihu.com/question/50076174 「红白机」欢迎转载，保留摘要，谢谢！

• 分析
• 总结

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

大家好，我是基基！

分析

个人觉得fc最神奇的游戏还属超级玛丽，32个关卡，每关都不同，各种隐藏要素，好像代码区才10多k，数据区10多k。反汇编看完还是不敢相信这点东西能玩一个童年… 现在helloworld的二进制都可能比这大多了。

首先128k并不小，主要消耗存储空间的不是程序。当然对于128k来说程序大小自然也要考虑，鉴于fc是八位机而且FC采用的是CISC处理器，一条指令就能完成很多事情，所以程序的大小也就现代64位RISC处理器的十几到几百分之一。

资源才是大户（包括图像、音乐、地图数据、关卡数据等等）。就拿图像和音乐来说，图像在没有压缩之前 消耗存储空间和像素深度和大小有关。FC上的图像，像素深度就2bit的索引而已 ，现在广泛使用的真彩色是24bit，包含alpha的需要32bit，这里就差了12倍到16倍。图像大小更是差距巨大，FC普遍一个角色也就是宽高十几个像素而已，与现在动辄宽高几千像素图像资源相比差了数万倍到数百万倍，所以图像资源消耗的存储空间至少差了5～7个数量级。

音乐的话，FC采用的是8位midi音乐，而现在普遍用的是PCM音乐。类比到图像中，就像矢量图像和位图的区别。总之PCM音乐的大小和采样深度、采样率、通道数以及长度有关，midi仅仅和谱子的复杂度有关，所以FC实际上对空间的要求和现代游戏相比至少差了5～7个数量级。你把128k放大10w倍到1000w倍，你就不觉得小了。

对于什么64k 3d程序什么的，这完全是两码事，FC程序小只是因为需求的资源本来就很小而已，而那种64k 3d程序是因为采用Procedural generation方法，简单的说就是通过数学来描述，而不是通过记录结果的采样，Procedural generation不光需要的存储空间极小，而且可以做到无限精度，缺点是难以描述复杂事物，并且对算力要求高，而不是用了什么外星压缩法。

总结

1.游戏大量复用图块，图块还使用调色板索引，好像每个像素才占用2bit。 2.程序员精心优化各种数据结构，每一bit存储都不浪费。 3.声音只存储发声通道的调制参数序列，能复用就复用。 4.代码全是汇编写成，直接操作硬件，基本不存在浪费的指令。