Getting started with a Tile-based game in Qt using QGraphicsScene and QGraphicsView

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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