对光驱板固件来说，是加延迟，阻塞数据I/O速度，来使这些强依赖读取速度的游戏正常。NullDC以前也有这个问题，也是类似改法。

而在不能改动光驱板固件的条件限制下，yzb做的，是修正游戏对的"读取完毕"标志位进行初始化的逻辑时机。因为本来就是游戏的开发者错误地假设了当前帧不可能读取完数据，就把"读取完毕"标志位的初始化逻辑，放到了发起"开始读取光盘数据的请求"这个逻辑之后。

即：
1. 发起"开始读取光盘数据的请求"。
2. 初始化"读取完毕"标志位，使其状态为"尚未完成"
3. 循环检测"读取完毕"标志位，直到其变为"已完成"，再跳到第4步，或者触发读取超时逻辑。
4. 后续逻辑。

这4个步骤的第1步，会因为光驱板读取速度过高而意外地在第2步还没开始前就把"读取完毕"标志位置成"已完成"状态(因为确实读完了)，然后第2步中，这个标志位又被抹除，变成了"尚未完成"状态，导致之后逻辑在第3步不能在特定时间内读取完毕，使得出现死循环，或者某些依赖光驱速度的随机数生成过程产生固定值。

yzb把第1、2步顺序换了，就可以规避这种初始化逻辑滞后导致的问题。

引用:

原帖由 yzb 于 2022-3-11 21:20 发表


我没把第1、2步顺序换了，只是把第3步加了判断，判断为触发bug的那几个物品，则强制延迟n帧以后，才让其变为"已完成"状态

这样啊。。。那不严谨通用，去重改吧。。。