OpenGL (ES)——由 CPU 或 GPU 计算的缩放，它是否“昂贵”？操作（相对而言）？
我问的原因是我已经为使用正交投影的 2d 自顶向下游戏编写了渲染方案。为了给出深度的外观，我缩放了对象。我想知道切换到平截头体并使用 z 坐标代替缩放是否会提高性能。我只是实施它并找出答案，但这需要我几个小时，而且在这里问更容易。
The reason I ask is that I've written a rendering scheme for a 2d top down game that uses ortho projection. To give the appearance of depth I scale the objects. I'm wondering if switching to frustum and using the z-coor in lieu of scaling will improve performance. I would just implement it and find out, but it would take me several hours, and its easier to just ask here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
glScale只是简单地修改堆栈顶部的矩阵，所有这些都在 CPU 中完成。至于“相对而言”昂贵，我想我会问 - 相对于什么？ :) 如果你偶尔这样做的话，并不是那么贵。如果您在关键的内部循环中执行此操作，那么，是的，它可能会很昂贵。glScalejust simply modifies the matrix on top of the stack, all done in CPU. As for expensive "relatively speaking", I guess I ask - relative to what? :) It's not that expensive if you are doing it occasionally. If you are doing it in a critical inner loop, then, yeah, it could be expensive.几乎可以肯定，切换到 3D 视图并使用
glFrustum会更快。这就是硬件的真正用途，而且它做得很好，至少在大多数情况下是这样。Almost certainly faster to switch to a 3D view and use
glFrustum. It's what the hardware is really built for, and it does it quite well, at least in most cases.据我所知，glScale http://www.opengl。 org/sdk/docs/man/xhtml/glScale.xml，是一个标准的OpenGL函数，它修改矩阵，但没有指定是在CPU上还是GPU上完成。我的猜测是，这会因实现而异，但它可以在 GPU 上完成；或 CPU，就像任何其他 OpenGL 函数一样。
As far as I'm aware, glScale http://www.opengl.org/sdk/docs/man/xhtml/glScale.xml, is a standard OpenGL function, which modifies the matrix, but it does not specify if it is done on the CPU or the GPU. My guess is this would vary by implementation, but it could be done on the GPU; or the CPU, like any other OpenGL function.
使用正交投影的 2D 不会根据 z 深度变化进行缩放。如果您想知道相对于更改 z 深度的成本，它应该是相同的成本 - 只是矩阵变换，但可能看起来不同，并且可能会干扰裁剪平面。然而，进行函数调用总是比不进行函数调用更昂贵，因此，如果您可以同时跟踪和使用深度，那么它应该会便宜一些，但需要注意前面列出的注意事项。希望这不是太多的词汤。
2D using an ortho projection won't scale on z-depth change. If you're wondering cost relative to changing the z-depth it should be an identical cost - just a matrix transform, but might look different, and might interfere with clipping planes. Making a function call is always more expensive than not making a function call, however, so if you can track and use depth at the same time, it should be micro-cheaper, with previously listed caveats. Hope that's not too much word soup.