I have a question that sort of a matter of opinion, but I'd like to get some input. Here's what i have:
A Bitmap class, which holds all info about the bitmap;
A Sprite class; this class is made up of several bitmaps. it has several for each frame, plus masks and "under" bitmaps for erasing the sprites. This class also includes member data like speed and position.
Now, i want to make an asteroid class, which will hold data about each asteroid. Should I:
have an instance of the sprite class be a member of the asteroid class? With this be too much overhead? If i do this, the data like speed and position would not need to be included in the asteroid class, as it could be accessed like: asteroid.sprite.x. however, this seems kind of roundabout. Should i maybe put the data like position and speed into the asteroid class, and remove it from the sprite class, leaving the sprite class strictly for frames of images and such? I've included the sprite class and the bitmap class (but not the asteroid class, as i have created it yet). Please give me your thoughts and how to go about this.
It depends on if you want to reuse Sprite for other proejcts. If Sprite is holding all of your graphics stuff, I would include all graphics stuff in Sprite (Bitmap*, width, length, etc.) This allows for you to use Sprite later in volitile (as in short lived code) game engines.
Then in asteroid, put velocity, position, your Sprite* (saves a lot of memory if you have zillions of them on the screen,) and whatever else that makes asteroid and asteroid in the asteroid object.
Basically, by looking at it from the viewpoint of what each object should do, you can divide attributes between the two objects in a logical manner.
If what was placed inside of Sprite was textures, then it would not be plausable to inherit assuming that a lot asteroids were on the screen and those asteroids were al using the same set of bitmaps.
A Sprite manager which would probably be a templated List of some sort, could take all of the Sprites, store them in a "pool." I think MFC has such an object if you are cramped for time, if you know MFC, or if your application allows for the cycles.
This way, if you want to reuse this storage structure, you can always just link it instead of hacking apart Asteroid. Plus, if you want to create textured landscapes and stuff like that, you can always just pull from the pool instead of playing with Sprites.
Now, an index to the texture would be more costly in terms of speed but it is safer than playing with pointers. Both methods have their ups and downs, but thats a preference thing right now.
If you already know how then there is no reason to make one. Either you already have one or you simply use the STL ones anyway, they're probably more powerful than yours
Container writing is something you do when learning the language, or when you need a VERY specific container. OOP is about reusability.
All the buzzt CornedBee
"Writing specifications is like writing a novel. Writing code is like writing poetry."
- Anonymous, published by Raymond Chen
Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.
Reply With Quote
CornedBee
