为什么switch性能不如手机，手机却不能模拟switch游戏？ 第1页

作为一名参与过switch游戏移植的图形开发者过来简单说一下，下面几个方面是switch性能优势所在：

1.switch 4gb内存运行时可以给到3.3gb内存我开发使用

2.switch原生图形API是任天堂和英伟达专门针对x1开发的，不同于opengl和dx，代码专一且效率极高

3.我们优化图形渲染使用官方推荐的延迟渲染，性能较前向渲染高很多

4.本身是ARM芯片加上主动散热，插上底座还提高x1运行频率，性能可以长期保持峰值稳定状态

5.三款ns都是用的x1，保证美术场景开发的统一性，基本可以做到基于硬件上限最优美术效果

顺便说一句，别说目前主流手机玩switch模拟器做不到，就是专门针对中端以上手机开发的游戏也很难达到任天堂第一方的游戏品质。其中需要解决的技术些许列举几点：

1.大场景流式加载卸载，也就是无缝大地图，强调对内存的管理

2.支持相对新的图形技术，包括曲面细分、延迟渲染、全局光照、计算着色器等

3.物理算法引擎甚至化学算法引擎的支持

--------------------------------------2021.1.10 18:21---------------------------------------------------

刚回来看到点赞还挺多，而且评论区有一些小讨论，刚好有点时间就稍微写多一点，我个人的话并不对switch和phone有偏见，只聊以我浅显的知识面和开发经历聊一下游戏图形技术。

在一个游戏中（这里以卡通游戏为例），我会针对如下美学需求做着色开发：

人物篇

1.基于NPR的光照算法，也就是通常我们说的卡通光照算法。

皮肤：不同于PBR（通常我们称为真实物理光照），NPR在光照分量（LightDir、NormalDir、ViewDir、TangentDir）的混合计算中使用smoothstep或step进行二值化插值，营造出传统卡通片中人物受光后“黑白分明”的视觉感受，当然不限于使用ramp texture或其他数据采样texture计算。

头发：使用Marschner或前言paper上的毛发光照算法，使用光照分量SubTangentDir（发根到发梢）等参与二值化区分的光照计算。

描边：基于空间三角面共边的边缘边查找算法，使用基于视口向量和法向量判断“正反面”的边缘边查找法，使用几何着色器或者后期Image着色器的线段渲染

网格：基于LOD的二重或三重权重网格做基于视口距离的细节渲染，使用曲面细分和高度置换的GPU精细网格渲染

etc

场景篇：

场景体积云：基于噪声算法的多网格交叉渲染体积云

场景体积光：基于光柱网格和uv光色插值贴图的体积光

屏幕体积光：基于后期的片段屏幕坐标和光源屏幕坐标的叠加和衰减

屏幕光散：基于后期的二维纹理的片段frag函数的高斯滤波和二重亮度增强

场景水：基于fft扰动和noise扰动和fresnel折射以及其他光照分量计算组合的渲染效果

场景火：基于noise或预置扰动的十字网格或公告板渲染效果

场景草：基于Geometry Shader的草型网格GPU生成和uv映射，包含noise扰动和基于uv点的圆形展开法向量NormalDir扰动

屏幕反射：基于ScreenSpace和对称矩阵的后期二维纹理采样倒置渐隐反射效果

屏幕波动：基于后期二维纹理的三角函数uv步长周期扰动计算

etc

物品怪物篇：

粒子化：物品或者怪物粒子化，基于几何着色器，geometry shader的顶点：立方体映射生成

消失化：物品或怪物消失化，基于noise扰动的uv纹理或者后期二维纹理的fragment discard

着色化：物品或者怪物高亮着色，基于空间网格扩展subpass渲染或者后期commandbuffer采样texture进行gauss filter扩散fragment渲染

etc

光线追踪：

基于硬件支持的光追，基于CPU软光追，基于计算着色器的混合光追。

只是列举了一部分我自己常用的技术，当然还有技术更复杂效果更好的渲染feature。

