Just read the other older thread about this - Using the .png or any other compression format won't help you, at the end of the day when you load the texture in it will uncompressed to 16 or 32 bit. So after scaling, and converting to 32-bit, this one texture will be 8Mb - Plus another 2.7Mb for mipmaps. So for all four suites, thats a grand total of - ~42.8Mb! (Thats not counting any meshes, or any other graphics in your scene)
Also, holding all the cards (or just one suite) in one texture won't help you either, unless your planning on showing all possible cards at once, because although it may save you on swapping textures when rendering, it will still upload the suite entire texture to the video card it would very slow if the graphics card couldn't hold all the textures in memory.
If you were to have a single texture per card, when it came to rendering it would only have to upload a bunch of smaller textures and only the ones it needed - therefore, much more likely to fit into graphics memory and more friendly to the texture cache.
As for making up a card of component parts, its really not worth the effort, and jokers, j,q,k would still need special texture parts. All that extra work, for parhaps a few less texture swaps for which you wouldn't even notice the difference in framerate - it's not like your rendering 1000's of cards at once (are you?!)
You can easily save out 52 images, at 128x256 8-bit palettized all that only comes up to about 1.6Mb on disk, which is nothing in the grand scheme of things. Then when all are loaded in and coverted to 32-bit, that would be 6.5Mb (8.67Mb with mips) held in normal RAM. Then when you want to render it and you had say, 10 different cards currently displayed in your game, that would only take up at most 1.25Mb of video ram (big difference from 33Mb!)
In a lot of cases, using a bigger texture made up of smaller textures works very well to speed up rendering and reducing texture swaps, but in this case - it's not.
Also, holding all the cards (or just one suite) in one texture won't help you either, unless your planning on showing all possible cards at once, because although it may save you on swapping textures when rendering, it will still upload the suite entire texture to the video card it would very slow if the graphics card couldn't hold all the textures in memory.
If you were to have a single texture per card, when it came to rendering it would only have to upload a bunch of smaller textures and only the ones it needed - therefore, much more likely to fit into graphics memory and more friendly to the texture cache.
As for making up a card of component parts, its really not worth the effort, and jokers, j,q,k would still need special texture parts. All that extra work, for parhaps a few less texture swaps for which you wouldn't even notice the difference in framerate - it's not like your rendering 1000's of cards at once (are you?!)
You can easily save out 52 images, at 128x256 8-bit palettized all that only comes up to about 1.6Mb on disk, which is nothing in the grand scheme of things. Then when all are loaded in and coverted to 32-bit, that would be 6.5Mb (8.67Mb with mips) held in normal RAM. Then when you want to render it and you had say, 10 different cards currently displayed in your game, that would only take up at most 1.25Mb of video ram (big difference from 33Mb!)
In a lot of cases, using a bigger texture made up of smaller textures works very well to speed up rendering and reducing texture swaps, but in this case - it's not.