graphics - 模拟老式 Sprite 的闪烁(理论和概念)

Question

我正在尝试开发一种老式的NES风格的视频游戏，它具有精灵闪烁和图形慢的特点。我一直在思考应该使用哪种类型的逻辑来实现这种效果。

如果我想使用老式的NES风格，则必须考虑以下限制:

一次在屏幕上显示的精灵不超过64个

每条扫描线或Y轴上的每行最多8个精灵

如果屏幕上有太多 Action ，系统会冻结图像一帧，以使处理器赶上

Action

根据我的阅读，如果屏幕上有64个以上的精灵，开发人员将只绘制高优先级的精灵，而忽略低优先级的精灵。他们还可以交替使用，在奇数编号的相对帧上绘制每个偶数编号的精灵。

扫描线问题很有趣。根据我的测试，像NES一样，逐像素绘制精灵无法在XBOX 360 XNA框架上获得良好的速度。这就是为什么在老式游戏中，如果一行上的精灵太多，如果将它们切成两半，就会出现一些精灵。出于该项目的所有目的，我将扫描线设置为8像素高，并根据其Y位置将每个子图线归在一起。

为了澄清，我将以8x8像素(而不是1x1)的批数将精灵绘制到屏幕上。

因此，愚蠢的我需要提出一个解决方案....

一次在屏幕上显示64个精灵

每个“扫描线”为8个精灵

可以根据优先级

绘制精灵

可以在每帧精灵之间交替

模拟减速

这是我目前的理论

首先，我想到的一个基本想法是解决精灵优先问题。假设值介于0到255之间(0为低)，我可以分配子画面优先级，例如:

0至63为低

63至127为中等

128至191为高

192至255为最大

在数据文件中，我可以将每个精灵指定为特定优先级。创建父对象时，将为子画面随机分配一个介于其指定范围之间的数字。然后，我将按从高到低的顺序绘制精灵，最终目标是绘制每个精灵。

现在，当在画面中绘制精灵时，我将在其初始优先级内随机生成一个新的优先级值。但是，如果没有在画面中绘制精灵，则可以在当前优先级上添加32。例如，如果系统只能将精灵绘制到优先级135，则可以在未绘制3帧之后绘制初始优先级为45的精灵(45 + 32 + 32 + 32 = 141)

从理论上讲，这将允许子画面交替显示帧，允许优先级并将子画面限制为每个屏幕64个。

现在，有趣的问题是我如何将子图形限制为每条扫描线仅8个？

我在想，如果我将精灵排列为高优先级到低优先级，请遍历循环直到找到绘制的64个精灵。但是，我不应该只是列表中的前64个精灵。

在绘制每个精灵之前，我可以检查一下是否通过计数器变量在其相应的扫描线中绘制了多少精灵。例如:

0到7之间的Y值属于Scanline 0，scanlineCount [0] = 0

介于8到15之间的Y值属于Scanline 1，scanlineCount [1] = 0

等

我可以为绘制的每一帧重置每条扫描线的值。在子画面列表中向下移动时，如果在该扫描线中绘制了一个子画面，则在扫描线的相应计数器上加1。如果等于8，请不要绘制该精灵，而转到下一个优先级最低的精灵。

慢一点

我需要做的最后一件事是模拟速度下降。我最初的想法是，如果我每帧绘制64个精灵，而仍然需要绘制更多的精灵，则可以将渲染暂停16毫秒左右。但是，在我玩过的NES游戏中，如果没有任何子画面闪烁，有时会变慢，即使有一些子画面闪烁，游戏的运行也会很漂亮。

也许给在屏幕上使用精灵的每个对象赋予一个值(如上面的优先级值)，并且如果所有带有精灵的对象的组合值超过阈值，会导致速度变慢？

结论...

我写的所有内容听起来确实合法并且可以使用，还是做梦了？你们都可以通过我的这种游戏编程理论想到什么改进？

Answer 1

首先，我喜欢这个主意。在制作复古游戏时，如果您忽略了复杂性限制，那就不会一样了。通过编写可以强制执行的框架，是一个好主意。

我可以说，如果您将该引擎抽象为一个开源的“复古游戏”图形引擎，那确实很酷，我一定会加入其中!

对于最高优先级的精灵，也许Priority Queue可以简化这一部分，因为您可以拔出64个最高优先级的精灵。

放慢速度，也许在引擎中您可以使用limitValue。每个精灵作为适当的limitUse。将所有limitUse变量加起来，如果它低于limitValue，请放慢速度。现在，对于slowDelay = f(limitUseTotal - limitValue)，其中f是将多余数量的sprite转换为计算的减慢值的函数。这是您所建议的一般想法，还是我误读了？