2
\$\begingroup\$

Currently i'm working on a sprite system which will have frames which make animations.

Usually a sprite contains current position, current frame number to be displayed in the running animation, etc... This is what I mean is STATE.

Let's say there are 100 NPC characters in a game which will have different animations running at any time.If we are maintaining the state in Sprite class, we usually create 100 sprites and draw it as each sprite has its own state.

But I feel the same thing can be done like this, Imagine, position and animation state is separated from the Sprite class.When ever we want to draw we will just set it and draw the frame at certain position.With this approach there is no need to have 100 sprite instances.We can make the exact above situation with one single sprite instance.

For me I feel separating the "state" kills encapsulation.But at the same time it will have a benefit in terms of huge memory!

Please give your Pros/Cons on this kind of approach?

\$\endgroup\$
2
  • \$\begingroup\$ I'm not really sure I understand. Are you saying you want to have 100 sprites that are all in the same spot and animated the same way? \$\endgroup\$ Commented May 20, 2011 at 5:01
  • 1
    \$\begingroup\$ @Drackir: NO.I mean the situation where we need 100 sprites all from same sprite sheet but different having actions running at different postions at once. \$\endgroup\$ Commented May 24, 2011 at 13:40

2 Answers 2

Reset to default
3
\$\begingroup\$

I assume all your classes use a pointer to the sprite-sheet/texture, so that the actual sprite-bitmap-data takes up memory space just once.

Assuming this, it really isn't going to help you much (concerning memory usage) to have the NPC and the Sprite class separated. Although I think separating the two can still be a good idea if you look at it the following way:

Sprite or SpriteSheet class:

  • is a helper class that will be initiated with a pointer to the sprite-sheet data and the desired frame-size
  • allows definition of "animations" which are basically collections of frames (or UV coordinates)
  • handles playback/looping of animations
  • doesn't know anything about game states

NPC class

  • depending on your design, this could either be a subclass of Sprite or hold a pointer to a Sprite instance (I would choose the latter).
  • implements the NPC behavior
  • will trigger/play animations depending on state (utilizing a Sprite instance)

I think this is quite the opposite of "killing" encapsulation. So in summary: I would recommend to separate your classes, but not because of memory-concerns...

\$\endgroup\$
1
  • 1
    \$\begingroup\$ +1 for "I would recommend to separate your classes, but not because of memory-concerns" . Yes ofcourse that's what in my mind as well.But think this way- We are duplicating the variables holding position of sprite in Sprite class as well as in NPC class also.If the number of instances are more we need to think of memory as well. \$\endgroup\$ Commented May 24, 2011 at 13:44
0
\$\begingroup\$

You are correct. We do the same type of thing in our engine. There is a sprite object that can organize your images into pages (texture file) and groups. A group has frames of animation taken from the texture from a grid or if you want to pack more data into the optimal space, you can specify the sprite via a rect. There is an entity object which is made from a sprite group and they exist as instances in the game world having position and size. This allows for efficient management of objects for your game. Multiple entities can efficiently use the one sprite object.

\$\endgroup\$
2
  • \$\begingroup\$ "Multiple entities can efficiently use the one sprite object" - this is the idea behind my problem statement.But how effective it is to classify the classes based on memory rather than the classification they belong? \$\endgroup\$ Commented May 24, 2011 at 13:50
  • \$\begingroup\$ efficient, not so much for memory concerns (Windows PC) but for rendering. If you can minimize texture swapping and state changes it is much more efficient for rendering. You have your sprite sheet loaded into memory and your images are packed onto it as tightly as possible. Your sprite class then organizes these images into a logical representation. You Entity class then can present multiple sprites in the game world very efficiently in terms of memory and rendering. \$\endgroup\$ Commented May 24, 2011 at 22:25

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.