Subclassing QGraphicsPixmapItem ???

[d_stranz]

I'm trying to organize the QGraphicsPixmapItems into a QVector and then add the individual vector entries to the scene. This will facilitate subsequent logic.

It actually doesn't matter in which order you do this, so long as at some point you *do* add the items to the scene. Just remember that when your item is destroyed by the scene, the pointer stored in the QVector will not be valid. Do not delete the pointers that you add to the QVector; they will automatically be deleted by the scene.

the pieces will be added with the squares as parents

You might want to rethink that, since the pieces will be moving from square to square and thus will be reparented often. You might want to make them direct children of the scene, but set their z-numbers so they are drawn on top of their respective squares. It will be very easy to keep track of which piece is on which square if you make two reciprocal QMaps: one that maps piece to square, the other that maps square to piece.

Regardless, it would probably be a better design to model the game independently of the display of the game. That is, instead of using QGraphicsPixmap items to represent the actual pieces in the game, model the board, pieces, and rules in a display-independent model. Use signals and slots to communicate changes in the board position, etc. to update the scene. By doing this, you can develop the game rules independently of how you display the board, and can get the logic for that working correctly without also getting all tied up in the game display at the same time. You'll also find it easier to change how the game is displayed, because you won't have to also change the game logic at the same time.

[mdavidjohnson]

anda_skoa and d_franz --

BTW, When I reply to two different posts, how can I force the system to publish them as two separate posts instead of combining them like this one?

Thank you, anda_skoa -

That does seem to have fixed it.

I'm not sure why it didn't crash before though.

---

Added after 23 minutes:

Thank you, d_franz -

Using two reciprocal QMaps is an intriguing idea. And I like the concept of separating the logic from the display.

But I wonder if the overhead of repeatedly referring to the maps might exceed the benefits.

For a simplified example, suppose I have a White Bishop at a1. It's potential moves would then be limited to b2, c3, d4, e5, f6, g7, and h8.

We check b2 and there's nothing on that square, so it's possible to move to b2.

We check c3 and there's a piece on it. If it is a White piece, it's not possible to move to c3. If it is a Black piece, it's possible to move to c3 with a capture.

In either case, our checking is short-circuited: There's no need to check d4, e5, f6, g7, or h8 because our Bishop cannot move past c3.

But, as an extended example, a Queen on a central square might have to check as many as 7 + 7 + 7 + 7 = 28 different squares for move legality.

I will think more on this.

Would reciprocal QHashs be superior to QMaps for this application?

[d_stranz]

But, as an extended example, a Queen on a central square might have to check as many as 7 + 7 + 7 + 7 = 28 different squares for move legality.

This is why it took decades for IBM to teach Big Blue to play master-level chess. And that isn't even considering look-ahead or strategy.

Map lookup -is- hash-based, the main difference being that QMap iterators return entries in key-sorted order, whereas QHash entries are arbitrarily ordered. If you don't have a need for ordering pieces or squares, then a QHash would work fine. (I would presume your keys would be the names of the squares or something like "wb1" for pieces, which are unique).

Lookups are extremely fast, so even if you did have 28 potential moves, checking them all would be quick. That particular scenario is the worst case anyway - for other pieces and for more typical piece placements, the number of things you'd need to check would be much less before you were blocked by another piece or ran off the edge of the board. I think I would also compute the allowed moves on the fly, using rules for each piece, rather than try to build a lookup table for each piece at each location on the board. That is, knowing the position of a white bishop ("x,y"), you know that it has potential moves to (x+1, y+2), (x-1, y+2), (x+1, y-2), (x-1, y-2), (x+2, y-1), etc., if I remember my chess rules correctly, so long as the target squares are on the board and not occupied by a piece of the same color. For a queen at (x,y), the rules are (x+n, y+n; n <=7), (x+n, y; n<=7), etc.

It is always good to separate logic from visualization. As you get the logic right, you can report the game moves as text (wb a1 ->c3) and worry about displaying it graphically later. You're probably going to want to create game log anyway, so that's how you'd report it.