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

[Andreas Pakulat]

On 08.01.08 18:24:11, Luciano Montanaro wrote:
> Il Monday 07 January 2008 21:53:31 Andreas Pakulat ha scritto:
> > On 06.01.08 21:30:24, Luciano Montanaro wrote:
> > > 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.

See the latest update mail, its now possible to specify a specific
LoadInfo which usually indicates the deck type. In the implementation
this currently relies on the array having the right order (i.e. 32 deck
is just the 32 first entries from a 52 deck and so on).

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

Thanks, I'll have a look as soon as I've got internet access again at
home.

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

Ok, I'll add a simple number argument to the backside function.

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

That would simplify a _lot_ of code. Especially it would remove the need
for a mapping between combinations of card and suite to the actual png
names. So +1 from my side if you can find somebody/some people to do it.
Unfortunately I have close to 0 ide about SVG or how to edit it :)

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

No, it just does all the caching itself in a special dir in the KDEHOME
(and also an in-memory cache) and sometimes the caching is mixed with
other code...

Andreas

-- 
You will inherit millions of dollars.