[Kde-games-devel] Tiles in KShisen
Wolfgang Rohdewald
wolfgang at rohdewald.de
Tue Jan 20 00:00:51 CET 2009
On Montag, 19. Januar 2009, Luciano Montanaro wrote:
> So let's extend the tileset format. It should not need too many changes...
> I think it already has the tile separated from the mah-jongg symbols, isn't
> it?
yes. The missing round wind tile could look like in xmj - maybe with a black
circle around the wind symbol. Without having that svg symbol I could simply
draw a white circle and put the wind face element on it - without shadow.
I believe this could be the same for all tilesets.
did you know there are unicode codes for mah jongg tiles? I was thinking about
using those codes to identify the tiles. So maybe it would be helpful to
somehow have them in the svg file. If the svg element names allow unicode,
the element name could simply be the unicode char. Can an SVG element have more
than one identifier? Since Python fully supports unicode (much easier to use
than in C++) this would be very nice for writing applications.
Problem: Find a font that actually implements those chars.
> So maybe all it needs is:
> - adding the missing symbols
> - add the rotated tile +shadow. (or rotate the existing tiles...)
> - add a "back" tile
>
> I think it should be possible to just rotate the existing tiles, although that
> may need finding the right orientation for each rotated tile...
I've programmed all that. See attachment. Look at the 4 tiles at the top,
especially the upper border and shadow. Also the lower corners of the 4 walls.
There you can see current problems with borders and shadows very well. Also,
in the classical tileset the form of the shadow is very irregular.
The frame border is for easier debugging. My class Board normally inherits from
QWidget but for testing I am inheriting from QFrame instead. I wonder if it would be
better not to use QLabels for the tiles in a QWidget but a QGraphicsScene. Since
qt4.4 even normal widgets like combo boxes can be put into a QGraphicsScene,
and they can even be rotated. Nice.
This is how the code generating the tiles in the attachment looks like:
self.players[0].wind.lightSource = 'NE'
self.players[1].wind.lightSource = 'SE'
self.players[2].wind.lightSource = 'SW'
self.players[3].wind.lightSource = 'NW'
... and for every player.wind: (xoffset, yoffset can be fractions - I need that too)
tile = self.addTile("WIND_"+PlayerWind.windtilenr[self.name])
tile = tile.attach('BAMBOO_1', xoffset=1, rotation=90)
tile = tile.attach('BAMBOO_2', xoffset=1, rotation=180)
tile = tile.attach('CHARACTER_1', xoffset=1, rotation=270)
as you can see in the attachment I still have layouting problems when resizing
the window. The wind tiles should all have the same size and left/right player
should not be that far from the walls.
You can not simply stretch a tile such that it has the form of a lying tile
because the relations between height and width are not constant: default.svg:
entire tile #TILE_2: 96/116=0.8275
tile without shadow: #g2285: 79.99/100.00=0.7999
surface of the tile: #g2291: 65.502/85.661=0.7646
face: #CHARACTER_3: 69.125/89.125=0.7756
I believe if these relations were all the same one could simply make the tile
broader and reduce the height - and put a rotated face on it. That should
work much better with the existing borders and shadows. I would not have to
combine tiles with different angles (what I call lightSource, and I believe
you mean the same with orientation). But if I do that with the tileset as it
is now, when attaching a rotated tile to a non rotated tile those two tiles's
shadows do not have the same width. Or if they have the face size is wrong.
Because I have to choose from one of the above relations.
> Then you compose the final tiles as it is done at the moment but twice, one
> time for the vertical tiles, the second one for the horizontal tiles.
yup. I compose them only when needed and put the entire tile into the pixmap
cache (kmahjongg puts the separate elements into the cache and always has to
combine several cache entries whenever drawing a tile. QImage is not neeedd.
kmahjongg does it with QImage, but that should be slower). Try it out - kmj
resizes much faster than kmahjongg. To further reduce the amount of computation
and number of cache entries I only resize the tiles when the board size changes
by at least X pixels. This is almost not noticeable but definitively speeds
things up even more. After all just like in kmahjongg I always have to draw
all 144 tiles.
> > Also, in kmj I need to be able to draw reversed tiles (face down). I
> > simulate that by drawing tiles without faces.
> >
>
> That one should simply be added. It should not be that difficult. It may just
> be another "symbol" to draw over the tile background.
Not quite. Again look at the borders. They should be reversed to be perfect.
I personally would love to have better and easier to use tilesets but I will not
involve myself with that - I just use them as they are.
--
Wolfgang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 90451 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20090120/ade4f0fc/attachment-0001.png
More information about the kde-games-devel
mailing list