[Kde-games-devel] Unify pixmap caching across card games

[Luciano Montanaro]

Il Monday 07 January 2008 21:53:31 Andreas Pakulat ha scritto:
> On 06.01.08 21:30:24, Luciano Montanaro wrote:
> > Il Sunday 06 January 2008 13:12:38 Andreas Pakulat ha scritto:
> > > On 06.01.08 11:57:05, Andreas Pakulat wrote:
> > > > I've started to work on unifying the pixmap caching across card
> > > > games, currently that involves kpat and lskat which are in kdegames
> > > > presently.
> > > >
> > > > I'm planning to use KPixmapCache behind the scenes instead of any
> > > > custom caching method for the pre-rendered SVG's. For this to work
> > > > well across all card games I've created a new class CardCache in
> > > > libkdegames and I'd like to have a discussion about the API.
> > > >
> > > > The attached file contains the header of this class including api
> > > > dox, so please have a look and send your comments.
> > >
> > > Sorry, forgot to attach the actual file...
> >
> > Also, the theme and size is not going to change that often in normal use.
> > So I'd use setTheme() and setSize() methods to set those when they need
> > to change.
>
> I agree about the size, but not about the theme. You can choose
> different theme names for front and back side, so each time you fetch a
> pixmap you'd first have to do a setTheme. An alternative would be
> setBackTheme and setFrontTheme, but I find that rather ugly.
>
> > The card() method (or front() method?) could then be card(suit, value);
>
> I've changed both methods to frontside and backside. Sounds better?
>

Yes, thank you! :)

> > The enum start with Ace, then King... is this the best choice?
>
> I don't care, but I also don't think it makes much difference in which
> order the card types are listed in the enum.
>
> > I'd go with Ace, Dice, ... King. Card value are assigned differently in
> > different games / different traditions.
>
> I don't have internet right now (while writing the mail), so please
> forgive me asking, but is Dice == 2?
>
> > The load method should either ask for the cards suit and values it needs
> > to load, or for a fixed enum like Deck52, Deck40 or so on...
> >
> > One of the decks we ship has card numbered up to 13.... Some game may
> > need that option. Also it would be nice to support tarot decks,
> > eventually! :)
>
> Extending the existing enum is no problem, but yes to save some space
> there should probably a few enums for specific card games, like Deck32
> (for skat) or deck52 for kpat (IIRC). Can you create some kind of "list"
> for this, I'm not familiar with those other card games...
>

Actually, thinking another bit about this, we may want to let people design 
decks for specific games/card deck types. for decks in the German tradition 
drawing the cards is much more work than for international decks, so we 
should allow 32 card decks, but with some flag to filter them out for games 
where they cannot be used.

Many Italian decks have 40 cards (Ace-7 Jack, Queen or Knight, King).

I think in Spain a 48-card deck is typical. Quite different design from the 
international deck, similar to the decks used in southern Italy.

Then there is the international 52 card deck; We are using two decks in the 
Spider game (but there is no need to support it in the cache, of course).

There is a good page with examples for many decks (in Italian only, but with 
lots of examples) here:

http://a_pollett.tripod.com/cardpgai.htm


> > Some game could benefit from having more than one back available.
> > Games like "Scala 40" are played with two decks of cards; traditionally
> > the two decks have different backs (red and blue), and it would be nice
> > to offer this option.
>
> Uhm, thats another reason for not having setters for the theme. The
> above can easily be acomplished by loading the back for the blue and
> then for the red theme. Or are the backs not in different "themes"? If
> not how does this stuff work with png and svg files?

If you look at the tigullio international deck, you can find a few back 
variations (just color variations, but that can change). 

>
> > Our decks have Jolly joker cards too. Those can't be represented with a
> > suit+value combination...
>
> Hmm, then maybe we need to combine the suite type and card type into 1
> enum and making the parameters Or-Combination of the values. So you'd
> call frontside( theme, CardCache::Club | CardCache::King ) or
> frontside( theme, CardCache::JollyJoker )
>
> That would also make this easier extendable to totally different card
> games like tarot which might not have a suite at all...

Yes, I think this is better.

>
> > Finally, I'd really like to be able to "get rid" of the separate backs
> > themes somehow. But others like it; I think this can be solved if we
> > understand each other better.
> >
> > My problem with the separate backs is that we do not have (rightly) any
> > convention on the size/ratio of the cards, or on their shape. In the
> > world there are decks of many different shapes, from circular, to tall
> > and thin, to square... all of those card shapes could work in our games,
> > in principle.
> >
> > They would not work with backs that are not part of the design, however.
>
> I do see the problem with that, though of course the backside can just
> be rendered to "fit". Which might destroy the nice look of the backside,
> but after all, you can't really predict what each user might like. I
> personally don't lile the oxygen back much, but the frontside is really
> nice.
>

There is the problem of the corners. Many of the backs have square corners, 
but the decks have rounded corners, with smaller or larger radii. We could 
manipulate the svg to leave a margin and embed the back images in there, but 
it is more work, and it requires hand-editing the svg file; not all the 
artists may want to do that. 

> > So the simplest option to give a few options to the players is to add a
> > few (or many) back variants directly in the deck svg. The backs could be
> > selected by name, if we name them progressively ("back_1", "back_2"...)
> > or we could give a class="back" attribute to the cards drawings that are
> > supposed to be used as backs, and then offer all of them for selection in
> > the card dialog.
>
> Hmm, does that work with QSvgRenderer? 

You can render just one card by reference with 

deckRenderer.render(painter, "back_2"); once we obtain the back names.

We could store the number of backs in the .desktop with a 

Backs=<number> 

entry, and we can compose the card back like back_%1. The code could fall back 
to the "back" back if the back_n does not exist...

Actually, it's possible to check for the existence of an svg element with
deckRenderer.exists("back_1");
so it's not strictly required to have the number of backs included in 
the .desktop file.

> And what about the raster decks? 

SVG has an <img> tag too. Non svg decks could be trivially converted to svg 
decks by shipping the images together with a .svg wrapper containing 
something like 
<svg>
<img id="4_hearts" href="4_hearts.png" /> 
</svg>

I did not look up the SVG specs, so the syntax may be a little different...



>
> > Well, I really wrote much more than I wanted to...
> > I hope I did not dissuade you to work on this, however!
>
> No, and btw. this is still the easier part of the work. Changing kpat
> and lskat to actually use this cache and drop their own implementation
> will be quite a bit harder.

I have not looked into that, but is kpat very different from your proposal?
Some rfactoring could be useful to make it easier to offer more game types in 
kpat, too.

>
> I'll change the enum to a QFlags thing now and then I'll post an update
> on the classes.
>
> BTW: I'm currently working on this in a local git clone of the kdegames
> module, thus when this code is ready to be committed to trunk/ it would
> create a bunch of separate svn commits. Those commits would contain
> compiling code, but would also show the progress of these mails. If you
> think its better to add the new cardcache in a single svn commit with
> only the final version please let me know so I can arrange for that.
>

I think this should not be a problem, I'm doing this kind of things myself 
with kgoldrunner. 

If someone sees this as a problem it's better to state that soon...

Ciao,
Luciano