高效绘制 2D 精灵(位图)图块
我正在编写一个基于 2d 图块的引擎。目前,我的绘图例程使用 C# 绘图库在每次屏幕刷新时重新绘制每个可见图块。我可以滚动和缩放来工作,一切看起来都是我想要的。但日常工作进展缓慢。现在我正在努力改进它。我有几个问题:
首先,我认为每次刷新时重新绘制图块是不必要的(因为它们永远不会改变)。现在我正在尝试更改算法,以便在初始化时将整个地图写入单个位图,然后在绘制时剪切位图的正确部分。您认为这是正确的方法吗? (我还考虑过将图像保留在背景中,然后滚动它。但后来我决定不想绘制视野之外的东西。但是,也许这比剪切/粘贴便宜?内存与时间问题?)
其次,据我了解,C# 绘图例程并未充分利用 GPU 的能力。我想我应该尝试在 OpenGL(或 DirectX,但我更喜欢前者,因为它是多平台的)中进行绘图。这会有帮助吗?您知道 OpenGL 的平铺(或一般像素绘制)教程吗?书籍参考也可能有帮助。
我现在也不做多线程(事实上我对那是什么只有一个模糊的概念)。我应该尝试对抽屉进行多线程处理吗?或者 OpenGL 会让图形的多线程变得多余吗?
谢谢。
I'm writing a 2d tile-based engine. Currently, my drawing routine uses the C# Drawing library to redraw every visible tile every time the screen refreshes. I got scrolling and zooming to work, and everything looks the way I want it to. But the routine is slow. Now I'm trying to improve it. I've a couple of questions:
First, I think redrawing the tiles at every refresh is unnecessary (since they never change). Right now I'm trying to change the algorithm so that it writes the whole map to a single bitmap at initialization, and then cuts the correct portion of the bitmap when it's time to draw. Do you think this is the right way to go?
(I also considered leaving the image in the background and just scrolling over it. But then I decided that I don't want to draw stuff that's outside of the field-of-view. However, perhaps that is cheaper than cutting/pasting? A memory vs time issue?)
Second, as far as I understand the C# Drawing routines do not use the full power of the GPU. I think I should try to do the drawing in OpenGL (or DirectX, but I prefer the former, since it is multiplatform). Will that help? Do you know any tiling (or general pixel-drawing) tutorial for OpenGL? A book reference could also help.
I also don't do multi-threading at the moment (in fact I only have a vague idea of what that is). Should I try to multi-thread the drawer? Or would OpenGL make multi-threading for graphics redundant?
Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您打算使用什么应用程序框架? WinForms (Win32) 和 WPF 之间的高效绘图技术有很大不同。
您是对的,.NET 绘图例程没有充分利用 GPU。使用 DirectX 或 OpenGL,一种直接的优化是使用图像列表或显示列表将所有图像图块(或者至少是即时视图区域所需的所有图块加上更多)预加载到 GPU 内存中。然后,您可以按索引在表面上绘制图块 - 在 x,y 处绘制图块 N。这通常比使用主系统内存中存储的位图在 GPU 表面上绘制要快得多,因为对于绘制的每个图块,都必须将位图像素复制到 GPU,这会占用大量时间。当您可以在输出中的多个位置使用相同的图像图块时,按索引绘制也会使用更少的 GPU 内存。
OpenGL 与 DirectX 是您的选择,但 IMO DirectX 的发展速度更快,提供比 OpenGL 更多的硬件加速功能。 Windows 上的 OpenGL 驱动程序也因被硬件供应商忽视而闻名。他们的主要关注点是 DirectX 驱动程序。
考虑一下您的 2D 图块应用程序是否真的需要 OpenGL 还是 DirectX。需要 OpenGL 或 DirectX 将减少可以运行您的应用程序的机器数量,尤其是较旧的机器。 OpenGL 和 DirectX 可能有点过分了。如果您足够聪明,您可以使用普通的老式 GDI 做很多事情。
远离多线程,直到您有充分的理由去那里并且您有一些线程方面的经验。多线程为某些计算情况提供了某些性能提升,但也带来了新的麻烦和新的性能问题。在您报名参加所有这些新的令人头痛的问题之前,请确保其好处是显着的。
一般来说,在屏幕上移动像素通常不太适合多线程。您只有一个显示设备(在大多数情况下),因此使用多个线程尝试同时更改像素效果不佳。借用项目管理中的一句话:如果一个女人可以在9个月内生出一个孩子,那么你能用9个女人在1个月内生出1个孩子吗? ;>
努力识别系统中不需要访问相同资源或设备的部分。与将图块传输到屏幕相比,这些是在并行线程中运行的更好候选者。
最好的优化是发现不需要完成的工作 - 例如,减少重新绘制图块的次数,或者更改为索引模型,以便可以从 GPU 内存而不是系统内存绘制图块。
What application framework are you planning to use? Techniques for efficient drawing are very different between WinForms (Win32) and WPF.
You are correct that .NET drawing routines do not take full advantage of the GPU. Using DirectX or OpenGL, one immediate optimization would be to preload all of your image tiles (or at least, all of the tiles you need for the immediate view area plus a little more) into GPU memory using image lists or display lists. You would then draw the tiles on a surface by index - draw tile N at x,y. This is usually much faster than drawing on a GPU surface using bitmaps stored in main system memory, since the bitmap pixels have to be copied to the GPU for each tile drawn and that uses up a lot of time. Drawing by index also uses a lot less GPU memory whenever you can use the same image tile in multiple places in the output.
OpenGL vs DirectX is your choice, but IMO DirectX has been evolving at a faster rate providing more hardware accelerated functions than OpenGL. OpenGL drivers on Windows also have a reputation for being neglected by hardware vendors. Their primary focus is on their DirectX drivers.
Give some thought to whether you really need OpenGL or DirectX for your 2D tile application. Requiring OpenGL or DirectX will reduce the number of machines, particularly older machines, that can run your app. OpenGL and DirectX may be overkill. You can do a lot with plain old GDI if you're smart about it.
Stay away from multithreading until you have a really good reason to go there and you have some experience with threading. Multithreading offers the reward of some performance boosts for some computing situations, but also brings with it new headaches and new performance problems. Make sure the benefit is significant before you sign up for all these new headaches.
In general, moving pixels around on the screen is usually not a good match for multithreading. You've got only one display device (in most cases) so hitting it with multiple threads trying to change pixels at the same time doesn't work well. To borrow an expression from project management: If a woman can create a baby in 9 months, can you use 9 women to create 1 baby in 1 month? ;>
Work on identifying parts of your system that do not need to access the same resources or devices. Those are better candidates for running in parallel threads than blitting tiles to the screen.
The best optimization is to discover work that does not need to be done - reducing the number of times tiles are redrawn for example, or changing to an indexed model so the tiles can be drawn from GPU memory instead of system memory.
如果你想使用 OpenGL,那么 2d 的最佳选择是 SDL 。
将 OpenGL 与 C# 一起使用永远不会那么可移植,因为它会使用 .NET 包装器。
XNA 是一个用 C# 编写游戏的好工具,它应该提供更快的速度和比 SDL 更灵活(尤其是 .net 端口)以及更多功能(但体积更大)。
对于您的剪切或滚动问题,最好的路线是滚动。
当您使用 GDI+(System.Drawing 使用的)进行绘图时,内存的问题远比 CPU 的问题要小得多。您始终可以将地图分成几个部分并滚动这些部分,然后在必要时加载(如果地图那么大)。
If you want to use OpenGL your best bet for 2d would be SDL.
Using OpenGL with C# will never be that portable simply due to the fact it would use .NET wrappers.
XNA is a great tool for writing games in C#, it should provide a lot more speed and flexibility then SDL does (especially the .net port) plus more features (however more bulk).
For your cutting or scrolling question, the best route would be scrolling.
Memory is much less of an issue than CPU when you're drawing using GDI+ (what System.Drawing uses). You could always split the map up into sections and scroll those then load when necessary if it's that big.
我不熟悉 OpenGL,但我在 ManagedDX 中编写了一个基于图块的引擎(后来移植到 XNA)。 ManagedDX 已弃用,但 SlimDX 项目仍在积极开发中。
使用 DX,您可以将每个单独的图块加载到
纹理
中。 (例如使用Texture.FromFile()
或Texture.FromStream()
),并使用单个Sprite
实例绘制它们。这表现得相当不错。我将纹理分组在一个简单的类中,并使用 Point 或 Vector2 作为其位置,仅在位置更改时设置它们,而不是每次调用绘制方法时设置它们。我仅在内存中缓存当前屏幕和一两个图块之外的图块,不需要更多,因为文件 IO 足够快,可以在滚动时获取新图块。I'm not familiar with OpenGL, but I've written a tile based engine in ManagedDX (later ported to XNA). ManagedDX is depricated, but there's the SlimDX project which is still under active development.
With DX, you can load each individual tile into a
Texture
. (UsingTexture.FromFile()
orTexture.FromStream()
for example), and have a singleSprite
instance draw them. This performs pretty well. I group the textures in a simple class with a Point or Vector2 for their locations, set them only when the location changes rather than every time the draw method is called. I cache tiles in memory only for the immediate screen and one or two tiles beyond, there's no need for more than that as the file IO is quick enough to fetch new tiles as it's scrolled.