Actually, writing that gave me some ideas to fix that problem, heh.
Anyways, I decided to beef up my Entity class a bit. Here's the definition:
class entity{ protected: CHAR_INFO* sprite; COORD size; public: COORD position; entity(); entity(COORD theSize); entity(CHAR_INFO* theSprite, COORD theSize); virtual ~entity(); int AllocSprite(int sizeX, int sizeY); COORD Size(); // May throw std::out_of_range. CHAR_INFO& operator[] (int idx);};The end-user - well, technically that's me too - can actually create an extended Entity class that contains additional fields, like Health and Level and Speed for example, that they can use for whatever they want. The GameView only cares that what it has is an Entity. In that respect it's a bit like an interface, except that you can instantiate a bare-bones, base-class Entity.
Sure, I guess you could keep that information (health, level, speed) in a separate structure and not bother with inheritance. It seems like a weak reason to use inheritance, actually. But conceptually it's cleaner to have everything in one spot. Actually, you could take that aforementioned separate structure and just add " : public entity" after the name, and it would work.
It occurs to me that I should explain what some of the member functions of Entity are for. Well, the operator[] allows for easy indexing of the sprite member (and includes bounds checking). AllocSprite() deletes the current sprite if it exists, and re-allocates enough room for a sprite of size (sizeX, sizeY). The position is public because, quite simply, there's no reason for it to be encapsulated. I was going to make it protected, and create get/set functions, but they would have been little more than "position.X = X; position.Y = Y;" and "return position;". Why bother?
Alright, back to mucking with drawing the entity sprites to the buffer. Comment!
