在浏览器中,最好使用一个巨大的Spritesheet还是使用许多(10000)个不同的PNG?


33

我正在jQuery中创建一个游戏,在其中使用了大约10000个32x32瓦片。到目前为止,我一直单独使用它们(没有精灵表)。一张普通的地图使用大约2000个图块(有时会重复使用PNG,但是所有单独的div),其性能范围从稳定(Chrome)到有点落后(Firefox)。每个div均使用CSS进行绝对定位。无需在每次更新时更新,只需加载新地图即可。

对于像CSS一样使用CSS背景定位的div使用spritesheet方法,性能会更好吗?

先感谢您!


3
哪里需要10000张地图瓷砖?我建议您不要在用户端上传/绘制所有地图。仅显示一部分,这是可见的。用户移动时,加载下一部分。每个3D图形的工作方式。
Deele

一张平均地图使用2000个不同的图块,或仅使用2000个图块?您正在创建多大的地图?
尼克·拉尔森

您是否考虑过使用一个或几个较大的图像作为背景并对边界执行多边形碰撞检测?
SAHornickel

Answers:


50

我的建议

太多的小PNG会增加很多网络开销(由于HTTP请求的大小以及PNG标头,甚至可能更重要的是,无法有效压缩)。另一方面,一个非常大的PNG的缺点是需要花费一些时间来加载,并且需要永久地保留在连续的内存块中的内存中(10,000瓦片为40兆字节)。

我推荐中间立场:几个合理大小的PNG,例如1024个32×32大小的图块。也许按主题分组(例如,一个带有森林瓷砖的PNG,一个带有山地瓷砖的PNG,另一个带有城市瓷砖的PNG-我不知道您游戏的主题,但您明白了。)

关于缓存效率的注意事项

由于内存访问效率高,因此永远不要使Spritesheets太宽。从128×8192图像中拖动图块将始终比从8192×128图像中拖动图块更快。

想象一下,您想使8192×128图像中的第一个图块变白。为了简单起见,假设1个像素为1个字节。像素的前两行以这种方式布置(单元在内存中包含其字节数):

┌────┬────┬───┬────┬──────────┬─────┐
  0   1 │...│ 31    ....    8191 1st line of pixels: bytes 0 to 8191
├────┼────┼───┼────┼──────────┼─────┤
81928193│...│8223   ....   16383 2nd line of pixels: bytes 8192 to 16383
├────┼────┼───┼────┼──────────┼─────┤
 ..  .. │...│ ..    ....    ... 

因此,为了隐藏一个标题的第一行,浏览器引擎将检索到的字节031。要取消第二行的内容,它将检索到的字节81928223,依此类推,直到检索253952253983要字节的第32行为止。

处理的字节总数将为32×32。但是,总的内存范围超过253984字节。在现代CPU上,这意味着32或33个缓存停顿。相反,如果图像为128×8192,则存储范围将仅为4000字节,这意味着不超过两个缓存停顿。

因为当今的CPU速度非常快,所以高速缓存停顿非常昂贵并且会挂起计算。因此,至少从理论上讲,使用128×8192图像代替8192×128图像的速度可能快8倍。在实践中,这将取决于如何实现blitting:底层引擎本身可能将图像拆分为图块以减少问题。

这很难正确地解释,而且我也没想过多阐述。我希望这是有道理的!


4
“还请注意,由于内存访问效率高,因此永远不要使Spritesheets太宽。从128×8192图像中划出图块总是比从8192×128图像中划出图块更快。” -很好奇,请您详细说明?:)
格里姆肖

@DevilWithin:我试图解释这个问题;让我知道我是否足够清楚!
sam hocevar

缓存效率的东西令人着迷。关于帧率的差异,您有任何数字吗?
格雷戈里·艾弗里·威尔

无论是问题,还是特定于实现的,但是如果像OpenGL这样的API以这种方式作用于纹理,则一定要考虑到这一点,谢谢:)
Grimshaw

2
@DevilWithin:我写的内容仅对CPU有效-大规模并行的GPU具有非常不同的缓存设置,并将使用其自身的内部格式存储纹理,并针对随机访问进行了优化。这就是为什么在OpenGL中建议使用正方形的2幂的纹理的原因,对于贴图集,我也将遵循该规则。
sam hocevar

5

一个巨大的Spritesheet(可能)将为您提供更好的性能,这仅仅是因为最大的滞后原因之一是浏览器请求到服务器到浏览器的往返。10,000个HTTP调用将花费很多,比1个HTTP返回的文件要长10,000个要长得多。

您还可以使用其他方法来减少延迟,具体取决于游戏的结构和所创建的HTML。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.