>> As we only need 6 bits of every byte, we can overlap the cards in
>> memory, every four cards in three bytes:
>>
>> AAAAAABB BBBBCCCC CCDDDDDD EEEEEEFF FFFFGGGG GGHHHHHH
>Don't forget that someone's also gonna have to *draw* a screen with all
>these cards. I doubt you'd have time to extract card values out of that
>packing during a screen kernel, and you can forget about using Andrew
>Davie's packing method for that :) I'd use one byte per card to make that
>a good deal simpler.
I take it doing by nibbles isn't that bad though?
>> For the build piles, Erik pointed out that you can draw these out
>> randomly from the deck at the point they are uncovered, instead of
>> actually tracking them all along... This is sound thinking. Once
>Actually, my original method for that was a bit flawed. I was using extra
>values to keep track of how many cards were in each face-down pile.
>There's no need for that. Just make it one linear array: the first spot
>will be the card in the first pile, the next two spots the cards in the
>next pile, the next three spots the cards in the third pile, and so on.
>And use 0 to indicate 'no card'. Keeping track of how many cards in each
>pile is unnecessary. Since you need to keep the undealt cards somewhere,
>you may as well just deal them into that array at game start instead of
>into the deck.
And I guess this doesn't take up any extra room either, so it would
actually speed up implementation from my scheme when most of the deck
is empty. I like it. :-)
>> Now, we still need to keep track of the up cards... Another trick
>> Erik mentioned was that we only need to keep track of the SUITS of
>> the cards underneath the top. So, we need 7 bytes for the top
>Actually, you need but _one_ bit, not two, for each card after the first.
>After the first card, you know what color each card below will be, so you
>only need one bit to distinguish suit. E.g., if the top card is the queen
>of spades, you only need one bit to tell whether the next one is the jack
>of hearts or the jack of diamonds.
Ah! Did I miss that, or are you refining?
>Of course, you need some counter to keep track of how many cards in the
>stack (your terminator won't work anymore.) Still, though, that's 6 bits
>for the top card plus 4 for the counter plus 12 for the other cards;
>smaller than your 6 bits for the top card plus 2 each for 12 other cards.
True. Of course, to avoid packing & unpacking time, we'll just use one
byte for the top card, and exactly two bytes for the up stack. I assume
we'd start those two bytes with the counter itself?
>Saves another whole byte per stack.
Woohoo!
Now who can do even better? :-)
Well, actually, I had the (uncompressed) ace piles at 4 bytes, but if
we use one byte to store the order of suits (you'd have to juggle a
terminator state, starting with/alternating 00000000 and 11111111 states
as you added), then you'd only need two bytes (4 nibbles) for the top
card values, saving one more byte.
Of course, this is somewhat ridiculous, so I won't go into detail about
the parenthetical mumbo-jumbo about the terminator required, which would
eat some processor time...
//*================================================================++
|| Russ Perry Jr 2175 S Tonne Dr #105 Arlington Hts IL 60005 ||
|| 847-952-9729 slapdash@xxxxxxxxxxxx VIDEOGAME COLLECTOR! ||
++================================================================*//
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
