Would it be better to have my Sprite class have a "draw" method or should i just manually do the blt''s using the Blt and BltFast functions (From DirectX) ?

I wrote a sprite class recently. I think its better that the sprite do it itself because when drawing your sprite may have to(and should) look at certain properties and decide how it should be blitted - like location,if its facing left or right, what frame of animation it''s in(I actually had a seperate animation class).

Programming sprites is very hard. Make sure you design it well.

What I''ve finally decided to do is have a sprite class, which when constructed, receives a pointer to an "object drawer" class. This object drawer class is responsible for loading and managing sprite graphics, maintaining a queue of required blts, and can draw sprites based on a numerical basis (for example, the Sprite class can say "go draw sprite 4, frame 5 at (432,123)"). All the draws are then flushed when the frame is ready to be drawn (ie all game logic has passed through). This creates an extra layer between the sprite and the graphics code, allowing all images to be maintained centrally, while also providing device independence to game logic, regardless of the portability or lack thereof of your lower level drawing routines. You could even recode the game to use 3D instead of 2D and only have to change the graphics coding, and the object drawer.

I find this arrangment really conveinent, and I''m going to do something similiar with sound when I have time to get away from apps and go back to game coding *sigh*

Thanks for the replies, I think i''ll opt for a draw() method in the Sprite class...I think i read somewhere that it should be done manually to save processing speed (the layer of indirection), but I don''t think it''s nesscessary with a simple 2D game.

Thats true too, a simple class doesn''t need all that much processing speed. I think its better you keep your code clean and have a Draw function.

My sprite class relies on an animation class through delegation - having an instance of a class inside another class. Basically, the sprite itself takes care if its logic and input. It also stores its own surface meaning it''s not very independant. Basically I used static pointers to hold the pointer to the back surface, so when I call blt, it goes there immediately. I also overloaded it to draw to a surface pointer passed to it. My animation class actually loads a file that stores the rectangles to each animation sequence and the number of steps in that sequence. When I set the sprite state, I have to tell the animation class this, and it will update the frame that needs to be shown. It will also loop through everytime I call a function to increase(limited by time). I sort of designed it and hased it together badly though and have to call a function every frame for my sprite class to get the rectangle needed to draw. My next go round, I won''t have the surface stored in the sprite class directly. Instead it will be in the animation class, making the sprite class more graphics independent and efficient. My only problem will come when I have to tell the sprite to draw itself which would require the sprite to tell the animation class to draw...I guess a small function on the stack is a small price to pay for what is gained....

And I started to babble about my program too much. Sorry about that.

"Ogun''s Laughter Is No Joke!!!" - Ogun Kills On The Right, A Nigerian Poem.

Is there any reason why inlining the sprite''s Draw() function shouldn''t solve the problem of function calling overhead due to this additional indirection?