接下来说一下switch和phone的区别，结合我日常开发来说。

我大概12年就做phone和pc web外包软件，其中有一个重要的性能指标，连老板都亲自盯着（公司就几个人，外包公司嘛，说的有点夸张，老板也就是技术经理和产品经理和会计人事一身的老程序员），那就是RAM内存，我自己写的程序老板就怕内存爆了，老板的要求要我在384mb内存android机器上必须能运行，要知道小米1和2都市面主流了。

为什么要特意谈我的往事呢？因为时至今日，这种RAM的要求都是存在的，一个游戏团队开发一款游戏，必须满足主流机器的运行，哪怕高端团队走高端路线，你得支持iphone11和iphone12吧？iphone 4gb的内存只会允许到开发者调用2gb级以内，因为phone必须保证自身操作系统基本运行和同级别的其它软件的基本运行。而且phone的游戏一直都是统一开发，iphone限制2gb RAM，那么android同样，而在嵌入式设备中，一般不会有独立的显存，都是使用lpddrx共用内存和显存，则2GB的限制会让phone的游戏开发的实时内容毫无疑问落后switch的3.3gb-3.7gb Use RAM（Switch的freebsd系统占用RAM极少，我未做极限测试）

再来说GPU方面，高端的嵌入式GPU（apple Ax和高通Adreno）目前使用的图形API是支持常用的图形技术的，然而metal和opengles/vulkan因为兼容众多GPU型号的原因，代码效率不如专用图形API，没错我说的就是不如sony的图形API和任天堂的图形API（联合Nvidia开发的），其中的不如包含性能效率不如、图形feature不如、精度运算不如等，具体参数我是没能力搞一个图表出来的。而这所谓的“三不如”表现上就是很细节的渲染方面，常见的渲染feature在switch和phone都可以实现，然而实现出来的最终渲染细节是不一样的。

再说开发engine方面，一方大作（不仅任天堂，包含sony和ms的第一方），inhouse engine可能在知名度上不如unreal、unity、cry、cocos、godot、flex、laya等，但是在与他们的“爸爸硬件”匹配程度上无可超越，包含最新的图形feature支持和最佳的运行效率以及极限的硬件压榨能力。

好，太冷了，我要洗澡躺床上看书了。

------------------------------------------2021.1.11 10:31-----------------------------------------

上班有点无聊，逛了下知乎，看到这个回答点赞还挺多的，那么接下来再多写一点，谈谈如果我是一个ns模拟器开发者，我要怎么开发手机版ns模拟器。

首先pass掉iphone，未越狱几乎不可能，越狱后勉强能搞一搞3ds psp ps2之类老世代模拟器开发

那么下面只谈android版本模拟器的开发，首先上几个资料链接：

1.https://www.androidauthority.com/how-much-ram-do-you-need-in-smartphone-2019-944920/

2.https://stackoverflow.com/questions/5887248/ios-app-maximum-memory-budget

3.https://en.wikipedia.org/wiki/Nintendo_Switch_system_software

4.https://developer.nvidia.com/content/tegra-x1

5.https://nintendotoday.com/switch-3-gb-ram/

6.https://blogs.nvidia.com/blog/2016/10/20/nintendo-switch/

7.https://www.nintendo-insider.com/nintendo-switch-supports-vulkan-opengl-4-5-and-opengl-es-3-2/

首先我们要看下上面列举的几个链接资料，因为涉及到“梯子”可能无法打开，我简单总结一下：

1.android phone虽然目前主流8gb RAM了，但是note8允许我们最大使用2.5gb RAM Single App，其他phone允许Single App Use 2GB more or less。

2.iphone11允许2gb Single App否则Crash It

为什么我特意强调好几次RAM使用呢？因为我们开发申请堆内存，如果物理内存不足无法申请了，程序就崩了。或者说物理内存足够，但是超过操作系统限制的申请极限，操作系统也把我的app kill了，而这个极限在phone上普遍是2.5gb左右。

