SFML community forums

Help => Graphics => Topic started by: mecablaze on March 12, 2011, 03:10:09 am

Title: RenderImage vs. Juggling a Handful of Sprites
Post by: mecablaze on March 12, 2011, 03:10:09 am

Okay, so I am working on a card game in SFML2 (I'm on Windows using Visual Studio 2010). I have a sprite sheet containing different graphics used to generate each card in the deck used for my game (symbols and card backs). I have an XML file defining where each individual sprite in the sprite sheet resides. All that is working fine.

I would like to generate all possible cards using the different symbols and card backs in my sprite sheet (i.e. I have an object Card which represents a single unique card). For the sake of example, think of having a sprite sheet with a club, heart, spade, and diamond on it with a white rectangle for a card back.

I would like to generate each possibility in a deck of cards. I can think of three ways to do this, I just don't know which one is the easiest and (more importantly) most efficient:
[list=1]

• Have the Card object maintain multiple sprites, one representing the card back, the rest representing each symbol on the card, etc. (this means adjusting multiple sprites' coordinates as the card itself moves around)
• Render the card back then symbols to a RenderImage and store that unique image for each Card object. This solution seems to lose the efficiency gained by having a sprite sheet (having only one image in the video memory)
• Somehow subclass sf::Drawable for the symbols to allow for relative coordinates to the parent (the card itself) to allow easier drawing
[/list:o]
I have tried this project with SDL (I created a seperate surface for each card) and XNA (I basically calculated the symbols' position at each draw).

Edit: I just wanted to leave a note and say that I'm totally geeking about SFML right now. It's a great project and orders of magnitude more usable than SDL.

Title: RenderImage vs. Juggling a Handful of Sprites
Post by: Laurent on March 12, 2011, 01:16:23 pm

I think the most efficient and easy way to handle this, is to compose all your cards and put them in one big image (or two or three if it exceeds the maximum texture size).

This way, you get:
- the best performances because there are only a few different images
- the easiest solution since you don't have to compose your cards dynamically, there are ready to use

You don't need RenderImage/Sprite to do so, you can simply use Image::Copy.

Title: Clarification
Post by: mecablaze on March 12, 2011, 04:08:11 pm

Quote from: "Laurent"

You don't need RenderImage/Sprite to do so, you can simply use Image::Copy.

Just to be clear (I'm still pretty new to game programming), I should open up my old image editing program (I'm using Paint.NET) and create all the card possibilities, save them to a couple of new sprite sheets and those into memory via Image::LoadFromFile? Where does Image::Copy come in, during that process?

Title: RenderImage vs. Juggling a Handful of Sprites
Post by: Laurent on March 12, 2011, 07:39:02 pm

Image::Copy is for composing your final cards programmatically, not with your old image editor.