Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: RenderImage vs. Juggling a Handful of Sprites  (Read 1866 times)

0 Members and 1 Guest are viewing this topic.

mecablaze

  • Newbie
  • *
  • Posts: 5
    • View Profile
RenderImage vs. Juggling a Handful of Sprites
« 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.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
RenderImage vs. Juggling a Handful of Sprites
« Reply #1 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.
Laurent Gomila - SFML developer

mecablaze

  • Newbie
  • *
  • Posts: 5
    • View Profile
Clarification
« Reply #2 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?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
RenderImage vs. Juggling a Handful of Sprites
« Reply #3 on: March 12, 2011, 07:39:02 pm »
Image::Copy is for composing your final cards programmatically, not with your old image editor.
Laurent Gomila - SFML developer

 

anything