3.ns操作系统是freebsd horizon精简系统，原生GraphicAPI为NVN（并支持vulkan和Opengl和Opengles），图形卡为256core的maxwell构架。

4.ns允许开发者使用3GB RAM运行单一进程的游戏，我自己试过用到3.3gb

那么通过以上我们能得出什么结论呢？

如果我开发一个ns模拟器，用敏捷迭代开发。

那么第一步我会选择开源的android phone，假设我模拟器申请上限2gbRAM（为了考虑众多中高端机型），那么我需要尽可能开发出精简到极限的运行时框架，最好500mbRAM占用以内，同时先支持vulkan和opengles图形API，则剩下1.5gb就可以给支持vulkan和opengles（甚至包含部分pc上opengl移植过来的小游戏）游戏运行时使用。那么我这个ns模拟器就只能玩一些跨平台的第三方或者独立游戏（就是需要游戏RAM开销够小，API够跨平台），这类游戏其实也很多的，ns被称为4399游戏机一个大原因就是很多移植游戏都是从phone上或者steam独立游戏移植过来的，他们的特点就是跨平台和开销够小（开发之初就考虑过phone上的各种参数限制的，为了囊括用更多phone用户，基本都控制cpu gpu使用率50%以下，RAM使用1gb以内，不然phone要不就发热发烫，要不就kill app）

举个例子：和平精英运行时也就1.2gbRAM

再举个例子：IOS版本知乎app有内存泄漏，已经好几个版本没修改了，在2gbRAM及以内 iphone上多刷几个帖子，就会出现申请不到RAM，页面加载不出，然后再触发系统机制kill app。

第二步，我就要做一些黑客的工作了，首先想方设法突破android system operation的限制，申请更多RAM，以最高权限杀掉其他除我ns模拟器以外的process，释放更多内存给我用。假设我要考虑一个ns上跨平台的大作（大作使用了vulkan，且极限压榨了3.3gbRAM），那么我ns模拟器就需要至少申请0.5gb+3.3gb=3.8gbRAM（一般不止，我们就当需要4gb），则我们需要6gb物理RAM以上的phone，soc性能不谈（虽然soc在没有散热的情况下长时运行是要打个三五折的，我们就当soc性能强于x1），则我开发的ns模拟器可以在2000+档次phone上短时间运行（30分钟以内）畅玩“3A移植大作”。

第三步，我就要做逆向工作了，我想让我的ns模拟器玩nintendo第一方大作，三方面入手：

1.通过CPU软模拟NVN API，那基本就是十倍性能差，也就是我需要SOC比x1实际性能强十倍，基本不可能，PC上还可以搞一搞。

2.硬件驱动，我是一个超级大佬，我完全实现了一份phone SOC的nvn驱动API，且几乎效能同等，因为x1是maxwell构架，不同于arm mali，只能自己重写实现。

3.我是一个专门搞游戏软件逆向破解和开发的，我把荒野之息的源码和资源全部反编译出来，用通用engine重新复刻一遍，支持vulkan，这个人是不可能，除非官方多年后自己搞高清重制版。

那么就只有第2的工作可以做，同时我顺便将ns的freebsd horizon系统也完全实现了一份。

此时我只需要放出一个ROM，就是适配phone的包含ns操作系统和graphic驱动的刷机包，让1000-1500档次的android phone直接刷成ns，再卖我自己定制的phone散热器。

市面上ns模拟器我没用过，毕竟老加班狗子了，根本没时间玩，不知道到了哪一步。

有大佬提醒了我还可以wrapper，也就是两个图形API的映射封装（就是函数和函数的映射封装，或者功能和功能的映射封装），那么我们可以在尽可能应用层不变的前提下，更换图形底层（类似偷梁换柱），也是可以做到xx%适配运行（运行效率和运行正确性，性能损失百分比，图形渲染错误百分比）当然这种wrapper也是需要一个长时间的完善过程

这种方式也是可以让我们解决图形API大部分的兼容问题，如果遇到很高级别的图形特性无法映射，也会fallback回滚到低级别的图形特性，满足能看就行、没崩就好。