   Sprite Manager!
  Ok, I have a sprite loader, but I want to make a sprite manager in order to do a few of things:Provide Collision Detection and ResponseSort the sprites based on their Y locations so they appear in front of eachother correctlyRandom access to any sprite for scripting and such too.It seems as though I only have a weekend to have the project done for class (dang teacher tricked me!), and I want the absolute *fastest* (as in development time) way to achieve these goals.I started creating a CSpriteManager class that is something like this:struct sSpriteNode{ CSprite sprite; sSpriteNode *next;};class CSpriteManager{ private:    int m_NumNodes;    std::vector<sSpriteNode> m_SpriteList;    ... public:    CSprite *GetSprite(int ID);    int DoCollisions(int sector);    int SortSprites(int sector);    int AddSprite(CSprite *sprite);    int KillSprite(int ID);    ...};This was just a thought, if anyone has any better ways of handling sprites please let me know, because its crunch time. =/EDIT: I know that the vector kinda makes it weird, but I just jotted something down, so bear with me. :)
  I've got something very similar in my code. I pretty much do everything you do:- I have a vector of MapSprites (I call them Objects though because mine can include trees and such)- I sort the vector before every frame draw and then iterate through the vector, only drawing objects which should be visible.I use a lot of inheritence in mine though, so I can treat different objects different ways. I still have a lot of work to do on my code though to add various features and such, but for now sprites are working and animating ok. Here's the latest snip of these class headers I'm working on tonight:/******************************************************************************ObjectLayer - Abstract class for all map objects>>>members<<<int object_type: an identifier type for the objectint row_pos: the map row position for the bottom left corner of the objectint col_pos: the map col position for the bottom left corner of the objectunsigned int status: a bit-mask for setting and detecting various conditions on the sprite>>>functions<<<virtual void Draw(local_map::MapFrame& mf):A purely virtual function for drawing the object, if it even needs to be drawn >>>notes<<<1) An object's "vertical" position is used so that objects can be drawn over eachother if necessary. For example, there may be a bridge that we want to be ableto walk on or under. Range is from -128 to 127. If an object has a height >= 100,then the object is drawn *after* the upper layer. *****************************************************************************/class ObjectLayer {protected:int object_type;int row_pos;int col_pos;char ver_pos;hoa_video::GameVideo *VideoManager;friend class MapMode; // Necessary so that the MapMode class can access and change these data memberspublic:ObjectLayer();~ObjectLayer() {}bool operator>(const ObjectLayer& obj) const;bool operator<(const ObjectLayer& obj) const;bool operator>=(const ObjectLayer& obj) const;bool operator<=(const ObjectLayer& obj) const;bool operator==(const ObjectLayer& obj) const;bool operator!=(const ObjectLayer& obj) const;virtual void Draw(local_map::MapFrame& mf) = 0;};/******************************************************************************MapSprite - Abstract class for all character, NPC, enemy, and other sprites>>>members<<<float step_speed: determines how fast the sprite transitions between tilesfloat step_count: a counter used for tracking movement>>>functions<<<void Draw(local_map::MapFrame& mf):A function for determining if a sprite needs to be drawn, and if so, drawing the spriteint FindFrame():Called by the Draw() function to figure out the sprite frame that should be drawn>>>notes<<<1) TO DO: Add functionality in Draw() to determine if a sprite should be drawn or not *****************************************************************************/class MapSprite : public ObjectLayer {protected:float step_speed;float step_count;unsigned int status;std::vector<hoa_video::ImageDescriptor> frames;void Draw(local_map::MapFrame& mf);friend class MapMode; // Necessary so that the MapMode class can access and change these data membersprivate:int FindFrame();};/******************************************************************************PlayerSprite - Manages the user-controllable player sprite on the map. >>>members<<<>>>functions<<< >>>notes<<< *****************************************************************************/class PlayerSprite : public MapSprite {friend class MapMode; // Necessary so that the MapMode class can access and change these data memberspublic:PlayerSprite();~PlayerSprite();};/******************************************************************************NPCSprite ClassThis class is for managing the images needed to display and animate sprites on maps. >>>members<<<int wait_time: the number of milliseconds to wait till the next tile transitionint delay_time: the average time to wait between tile transitions>>>functions<<<  >>>notes<<< *****************************************************************************/class NPCSprite : public MapSprite {friend class MapMode; // Necessary so that the MapMode class can access and change these data members//vector<bool, std::string> sprite_dialogue; LATERint wait_time;int delay_time;public:NPCSprite(std::string name);~NPCSprite();void ConstantMovement() { delay_time = 0; }void DelayedMovement(int average_time) { delay_time = average_time; }};Like I said, a lot of inheritence. [smile] A PlayerSprite is also a MapSprite is also an ObjectLayer. But it makes it nice and easy to update the game state. I just iterate through this vector of objects and call different functions accordingly. Snip:// Update all game objectslist<ObjectLayer*>::iterator obj_iter;for(obj_iter = object_layer.begin(); obj_iter != object_layer.end(); obj_iter++ ) {switch ((*obj_iter)->object_type) {case PLAYER_SPRITE:UpdatePlayerExplore(dynamic_cast<PlayerSprite*>(*obj_iter));break;case NPC_SPRITE:UpdateNPCExplore(dynamic_cast<NPCSprite*>(*obj_iter));break;default:cout << "Object not a sprite!" << endl;break;}}Dunno if it's the best way to do things, and surely it depends on how your game operates. But it's been working great so far. [grin]   ;  Wow, that is some heavy C++, or at least compared to what I'm used to.Yeah thanks Roots (love what your doing with your project), I don't know how much it helped though since I just totally scrapped the idea of using a robust sprite managing system for this project.I decided that I am going to make this code work for this game only-- A little maze where you have to navigate through as fast as you can. That's it.I'm making my code dirty and ugly. I'm making my code... pure linear. *woman screams*I decided this because I realize that I have way too much on my agenda right now (3 final projects due monday, and I have to start a research paper too).Oh, well, thanks again. [smile]   ;Quote:Original post by RootsI've got something very similar in my code. I pretty much do everything you do:- I have a vector of MapSprites (I call them Objects though because mine can include trees and such)- I sort the vector before every frame draw and then iterate through the vector, only drawing objects which should be visible.I use a lot of inheritence in mine though, so I can treat different objects different ways. I still have a lot of work to do on my code though to add various features and such, but for now sprites are working and animating ok. Here's the latest snip of these class headers I'm working on tonight:*** Source Snippet Removed ***Like I said, a lot of inheritence. [smile] A PlayerSprite is also a MapSprite is also an ObjectLayer. But it makes it nice and easy to update the game state. I just iterate through this vector of objects and call different functions accordingly. Snip:*** Source Snippet Removed ***Dunno if it's the best way to do things, and surely it depends on how your game operates. But it's been working great so far. [grin]I think Washu would have a fit with this.Please read.;Quote:Original post by visageI think Washu would have a fit with this.Please read.Interesting read. However I don't think my reliance on inheritence here is necessarily a bad thing. Imagine if I had each specific object as a seperate class. To put them all in a single container, I'd have to use void * pointers and casting to grab them and sort them in the appropriate order, etc. (exactly how you'd be forced to do it in C). It just doesn't make sense to me *not* to use inheritence to my advantage in this case.The MapSprite class might be over-doing it a little, but it exists because both sprites share a lot of similarity (particularly they are drawn the same way, and why write that function twice?). I'm not trying to say that inheritence is the golden egg of C++ design (because it absolutely isn't), I'm just saying it's useful when used in the right cases, and I believe this case is one of those. [smile] Thanks for pointing out that article to me though!Back on topic, The Forgotten Mindset if you're shooting for getting a small game coded ASAP then yeah, you might want to do something simpler and/or messier to get the job done. Good luck!;  I'm sort of curious why you differentiate between PlayerSprite and NPCSprite.  To me, they're basically the same thing.  I agree with your use of inheritance to extend your basic sprite class, but it seems superfluous in this case.  I understand you'd want to access each sprite through a common interface --- I do this myself --- but it seems to me you'd only want to derive classes where the method of calculating/processing animation is unique --- for example, frame-based vs. interpolated vs. physically accurate (as I mentioned in Forgotten's other thread).  Just curious.   ;Quote:Original post by TomI'm sort of curious why you differentiate between PlayerSprite and NPCSprite.  To me, they're basically the same thing.  I agree with your use of inheritance to extend your basic sprite class, but it seems superfluous in this case.  I understand you'd want to access each sprite through a common interface --- I do this myself --- but it seems to me you'd only want to derive classes where the method of calculating/processing animation is unique --- for example, frame-based vs. interpolated vs. physically accurate (as I mentioned in Forgotten's other thread).  Just curious.Well initially the reason I split them was because they are different in the way they interact with the map. In the game loop when I update the player sprite, I check for user input to determine how to change the sprite. On the other hand, the NPC sprites either have a random movement function or are updated by a script. So that's the core difference between the two.The other difference (which has come about recently) has to do with the number of frames. In addition to the standard motion frames, we may also want frames for things like climbing, jumping, emotions, etc. This can turn into a lot of work for our artists and we don't want to have to require them to make all these frames for every sprite. Therefore, we only create these extra frames for player sprites. So it's really a safety mechanism to make sure we don't access outside the sprite frame vector for NPC sprites, which would cause a seg fault.In all honesty though, I think you are right that there's not really a need for PlayerSprite and NPCSprite classes and it wouldn't be too much work to merge them together. I think I'll work on doing that when I get a chance. [smile]   ;  Well guys it's all done (been done a while..)Here is the final game: Uber Maze Escape!!111oen1!!!!1It's definanly as complex as I envisioned, and is an entirely different game (not rpg :))Time is the most valuable resource known to man, as well as the most expensive.Oh, and yeah, didn't get to use a sprite manager :)   