使用 QGraphicsScene 和 QGraphicsView 在 Qt 中开始基于 Tile 的游戏

发布于 2025-01-01 11:40:03 字数 530 浏览 1 评论 0原文

我将开始在 Qt 中编写基于 2D 图块的游戏,并阅读有关 QGraphicsScene 和 QGraphicsView 类的信息,这些类旨在显示和处理大量 2D 对象。

我的问题是,使用 QGraphicsScene 创建一个包含大量图块的世界是否可行?我可以一次性添加整个世界吗?或者我应该尝试实施一些措施来稍微限制该区域?我读到 QGraphicsScene 可以处理“数千个项目”,但是 2D 图块地图可以轻松变得非常非常大(200x200 个图块?不是那么多,但这已经是 40,000 个对象了,这已经很多了)。

该地图也将是几乎静态的,因此可以将其绘制为一个大像素图,但这确实阻止您使用 QGraphicsScene 中的所有奇特的东西,例如处理独立项目上的鼠标点击等。除此之外,我'我将绘制不会与图块网格对齐的玩家、NPC 等。是否有一些优化的东西可以使用大量静态对象和它们之上的一些动态对象?

使用 QGraphicsScene 和 QGraphicsView 是一个好主意吗?或者我应该尝试在 Qt 中寻找替代方案,或者可能是一个不同的、更面向游戏的库?

提前致谢

I'm going to start programming a 2D tile-based game in Qt and read about the QGraphicsScene and QGraphicsView classes which are intended for displaying and handling lots of 2D objects.

My question is that will it be feasible to create a world with lots of tiles using QGraphicsScene? Can I add the whole world at once tile-by-tile or should I try to implement something to restrict the area a bit? I've read that QGraphicsScene can handle "thousands of items" but a 2D tile map can easily get really, really big (200x200 tiles? not that many, but that's already 40,000 objects which is a lot).

The map is also going to be pretty much static so it might be possible to draw it as one big pixmap but this really prevents you from using all the fancy stuff in QGraphicsScene like handling mouse clicks on independent items etc. On top of that I'm going to draw the player, the NPCs and so forth which will not be aligned to the tile grid. Are there some optimization stuff for using lots of static objects and some dynamic ones on top of them?

Is using QGraphicsScene and QGraphicsView even a good idea at all or should I try to look for an alternative inside Qt or maybe a different, more game-oriented library?

Thanks in advance

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

倒数 2025-01-08 11:40:03

您应该使用 QGraphicsView。

Qt 文档中的 40,000 Chips 是您最好的选择仔细检查的例子。它处理大量元素的复杂性,以多种比例绘制它们等等。

玩一下这个例子,你会发现,如果你缩小,你可以在任何视图中选择和拖放多个芯片,或者你可以放大到足以看到照片上的一些文本,那么所有的芯片实际上组成了一张大照片。单独的芯片。理解每个部分需要时间,但这是一个非常值得研究的透彻示例。

chips.cpp 源中,它展示了如何通过使用基于样式选项中存储的转换的“LevelOfDetail”或 lod 变量 switch 语句来快速运行。

Qt Graphics View 已经过优化,可以完成您在问题中讨论的许多事情,但需要一段时间才能理解如何处理它。

如果您仍然对要使用的地图的大小有疑问,我会将图块布局存储在硬盘上,并在需要时加载您需要的图块布局,并将不需要的图块布局从场景中删除,如下所示必要的。

You should use QGraphicsView.

The 40,000 Chips int the Qt Documentation is your best example to closely examine. It deals with the complexity of large numbers of elements, drawing them at multiple scales and a lot more.

Play with the example and you will see that all the chips actually make up a large photo if you zoom out and that you can select, and drag and drop multiple chips at any view, or you can zoom in enough to see some text on an individual chip. It will take time to understand each part, but this is a very thorough example to look into.

In the chips.cpp source, it shows how it can still run quickly by using a "LevelOfDetail" or lod variable switch statement based off of the transformation stored in a style option.

Qt Graphics View has been optimized to do a lot of the things you have talked about in your question, but it takes a while to understand how to approach it.

If you are still having issues with the size of the map you want to use, I would store tile layouts on the harddrive and load the ones you need when you need them, and remove the ones you don't need off of the scene as necessary.

残花月 2025-01-08 11:40:03

QGraphicsScene 能够仅绘制视图中所表示的内容,其他所有内容都位于场景索引中。您可以使用不同的选项来配置场景和视图的操作方式,以优化您的特定使用。仅仅因为场景索引中有 40k 个图块,并不意味着您需要绘制那么多图块。您实际上只有视图分辨率中显示的数量。

此外,如果您的项目是静态的,则还有缓存选项,那么它们只需计算一次,并且可以从像素图缓存中检索。

最终我认为它完全值得你花时间去尝试。对于您来说,模拟一个测试应该相当容易,您可以在场景中填充大量图块,然后只需尝试滚动视图即可。我觉得这并不关心你有多少个图块,而是关心正在绘制的实际视图中的图形有多复杂。

QGraphicsScene has the ability to only paint what is being represented in the view, everything else just sits in the the scene index. You have different options for configuring how the scene and view operate to optimize your specific use. Just because you have 40k tiles in your scene index, doesn't mean you need to paint that many. You really only have as many as are being displayed in the resolution of your view.

Also, there are caching options if your items are static, then they only have to be calculated once and can be retrieved from a pixmap cache.

Ultimately I think its completely worth your time to try it out. It should be fairly easy for you to mock up a test where you populate your scene with a very large number of tiles and simply try scrolling around the view. I feel its not so much a concern with how many tiles you have, but rather how complex the graphics are within the actual view being painted.

南烟 2025-01-08 11:40:03

我正在开发一个类似的项目,并且使用 30x30 的持久 QGraphicsPixmapItems 网格。当地图视图发生变化时,QGraphicsscene 会迭代当前视图中的地图数组部分,在每个图块上调用 setPixmap 将其更改为新的图块类型。它运行得非常顺利,到目前为止我没有任何性能投诉。

I'm working on a similar project and I'm using a 30x30 grid of persistent QGraphicsPixmapItems. When the view of the map changes, the QGraphicsscene iterates over the part of the map array that's currently in view, calling setPixmap on each tile to change it over to the new tile type. It's been working pretty smoothly and I don't have any performance complaints thus far.

相对绾红妆 2025-01-08 11:40:03

我同意所说的。我多年来一直在制作基于 QGraphicsView 的游戏(如果您使用的是 Linux,请询问您的软件包如果您愿意的话,可以使用 KDiamond 或 Palapeli 的管理器),虽然几年前 QGraphicsView 首次出现时渲染性能一直是一个问题,但这些问题现在已经普遍得到解决。

您应该关心的是内存消耗。芯片示例可以具有与您想要的图块一样多的芯片,但这些芯片不会像像素图一样保存在内存中。如果每个图块都是固定大小的 50x50px 图像,则已经

32bits*50px*50px*200*200 = 381,9 MiB

I agree with what has been said. I've been doing QGraphicsView-based games for years (if you're on Linux, ask your package manager for KDiamond or Palapeli if you like), and while rendering performance has been an issue when QGraphicsView first came out years ago, these problems are now generally solved.

What you should be concerned about is memory consumption. The chips example may have as many chips as you want to have tiles, but those chips are not kept in memory as pixmaps. If each tile is a fixed-size 50x50px image, that's already

32bits*50px*50px*200*200 = 381,9 MiB
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文