Page 1 of 1

QGraphicsView

Posted: Fri Jun 08, 2012 3:08 am
by chris
I came across QGraphicsView today while looking at some QT documentation. Is there a reason our mapper isn't using this layout? It seems like it would allow for a lot of functionality for very little work.

Re: QGraphicsView

Posted: Fri Jun 08, 2012 8:53 am
by Vadi
Heiko would have to answer that, I'm not certain.

Re: QGraphicsView

Posted: Sat Jun 16, 2012 9:54 pm
by chris
I gave it a try and the rendering is slower than what we have going now, which is sort of expected since we call QPixmap which ties into the hardware.

Re: QGraphicsView

Posted: Sat Jun 16, 2012 10:25 pm
by Vadi
CPU you mean?

GPU is hardware too, but it's brilliant for graphics.

Re: QGraphicsView

Posted: Sun Jun 17, 2012 7:12 pm
by chris
I'm going to pursue this avenue for a bit, the performance on real maps when the code is unoptimized is indistinguishable from the current mapper. It also lets me treat each entity on the map as an object easily, set Z levels to automagically handle draw orders, etc. I can also subclass the graphic items, so I can subclass a Room, a Line, or a label, and within that subclass define the behavior/submenus from right/left clicking.

Anyone who wants to follow the progress can grab it from the GraphicsView branch on my git repo.

Re: QGraphicsView

Posted: Wed Dec 12, 2012 7:49 am
by Vadi
What is the latest news in this dept, if any?

Re: QGraphicsView

Posted: Wed Dec 12, 2012 2:24 pm
by chris
It's on the backburner. Once you start adding in labels/rooms/exits the map slows down considerably when it gets to big enough sizes. I think it's better to make the current mapper use some of the QGraphicsView-like implementations (such as having rooms/lines/etc be a class).

Re: QGraphicsView

Posted: Wed Dec 12, 2012 8:16 pm
by Vadi
Hm, yeah. I did try it out on a giant one-area-world map and it was way, way slow.