《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.代码全是汇编写成,直接操作硬件,基本不存在浪费的指令。

文章目录
  1. 1. 分析
  2. 2. 总结