问题描述
我有一个 32 帧的钻石爆炸成碎片的灰度动画(即 32 张 PNG 图像 @ 1024x1024)
I have a 32 frame greyscale animation of a diamond exploding into pieces (ie 32 PNG images @ 1024x1024)
我的游戏包含 12 种不同的颜色，所以我需要以任何所需的颜色来执行动画
my game consists of 12 separate colours, so I need to perform the animation in any desired colour
我认为这排除了任何 Apple 框架，也排除了许多用于在 iOS 中逐帧制作动画的公共代码.
this I believe rules out any Apple frameworks, also it rules out a lot of public code for animating frame by frame in iOS.
我的潜在解决方案是什么?
what are my potential solution paths?
这些是我找到的最好的 SO 链接:
these are the best SO links I have found:
最后一个只是表明可以将图像加载到每帧的 GL 纹理中(他是从相机中进行的，所以如果我将所有内容都存储在内存中，那应该会更快)
that last one just shows it is may be possible to load an image into a GL texture each frame ( he is doing it from the camera, so if I have everything stored in memory, that should be even faster )
我可以看到这些选项(首先列出最懒惰，最后列出最优化)
I can see these options ( listed laziest first, most optimised last )
选项 A每一帧(由 CADisplayLink 提供)，将文件中的相关图像加载到纹理中，并显示该纹理
option A each frame (courtesy of CADisplayLink), load the relevant image from file into a texture, and display that texture
我很确定这很愚蠢，所以选择 B
I'm pretty sure this is stupid, so onto option B
选项 B将所有图像预加载到内存中然后按照上面的方法，只有我们从内存而不是从文件中加载
option B preload all images into memory then as per above, only we load from memory rather than from file
我认为这将是理想的解决方案，任何人都可以给它竖起大拇指或大拇指向下吗?
I think this is going to be the ideal solution, can anyone give it the thumbs up or thumbs down?
选项 C将我所有的 PNG 预加载到最大尺寸的单个 GL 纹理中，创建纹理图集.每一帧，将纹理坐标设置为该帧在 Atlas 中的矩形.
option C preload all of my PNGs into a single GL texture of the maximum size, creating a texture Atlas. each frame, set the texture coordinates to the rectangle in the Atlas for that frame.
虽然这可能是编码效率和性能效率之间的完美平衡，但这里的主要问题是分辨率丢失；在较旧的 iOS 设备上，最大纹理大小为 1024x1024.如果我们在其中塞入 32 帧(实际上这与塞入 64 帧相同)，我们将在每帧中设置为 128x128.如果生成的动画在 iPad 上接近全屏，这不会破解它
while this is potentially a perfect balance between coding efficiency and performance efficiency, the main problem here is losing resolution; on older iOS devices maximum texture size is 1024x1024. if we are cramming 32 frames into this ( really this is the same as cramming 64 ) we would be at 128x128 for each frame. if the resulting animation is close to full screen on the iPad this isn't going to hack it
选项 D而不是加载到单个 GL 纹理中，而是加载到一堆纹理中此外，我们可以使用所有四个通道将 4 个图像压缩到一个纹理中
option D instead of loading into a single GL texture, load into a bunch of textures moreover, we can squeeze 4 images into a single texture using all four channels
我对这里需要大量繁琐的编码感到厌烦.考虑到这种方法，我的 RSI 开始感到刺痛
I baulk at the sheer amount of fiddly coding required here. My RSI starts to tingle even thinking about this approach
我想我已经在这里回答了我自己的问题，但是如果有人真正做到了这一点或者可以看到解决办法，请回答！
I think I have answered my own question here, but if anyone has actually done this or can see the way through, please answer!
推荐答案
如果需要比(B)更高的性能，看起来关键是glTexSubImage2D http://www.opengl.org/sdk/docs/man/xhtml/glTexSubImage2D.xml
If something higher performance than (B) is needed, it looks like the key is glTexSubImage2D http://www.opengl.org/sdk/docs/man/xhtml/glTexSubImage2D.xml
我们可以在内存中连续排列 16 个 512x512x8 位灰度帧，而不是一次从内存中拉出一帧，将其作为单个 1024x1024x32 位 RGBA 纹理发送到 GL，然后使用上述方法将其拆分到 GL 中功能.
Rather than pull across one frame at a time from memory, we could arrange say 16 512x512x8-bit greyscale frames contiguously in memory, send this across to GL as a single 1024x1024x32bit RGBA texture, and then split it within GL using the above function.
这意味着我们每 16 帧而不是每帧执行一次 [RAM->VRAM] 传输.
This would mean that we are performing one [RAM->VRAM] transfer per 16 frames rather than per one frame.
当然，对于更现代的设备，我们可以获得 64 个而不是 16 个，因为更新的 iOS 设备可以处理 2048x2048 纹理.
Of course, for more modern devices we could get 64 instead of 16, since more recent iOS devices can handle 2048x2048 textures.
我将首先尝试技术(B)，如果它有效(我不想过度编码)，我会先尝试一下，如果需要，看看这个.
I will first try technique (B) and leave it at that if it works ( I don't want to over code ), and look at this if needed.
我仍然找不到任何方法来查询图形芯片上可以保存多少个 GL 纹理.有人告诉我，当您尝试为纹理分配内存时，GL 只会在内存不足时返回 0.但是，要正确实现这一点，我想确保我不会在风中航行 re: 资源...我不希望我的动画使用太多 VRAM 以至于我的其余渲染失败...
I still can't find any way to query how many GL textures it is possible to hold on the graphics chip. I have been told that when you try to allocate memory for a texture, GL just returns 0 when it has run out of memory. however to implement this properly I would want to make sure that I am not sailing close to the wind re: resources... I don't want my animation to use up so much VRAM that the rest of my rendering fails...
这篇关于iOS:以自定义颜色播放逐帧灰度动画的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！