card game advice
Blitz3D Forums/Blitz3D Programming/card game advice
| ||
| If I am making a card game... which would be more memory friendly in b3D??? 1. Cards as sprites 2. cards as textures or Cards as fonts... I have a playing card font. -RZ |
| ||
| Using a font for your graphics is pretty dumb. You'd have like no control over the graphics. As for sprites vs. textures, are you talking about 3D graphics? Because in that case, you're comparing apples to oranges. It's not an either-or thing; a sprite is the geometry, the texture is the image displayed on the geometry. So with a sprite you still need a texture. You could use a regular mesh instead of a sprite for the geometry, but either way you'll need a texture image. |
| ||
| Make sure you use a compressed imageformat like PNG. As cards have a lot of white and samey colours, they can be compressed very efficiently. Also try to use the smallest palette possible. A regular playing card should easily fit in 8 or 16 colours, and maybe a few more for the picture-cards like K,Q,J. |
| ||
| Note that using a compressed image format only helps for data storage (ie. hard drive space,) not run-time memory use (ie. RAM.) That's because regardless of how the image is stored it gets decompressed for use. Reducing the color depth/using a small palette helps in both however. |
| ||
| Do palettes actually get used these days? I thought they were all expanded to 32-bit in the end... |
| ||
| Well damn, then maybe the color depth doesn't matter either for memory usage. |
| ||
| Well, I suppose it's in memory with it's original palette. Isn't it when it gets actually used on geometry and shown on screen it goes 32 bit? You hardly see all 52 cards at the same time anyway. |
| ||
| You could also consider generating your 'regular' cards on the fly by drawing your own textures from card-elements the moment you need them. This would be pretty slow though, I think. |
| ||
| Well I was going to create a card *entity* and apply the texture to it depending on which card it was. OR I was going to just create a set of sprites and just show which card it was... Both seem pretty slow. I think the *entity* route could look prettier in the long run because I can control the alpha more efficently... -RZ |
| ||
| You will also want to display a different texture on the back of the cards which single Sprites can't manage. |
| ||
| True... two entitys in Rhino... VERY THIN... labeled FRONT and BACK then... |
| ||
| @Napoleon: To generate cards at run-time is a good idea: it won't be slow as you think as I did it for a card game I wrote for Amiga-500 (7MHz CPU) and there was no speed problem. |
| ||
| Personally I'd create a mesh and deal with the UVs. A card has the same symbol in the top right and bottom left but reversed, you also want this symbol to be a decent res, so you'd create a texture that holds all of the suits as well as all the numbers from 1,10,J,Q,K, also this would need to hold the pictures of the Jacks, queens and kings for all suits, I would imagine you'll be able to fit all of this onto 1 512x512 texture quite easily. You'd have a second texture (surface) that is the back of the cards (probably a 256x256). You'd need to create a mesh that is basically a grid. This needs to be UVed up so you've got the number and suit delt with in the top right/bottom left. Then you've got the cental bit. If you split this into a 3x3 grid you can then just uv map from your single surface so that it displays the correct symbols in the correct grid square. Anyway, once you've done that lot you've got a whole deck of cards on 2 surfaces, 1 512x512 texture and 1 256x256 texture. |
| ||
| Make sure you use a compressed imageformat like PNG. As cards have a lot of white and samey colours, they can be compressed very efficiently. Also try to use the smallest palette possible. A regular playing card should easily fit in 8 or 16 colours, and maybe a few more for the picture-cards like K,Q,J. You joking? Only 5 colours are ever needed for playing cards. Including the backing pattern on the reverse and the picture cards plus jokers. White, Black, Red, Blue and Yellow |
| ||
| Malice... Personally I'd go for at least 256 colours to take antialiasing into account. |
| ||
| I tried both PMG and JPG and for some things PNG is much smaller... ie. The sprites for my game that say *SCORE* etc. but to do the intro screens I used JPG because the same size of PNG was 4X as big a file. -RZ |
| ||
| @malice: only if you want flat, jaggy images. If you want the cards to look good, you want some shading, maybe some dirt or paper-texture on it as well. And it's nice if you can do some antialiasing between the different colours too. |
| ||
| @malice: only if you want flat, jaggy images. If you want the cards to look good, you want some shading, maybe some dirt or paper-texture on it as well. And it's nice if you can do some antialiasing between the different colours too. Well, why not scan some 32-Bit images of actual playing cards then??? The Subject was Rook Zimbabwe asking about the most memory friendly way to do this.... |
| ||
I know what the subject was, thanks. As I said: for most cards, 8 colours is enough. Some might need more, like this one: So next time try to think a bit before bitchslapping people for no other reason than trying to help people out in a constructive manner. Thanks. |
| ||
| What are the copyright issues if you scan cards and use them in a commercial game? Presumably, the card images are copywrite material, just like any other. |
| ||
| Well I was wondering about that too... Copyright is usually ONLY granted for Jack through King... Ace of Spades and Card Backs UNLESS there is a new design element to the FONT or SHAPE of SUITES... I suppose that is why every card company has cards that look really the same until you get to the face cards and then they look *similar* but not same... -RZ |
| ||
| Naked Lady playing cards ;-) |
| ||
| 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) |
| ||
| I was hopig for *simple and elegant* but I would indeed settle for simple! :) If my website supported the ability to hotlink pics I would show you what I have... Sadly no... It is a security issue because of the products we sell. Picture this: A set of PNGs of each suite. I could put them together but I wanted to make a strip because it is easier for me to think about. KISS rule! |
| ||
| All good ideas let me say! Sledge has the most direct approach. While you can rotate sprites you can't flip them over and show a different pic and thats where I was at... I suppose I will simply try to write the thing with sprites. You know VB had a VBCards.Dll maybe something like that??? |
   |