日志
SEGA Saturn模拟效能研究
热度 2 ||
Kronos从2018年12月推出，至2019年5月作者FCare在过去6个月中对OpenGL核心渲染器进行了完全重写，它允许和修复了大量图形问题。
Kronos使用的是高性能SH2缓存解释器，尽管与YabaSanshiro中使用的dynarecs不同，但CPU频率要求仍然比使用经典的SH2解释器（如甲虫土星）的模拟器低约30%。
2020年5月，发布Kronos 2.1.2，加入了新的OpenGL CS 视频渲染器，新渲染组件为OpenGL提供了很大的灵活性，并允许实现逐行渲染四边形例程绘制。精确地再现VDP1行为，这就是这个渲染器的目的，需要显卡支持OpenGL 4.3。
此处提供了兼容性列表
OpenGL CS视频渲染器
土星是怪兽，它有8个处理器，其中有2个自定义图形处理器VDP1和VDP2。VDP2处理背景，VDP1处理精灵、纹理和多边形。
VDP1是每行绘制一条“四边形”线，其基本思想是沿水平边插值端点，然后在这些端点之间绘制纹理线。它必须在斜率改变的地方用一个额外的像素画线，所以所有的像素都有一个相邻的左、右、上或下。他们这样做是为了防止线之间的空隙。
像OpenGL这样的现代图形api不知道如何做到这一点，因为它的渲染管道是基于三角形几何体的，所以基本上它不能再现VDP1的行为。有一些技巧，比如细化，但最终它们只是针对特定问题的解决方案，而不是针对这一问题的所有解决方案。不过，这里有一些好消息：在OpenGL 4.3中，引入了一个名为“计算着色器”的新功能，您可能已经通过Flycast的“顺序无关透明度”（order independent transparency）或N64的“并行”（parallel）中听说过它，这个新组件为OpenGL提供了许多灵活性，并允许实现逐行渲染四边形例程绘制。精确地再现VDP1行为，这就是这个渲染器的目的。
考虑到用现代GPU正确模拟VDP1有多难，它是否被正确模拟了？一个很好的测试是世嘉拉力赛的观赏模式：正确的VDP1模拟在道路上不会有洞，在边界上几乎看不到小点，如图1-3所示：
不像下图这样：
让我们做一些比较，从第一张到最后一张，这些图片是由土星实机、Mednafen/beetle、Kronos（OpenGL CS渲染器）、Kronos（旧的OpenGL渲染器，基于YabaSanshiro的）的屏幕截图。在这些图片中与VDP1处理行为有关的两个明显事值得注意：
* 道路边界：在控制台上，Mednafen和Kronos的新渲染器，如果放大，您会注意到它不是一条平滑的线，有点，这是准确的行为；最后一个屏幕虽然平滑线可能看起来更好，但实际上是不准确的。
* 到处都是孔：如果放大最后一张屏幕截图，您会注意到在山顶，后面的道路上到处都有一些孔，其它屏幕截图中不存在这些孔。
可以使用OpenGL渲染器解决这些漏洞，但最终最终会在此过程中产生其他问题。直到最近，我们仍使用这种解决方法，但对于世嘉拉力赛而言，它只是放大了道路边界上的点。这种新渲染器的唯一已知缺点是，它将需要一个相当不错的GPU！
---------------------------------------------------------------
世嘉土星不做3D，而是做3D变形的2D精灵
土星模拟器从技术上讲，OpenGL可以做四边形，在OpenGL或D3D中将这些四边形绘制为实际的3D对象，硬件上是通过三角形模拟的四边形，但这样的3D硬件渲染会产生大量图形渲染错误和其它各种各样问题，并且无法再现土星可以做出许多奇怪的效果（比如“蝴蝶结四边形”）。主要是API的一个限制影响3D加速，老实说，它需要至少有OpenGL 4.3能力的GPU硬件，在OpenGL 4.3中，引入了一个名为“计算着色器”的新功能，这个新组件为OpenGL提供了许多灵活性，并允许实现按行渲染四边形的例程。Kronos新的OpenGL CS渲染器在着手解决基于Yaba Sanshiro旧OpenGL渲染器上的问题，精确地再现VDP1处理行为是OpenGL CS渲染器的目的。
当主机硬件和PC硬件非常不同，并且PC硬件速度足够快，可以在软件中模拟主机硬件处理，一开始就这样做的有SSF。不过，SSF开发者也使用了DX11 GPGPU加速，在GPU上运行Saturn模拟器虽然仍然无法获得更高的分辨率，但你的CPU会被完全释放。
---------------------------------------------------------------
Yaba Sanshiro重新开始编写新的Vulkan图形仿真核心
源自Yabause开发失败项目已终止的分支，YabaSanshiro PC版也一度停更，因不恰当使用OpenGL受API的限制，硬件渲染不能再现土星VDP1的处理行为，产生出大量错误和其它各种各样问题，另外它的CPU编译器效率低下，在i7上达到70%出奇高的使用率，对于这些致命错误(Fatal Error)，接手该项目的日本开发者devMiyax，在10年当中由于技术原因一直未能解决。
2018年12月Yabause另一分支法国开发者FCare推出Kronos，接着花了半年时间对OpenGL核心渲染器进行了完全重写，它允许和修复了大量图形问题。大约一年后，2020年5月FCare发布Kronos 2.1.2，加入了新的OpenGL CS 视频渲染器，新渲染组件为OpenGL提供了很大的灵活性，并允许实现逐行渲染四边形例程绘制。精确地再现VDP1行为，这就是这个渲染器的目的，需要显卡支持OpenGL 4.3。到此，PC平台表现一直很烂的YabaSanshiro在技术上被Kronos完全取代。
在Kronos出现后，Yaba Sanshiro的后续开发重心移到了Android平台，Yaba Sanshiro在更名前叫uoYabause，因合并了OpenGL ES3.0硬件加速分支的Yabause，作为非官方Android移植版取名uoYabause在推出后不久被谷歌商店下架禁止了，原因是uoYabause该名称与Yabause过于相似，有购买用户向谷歌投诉uoYabause该移植付费版是一个欺诈项目，主因是原OpenGL无法正确模拟土星的VDP1处理行为，导致图形仿真存在大量致命性错误。有的用户在推特发文认为这款模拟器在VDP1、SH2、SCU 、SCSP这些部分上可能需要重做。
uoYabause在Google Play商店将其除名下架后，开发者devMiyax将uoYabause更名Yaba Sanshiro再次推出。图形仿真错误产生大量渲染错误和其它各种各样问题未能解决，使得Android版Yaba Sanshiro又因作弊功能涉嫌违反谷歌Play商店的设备和网络滥用政策（作弊功能可能会导致自动过滤器出现故障）再次被谷歌Play商店除名。
在遭遇2次除名下架后，近期，开发者不得不再度更名为Yaba Sanshiro 2 Pro重新上架谷歌Play，作弊功能已被删除，而为之前Yaba Sanshiro专业版付费的用户由于失去了他们的许可证，所以必须再次为此版本付费。
Android平台由于最新骁龙8 Gen 1只支持OpenGL ES 3.2，Yaba Sanshiro开发者无法像PC上的Kronos那样借助OpenGL 4.3灵活、准确的模拟土星的VDP1处理行为。Android上只能用Vulkan初步实现新的图形仿真核心，由于开发者devMiyax在4年前告知用户Vulkan不支持四边形渲染，只能通过镶嵌来处理。但PC平台多年以前的nVidia Maxwell GPU、AMD Radeon R7 250、英特尔MESA iGPU对于Vulkan的支持都可以实现ParaLLEl四边形渲染。
2020年12月27日YabaSanshiro开发者推特发文称准备重新编写新的Vulkan图形仿真核心，以便准确模拟VDP1、VDP2。
我重新开始使用#Vulkan实现新的图形仿真核心。到目前为止，我觉得好处是。
*可以分离VDP2和VDP1
*最大限度地减少和简化了仿真的实现。
*快速
由于土星模拟的瓶颈是多个VDP系统，硬件仿真必须分开来实现，此外，世嘉土星对CPU周期的要求非常严格，改变任何关于解释器的东西都可能需要重写与时序有关的一切。devMiyax接手Yabause后续分支版开发有10年以上，考虑到硬件渲染造成的弊端矛盾，开发中在解决新bug的同时又会造成其它问题，顾此失彼陷于技术矛盾的问题处理。新版Yaba Sanshiro较旧版在兼容性、稳定性难有明显改善下其它方面变得更糟，很长时间羁留在UI界面调整上，若非自身程序Bug太多影响到付费用户与谷歌Play平台网络管理，招致两次除名下架在EMU圈子影响较大，开发者可能不会想办法从其它方面进行弥补。
2022.3.15 开发者devMiyax在推特发文：“关于SH2缓存，它将在Yaba Sanshiro 2 Pro 1.8版本中提供。在1.8版本中加入了SH2缓存模拟，通过缓存命中率修正了某些游戏bug，略微改善一些兼容性。 经测试OpenGL下缺失图层问题严重，可通过调整设置解决，但会造成屏幕图层闪烁。Vulkan核心只能支持个别游戏。2022.3.27发布PC版1.8更新，测试运行情况比安卓版要好，但新版存在严重bug：暂定一会恢复运行后音频断音。切换全屏会使窗口上下黑边不断延长导致窗口/全屏切换失效，整体情况落后另一分支的Kronos。
Yaba Sanshiro对VDP1、SH2、SCU 、SCSP的仿真其实很不完善。开发者devMiyax在谷歌Play向用户坦言：“硬件模拟真的很难，Yaba Sanshiro并不完善，你可以在这里检查当前的兼容性。”
---------------------------------------------------------------
测试不同SS模拟器的声音表现
实机 (10分) = SSF PreviewVer (10分) > Mednafen Saturn (6分) > Yaba Sanshiro (3分)
CD数字音频是44.1KHz/16bit的PCM标准。bit位深越大，信噪比和动态范围越好，音色也就越真实、生动。
由于录音和播放设备都会有一定的底噪，事实上往往有2-3bit是被底噪信号耗掉的，在动态范围上有意义的位深只有13bit，这时实际的动态范围也就80dB左右，听一般轻音乐录音问题不大，但大动态的录音作品，就可能存在一定影响(动态被压缩)了。
土星实机PCM数字音频是44.1KHz/13bit，比特精度约为13bit(数据来源SSF_PreviewVer_R28/Document/index.html索引页)。
SSF_PreviewVer_R28 PCM数字音频是44.1KHz/15bit(数据来源SSF_PreviewVer_R28/Document/index.html索引页)，音频的比特深度即采样精度略高于实机，接近CD的16bit标准。
SSF实现土星DSP实时混响处理
SSF Test Version (18.01.03) (Sega Saturn Emulator for WIN)
SSFに関しては以下の修正が出来ればいいなぁ おそらくバグってるSCSP-DSP処理 バーニングレンジャーなどフェードアウト後にゴミが残る現象 VDP2のビットマップの表示不具合 BIOSのエミュレート
テストバージョンを更新しました … 内蔵音源で音程が狂うバグを修正してみました 怪しいソフトは一通り確認したつもりですが、まだ音程の狂っているソフトがあるかもしれません
从SSF TestVer自2018/01/03到更高版本的SSF PreviewVer R9有一个严重错误，SCSP-DSP处理存在bug导致程序不定时发生崩溃。
土星内置声源DSP（数字信号处理）在混响效果处理上使用了24位浮点运算，但在实机DSP环形缓冲区中写入的浮点数据是什么格式，世嘉是不公开的，长久以来，开发者不清楚DSP混响效果计算的浮点数据（用于声源相位旋转滚动的横坐标时间计算格式）。SSF只是采用单精度浮点运算，由于世嘉在土星DSP内部对声源相位中心坐标的定位还使用了定点计算，SSF在DSP环形缓冲区模拟上一直没有实现带有所需要使用的SCSP寄存器功能，内置声源的DSP混响效果不起作用，无法正确播放直接访问环形缓冲区的软件声音，遇到此类处理时会导致SSF程序不定时发生崩溃。开发者过去也认为没有软件可以完成如此棘手的事情，为纠正旧版中拖了很长时间的各种错误，进一步提升兼容性、速度和准确性，SSF TestVer被放弃修改，版本回退重新更名为SSF PreviewVer。
频繁更新至SSF PreviewVer R10开发者尝试修复SCSP-DSP处理中的bug，该版将单精度浮点运算改为和SS实机处理相同的固定点运算，从SSF PreviewVer R12 开始，声音改为使用波形音频播放，并且可以选择切换XAudio2 (动态库处理音频数据) 播放，XAudio2内置效果：混响、音量计量，提供灵活且强大的DSP框架，支持音频信号编程处理，信号是声音编程的基本单位，好比是图形中的像素。 处理信号的数字信号处理 (DSP) 效果好比是游戏音频的像素着色器，经数字优化补偿后提高了数字立体声的动态范围、包括力量感、临场感和清晰度这些，最大程度还原了SS原声源的层次与空间分布。
接着是完整模拟实机的DSP混响处理，需要解开世嘉在土星DSP环形缓冲区中写入的浮点数据格式，实现PCM脉冲编码调制线性反馈移位寄存功能，由流密码开/关组成声源定点坐标的交替转换，这是三维空间框体下声源重心坐标的定位机理。
开发者经过仔细推导，大致得出了DSP环形缓冲区中写入的浮点数据格式，将此浮点地址转换为定点地址，用于旋转滚动（代表电流采样的正半周）的坐标计算。直到SSF PreviewVer R17才终于实现对土星DSP混响算法的实时处理，提高了音频解码性能和质量，开发者认为现在的SSF声音听起来像一台真正的实机！这一改进提高了声源处理的边缘保真度(基于严密的精确算法)，相对于(实机)原始硬件。
---------------------------------------------------------------
多机种模拟器Mednafen
作为兼容多机种运行环境的软件平台，核心在设计开发框架时要满足的，往往是一个需求类别，优先考虑的是抽象出软件最合理的设计，使得程序具有良好的可读性和扩展性，通常一开始写出的逻辑就为了以后的重用，多机种模拟器包含的许多通用性开发框架就是一步步抽象/埋坑/优化而来的，而不是具体到某个实机其硬件环境指标的需求，所以一定会考虑代码的复用性、组件的复用性、同一个功能对不同场景的复用性。有了复用的能力，才能够用更少的开发去满足更多场景的同类需求问题。考虑到实现代码框架环境的通用性，复用性代码的堆砌比较多，为实现某个主机运行所需的兼容环境，比照实机硬件函数 (机制) 的取值精度一般比较低，直观表现在图像/声音效果的还原上。
之前曾提到土星对CPU周期的要求非常严格，改变任何关于解释器的东西都可能需要重写与时序有关的一切。因此在准确性和速度之间的权衡是一个困难的命题。对于老硬件系统，精度几乎总是更可取的，而现有PC硬件在软件中模拟主机硬件处理对于精度的仿真速度已经非常快了，并且通常包含更严格的时序限制。Mednafen这方面的调整较为平衡，时序限制没SSF那么严格，兼容状况目前稍好于SSF，只在图像、声音计算处理精细度上低于SSF。
近几年Mednafen对土星的完善模拟作了大量修正与优化，最新正式版在兼容性和执行效率上较过去的旧版更好。
另一个多机种模拟器BizHawk在模拟土星上使用了Mednafen内核(版本更新晚于官网)，在内存和CPU占用率上都比Mednafen原版更高。
BizHawk 2.6
Mednafen 1.26.1 x64
SSF PreviewVer一直采样Clang+LLVM编译，在注重准确性模拟器中的执行效率是最高的。最新版在Ryzen7 3700X上模拟大部分SS游戏，CPU使用率都在4%以下，主SH2，协SH2，68000，即使用满DSP，也不会超过6%，在4代I7-4771上CPU使用率也不超过10%。
---------------------------------------------------------------
SSF：
由于最近在最新版本中检测到病毒，不建议使用。
P.S.释疑一下，SSF号称是最精确的SS模拟器，自R27开始作者开发了一个无限循环程序样本，因无限循环要从CPU中提取资源换取浮点精度的缘故，而被一些杀软误标记为病毒。
Yaba Sanshiro 2：
它远不如SSF和Mednafen那么成熟，仍然存在许多兼容性问题，开发似乎已经停止...
Kronos：
大多数游戏在Windows上仍然存在问题... 此处提供了兼容性列表