[Kde-games-devel] Co-ordinates in QGraphicsView

[Stefan Majewsky]

On Sun, Jul 1, 2012 at 4:06 AM, Ian Wadham <iandw.au at gmail.com> wrote:
> In the QGraphicsView module, a scene (QGraphicsScene) and a view (QGraphicsView)
> each have their own co-ordinate system and there is an automatic transformation
> between them.  This works fine for simple items like lines, rectangles, circles and
> ellipses, but how does it work for pixmaps rendered from SVG by KGameRenderer?
>
> Suppose I have a 10x10 grid full of pixmaps in a scene.  It woul be nice if I could
> use scene co-ordinates X = 0 to 9 and Y = 0 to 9 and the view would work out
> however many pixels that comes to, e.g. the view is 400x400 pixels, so each
> grid square is painted as 40x40 pixels.  That works fine if there is a
> QGraphicsRectItem in each square.

Yeah, the various involved coordinate systems are a real problem. An
early solution I came up with was to use the paintEvent() to find the
actual pixel size of the sprite image, and setRenderSize()
accordingly. This is implemented in KGameRenderedObjectItem and used
by KDiamond and Klickety. The obvious problem is that finding the
right render size needs a roundtrip through a paint event.

In Tagaro, I later implemented another solution, which is better,
though still not optimal. The classes Tagaro::SpriteObjectItem does
similar things like KGameRenderedObjectItem, but it uses a
Tagaro::Board parent item to calculate its size. The board has a
"logical size" (e.g. width=height=9 for a board with 9x9 fields) and a
"physical size" (in scene coordinates). The board can use a
QGraphicsView to find the relationship between pixels and its
"physical size", and update the render size of contained
SpriteObjectItems accordingly.

This latter system is used in Kolf (though static import of the
relevant classes, see kdegames/kolf/tagaro/). A Kolf course always is
400x400 big in the logical coordinates used by Kolf's save files and
physics engine. The Tagaro::Board maintains the scale between these
400 units and the N pixel edge length of the view.

In Kolf, this works quite nicely. I recall that Jeffrey Kelling and I
had run into some problems using Tagaro::Board in Magnetik Planet (git
clone kde:scratch/jkelling/magnetikplanet) which is why
Tagaro::Board/SpriteObjectItem in the libtagaro repo differs in some
regards from the copy in Kolf.

Greetings
Stefan