To use the least memory you're really going to have to use a combination of techniques. It's a matter of breaking the card images down into their component parts then writing a routine to construct them at run-time as needed on the screen.
Textures or sprites? I assume you really meant to ask whether you should go for textures/sprites (3D) or images (2D) and this really depends on whether you need the cards to be scalable/rotatable and what your target hardware is.
Whichever you go for, you will need textures/images for each symbol (Hearts/Spades/Clubs/Diamonds), each numeral (2 to 10) and each letter (A,K,J,Q). Ideally these will be 1-bit and you will colour them on the fly depending on whether they need to be black or red. Note, though, that you can't used paletized graphics in Blitz so you will be saving disc space, not memory where colours are concerned. Personally I would put my own ease as a programmer above the need to save what will be a piffling amount of space by modern standards, but you asked!
There's also the central imagery to consider for cards like the King... personally I would bite the bullet and use PNG as it's non-lossy, retains trasparency information (so if you wanted to add a surface characteristic to the card you could) and you can get some decent file sizes out of the format if you use something like PSP's export options.
For the backs of the cards... a small, repeating pattern. Straightforward in 3D and only slightly more bothersome in 2D.
Once you have all your individual elements it's really up to you to decide how to construct the visual representation of each card as needed. That's going to depend on your methodology for handling instances of cards in your code so is not really something anyone can provide definitive advice on at this point.
Personally, again, I have to say, I'd forget this manner of optimisation altogether... it's almost certainly not worth the payoff. Make coding the thing as easy as posible -- that should be your primary design directive if you actually want to finish the thing. Optimisation can come later.
EDIT: Sorry, wrote 2-bit instead of two colours (1-bit)
Textures or sprites? I assume you really meant to ask whether you should go for textures/sprites (3D) or images (2D) and this really depends on whether you need the cards to be scalable/rotatable and what your target hardware is.
Whichever you go for, you will need textures/images for each symbol (Hearts/Spades/Clubs/Diamonds), each numeral (2 to 10) and each letter (A,K,J,Q). Ideally these will be 1-bit and you will colour them on the fly depending on whether they need to be black or red. Note, though, that you can't used paletized graphics in Blitz so you will be saving disc space, not memory where colours are concerned. Personally I would put my own ease as a programmer above the need to save what will be a piffling amount of space by modern standards, but you asked!
There's also the central imagery to consider for cards like the King... personally I would bite the bullet and use PNG as it's non-lossy, retains trasparency information (so if you wanted to add a surface characteristic to the card you could) and you can get some decent file sizes out of the format if you use something like PSP's export options.
For the backs of the cards... a small, repeating pattern. Straightforward in 3D and only slightly more bothersome in 2D.
Once you have all your individual elements it's really up to you to decide how to construct the visual representation of each card as needed. That's going to depend on your methodology for handling instances of cards in your code so is not really something anyone can provide definitive advice on at this point.
Personally, again, I have to say, I'd forget this manner of optimisation altogether... it's almost certainly not worth the payoff. Make coding the thing as easy as posible -- that should be your primary design directive if you actually want to finish the thing. Optimisation can come later.
EDIT: Sorry, wrote 2-bit instead of two colours (1-bit)