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

[Andreas Pakulat]

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?

> 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...

> 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?

> 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...

> 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.

> 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? And what about the raster decks? 

> 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'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.

Andreas

-- 
You look tired.