I want to Make a scene so people can navigate through but they cant walk through objects.
Related
I have a problem that I don't know how to face and I was looking for some help. I recently started using Qt and I do not really know how Qgraphicsitems works.
I have a scene and I have to create a group of graphics items everytime my program starts, but sometimes I have to update some of those items that are always together.
So I was thinking about creating one Qgraphicsitem with all of them in it. That way i can handle them easily. My problem is that I'm not sure if that is a good approach. In a modular point of view it make sense because that group of items are always toguether and that way I do not have to create all of them everytime, but I do not know how to do it in the first plane how can I create a QgraphicsItem that has some QgraphicsItems in it?
Sounds like you're looking for QGraphicsItemGroup:
The QGraphicsItemGroup class provides a container that treats a group of items as a single item.
https://doc.qt.io/qt-5/qgraphicsitemgroup.html
I have a QTabBar, and all tabs are supposed to have the same widget in them:
layout1->addWidget(w);
layout2->addWidget(w);
However calling addWidget the second time causes this widget to disappear in the first layout.
Is there any way to use one widget to insert it in several tabs?
Of course I can always create a new widget instance for every tab, but that takes extra time and memory.
Is there any way to use one widget to insert it in several tabs?
No. If you want the widget to be seen twice, then you need two instances of it.
Of course I can always create a new widget instance for every tab, but that takes extra time and memory.
Simple widgets are relatively cheap in regards to memory/time to create. Unless your GUI is becoming unresponsive and your profiler says that this is a problem, you are likely attempting a premature optimization.
Depending on the specific goal you're trying to accomplish, there are patterns such as using multiple views that share a single model that can potentially be employed.
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
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.
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.
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.
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
Im just pondering best practice with an application I'm developing. Its a simple one window application using qt creator. It's just going to start a QProcess and show the output in a QTextEdit box. To do this there needs to be a bit of processing between the output of the QProcess and the QTextEdit but i dont know where i should do this, should i create a new class to do that or add member functions and extra signals and slots to my main window? I dont want mainwindow to become bloated and hard to read but equally i dont want to have more source files than really I need.
Any thoughts?
The main window class can very easily get bloated with all kinds of functionality. I've dealt with that myself, so it's a very real trouble.
Really, though, this is not so much of QT question as it is an object-oriented design question. The key is that your output window does not need to be a part of QMainWindow, so it probably shouldn't be. Make the display a widget, and insert it onto the main window. That is much more flexible, as if you ever need to move that output pane for any reason, it won't be coupled to a specific part of the program.
The logic that feeds data into that output pane should also get its own class, separating the responsibility for displaying the output from the responsibility for acquiring the output.
For reference on the concepts behind my suggestion, see the Single Responsibility Principle and the separation of concerns.
Also - you may wish to have a read at this link to model view delegate information which is how I tend to develop in Qt. Like the person above says - this is more a question of good OO design.
I'm trying to share create four QGLWidgets with the same GL3 context so I can share a VBO between them. I've been doing this for a while with just one widget, but it wasn't shared with the others. QGLWidget has a sharewith paremeter, which from what I understand automatically shares the contexts between them, but I'm not sure how compatible that is with JOGL.
I'm also confused about when the context is actually created. In some examples it says to create the context in initializeGL. I'm not sure if that means I have to update the first widget before I can create the secondary widgets (passing the sharewith paremeter the first created widget with a current context).
Can anyone provide me with a simple example to get this functioning? I just need to create four context-sharing GLWidgets that all run off a GL3 profile.
Although I'm not using JOGL, I am doing a similar thing here and here. The basic idea is that you create a hidden QGLWidget, make it current and compile all your shaders, then pass it as the shareWidget to your child viewports. Whenever you want to upload geometry
make the hidden QGLWidget current and do your glBufferData calls - the data becomes available to the other viewport contexts.