I am doing this in my paintEvent
painter.drawPie(rect, angle*16, 45*16);
But before drawing the pie I want to know whether the current mouse position lies under the pie region or not.
Mouse tracking is on. And I can get the mouseEvents. No problem from that side. But what is the math involved to know wheather the point lies inside the pie or not?
It's unfortunate that QPainterPath doesn't have an addPie() function. You can, however, use Qt's implementation of QPainter::drawPie() as a reference:
http://qt.gitorious.org/qt/qt/blobs/4.7/src/gui/painting/qpainter.cpp#line4439
You can essentially create the QPainterPath the same way they do it and call contains() on it.
I have not tried this, but you could try to intersect two QPainterPaths (one triangle and one circle) to get a QPainterPath for your pie-segment and then call QPainterPath::contains(QPointF&) with the mouse position as parameter.
Now that I write this, the check is probably easy to implement: if the point is inside the circle and inside the triangle, then it's inside the pie. Both subtests are easy to implement.
Related
I've been looking for a robust method of pathfinding for a platformer based game I'm developing and A* looks like it's the best method available. I noticed there is a demo for the AStar implementation in Godot. However, it is written for a grid/tile based game and I'm having trouble adapting that to a platformer where the Y axis is limited by gravity.
I found a really good answer that describes how A* can be applied to platformers in Unity. My question is... Is it possible to use AStar in Godot to achieve the same thing described in the above answer? Is it possible this could be done better without using the built in AStar framework? What is a really simple example of how it would work (with or without AStar) in GDscript?
Though I have already posted a 100 point bounty (and it has expired), I would still be willing to post another 100 point bounty and award it, pending an answer to this question.
you could repurpose the Navigation2D node for platformer purposes. The picture below shows an example usage. The Navigation2D node makes it possible to navigate the shortest path between two point that lie within the combined navigation polygon (this is the union of all NavigationPolygonInstances).
You can use the get_simple_path method to get a vector2 array that describes the points your agent/character should try to reach (or get close to, by using some predefined margin) in sequence. Place each point in a queue, and move the character towards the different points by moving it horizontally. Whenever your agent's next point in the queue is too high up to reach, then you can make the agent jump.
I hope this makes sense!
The grey/dark-blue rectangles are platforms with collision whereas the green shapes are NavigationPolygonInstance nodes
This approach is by no means perfect. If you were to implement slopes into your game then the agent may jump up the slope instead of ascending it normally. It is also pretty tedious to create all the shapes needed.
A more robust solution would be to have a custom graph system that you could place in the scene and position its vertices. This opens up the possibility to make one-way paths and have certain edges/connections between vertices marked as "jumpable" only. This is a lot more work though if you can not find any such solution online.
https://www.dropbox.com/s/phven3rriv36893/graphicsview-pathitem.png?dl=0
I wonder if there's a way to make my QGraphicsPathItem respond to mouseHoverEvents to the actual curve instead of the whole orange area as seen in the docs.
https://www.dropbox.com/s/7m8w34nitp34sgf/pipes.png?dl=0
In my application I'm not seeing the area that actually forms the path and therefor I only want a hoverEnterEvent when the bezier curve is hovered (and a hoverLeaveEvent when the bezier is left of, course).
Is that possible to achieve with QGraphicsPathItem or is that a completely wrong approach? If yes, how? If not, what QGraphics object can be considered as a replacement?
If code is really needed, let me know.
Cheers,
Michael
Tim Wakeham's answer is totally correct: you need to re-implement shape() to provide a more detailed shape for your path item. However, his answer is not totally useful, since it's not trivial to implement a good shape() method returning the right QPainterPath.
It's even more confusing because in this case, the QGraphicsPathItem can already provide a QPainterPath from its path() method. Unfortunately that is generally not the right value to return from the shape() method since it draws the item rather than delimits its outside.
Fortunately, since this is a fairly standard requirement, there is a built-in class to transform the path into an outline that can be used for the shape: QPainterPathStroker.
Here's some code I use to do that:
qp = QtGui.QPainterPathStroker()
qp.setWidth(MARGIN)
qp.setCapStyle(QtCore.Qt.SquareCap)
shape = qp.createStroke(self.path())
You need to reimplement QGraphicsItem.shape to return a more accurate representation of your curve. The default implementation gives you the bounding box as you've discovered.
I have to display a tiled map to display the result of a simulation
One can zoom/unzoom on the map, so if the zoom is far, there will be much more tiles displayed.
I am using QGraphicsPixmapItem to add the tiles to a QGraphicsScene.
I wonder whether openGl would be able to speed things up
I am using QGraphicsPixmapItem to add the tiles to a QGraphicsScene.
QGraphicsScene already uses methods like spatial subdivision (Kd trees) to determine which parts of a scene are visible and which not. In addition QGraphicsScene can use OpenGL as a rendering backend.
I strongly suggest you stick with QGraphicsScene, you'll hardly get more efficient than this, especially considering your next question:
I wonder whether openGl would be able to speed things up
Not if used naively. OpenGL is not a scene graph. I can't cull away and not issue drawing commands for geometry not visible. If you send it drawing commands it will process them. Unlike QGraphicsScene, which maintains scene data, OpenGL will carry out whatever drawing operation you ask it to do. Even if the final result may be invisible. Only in the very last processing steps (clipping, early fragment rejection) invisible fragments are discarded.
I have seen around that there is a b2Manifold. What I want to accomplish is to detect whether or not a collision was on the top part or not of one of the objects that were colliding.
I have already set up a b2ContactListener and it works fine. I would just like to provide more accurate collisions by setting up the manifold to detect if one b2Body is on top of the other b2Body that it collided with.
How would I do this?
Thanks!
http://postimage.org/image/kbfr7c5db/
I need to draw a tree with Qt,
I was thinking using QGraphicsScene and QGraphicsItem for the nodes. But as I want the nodes to be movable, so how do it the best way for the lines between the node ?
Any suggestions ?
Thx.
I would implement arcs as items as well, QGraphicsLine item in particular. The line could go between the centers of connected nodes.
Keep a reference to incident edges in the node item, and during node dragging update line nodes with:
edge->setLine(QLineF(node_center.x, node_center.y);
I suggest you use QML for drawing those kind of things (I hate QML language, but unfortunately it is the future in Qt for drawing high performance graphics, they are working hard on that and Qt5 will also be more QML-centric I guess). For drawing lines you can use rotated thin rectangles. See Rectangle.